淺談軟體工程師的程式碼素養
作者：孟健， 騰訊 web 前端開發 工程師
商業轉載請聯絡騰訊 WeTest 獲得授權，非商業轉載請註明出處。
原文連結：http://wetest.qq.com/lab/view/384.html
WeTest 導讀
寫這篇文章時內心是比較忐忑的，因為文章的話題範圍非常大，怕自己駕馭不了。在實際工作中，維護過很多型別的程式碼，其中不乏高階工程師完成的邏輯，大家的需求能力都很不錯，能夠快速滿足產品的需要，但很少能有人能注意到程式碼的整潔度，甚至很多程式碼經過多人維護後已經變得無法再進行任何一處的修改，最後不得不花大量的時間進行重構。因此我決定還是寫一篇文章來 “淺談” 軟體工程師應具備的程式碼素養，希望能夠對大家有所幫助，水平所限，如有不當之處還請不吝指正~
“程式是寫給人讀的，只是偶爾讓計算機執行一下。” ——Donald Ervin Knuth（高德納）
一、關於程式碼素養
我們常常談到 “素養” 一詞，是指個人在專業領域內實踐訓練而成的一種修養，在不同的領域中有不同的體現，如在音樂領域中，“音樂素養” 是指個人對於音樂的感覺程度，對音高節奏的把控，對不同流派音樂的鑑賞能力等，而在程式設計領域，也有不同的素養，反映出對基本功、程式碼整潔度、專業態度等等方面，所謂 “程式碼素養”，簡單來說，就是指程式碼寫的是否優雅美觀可維護。
絕對完美的程式碼是不存在的，程式碼素養並不是指完美主義。在翻譯領域有 “信，達，雅” 的標準，“雅” 之所以放在最後，是因為要達到它，需要有比較高的水準和經驗積累。類比到程式設計領域，我們在程式設計時，第一時間想到的是如何將業務邏輯實現出來，而不是如何把程式碼優雅地寫出來，所以寫程式碼沒有所謂的絕對優雅。但是，作為一名專業的前端工程師，確切的說，應該是專業的軟體工程師，編寫優雅的程式碼應當是時刻保持的追求，它更像是一個準繩，如同每個人知道自己該做什麼，不該做什麼，所謂原則，所謂底線，體現出所謂的 “程式碼素養”。
二、破窗理論
破窗理論，原義指窗戶破損了，建築無人照管，人們放任窗戶繼續破損，最終自己也參與破壞活動，在外牆上塗鴉，任垃圾堆積，最後走向傾頹。
破窗理論在實際中非常容易出現，往往第一個人的程式碼寫的不好，第二個人就會有類似 “反正他已經寫成這樣了，那我也只能這樣了” 的思想，導致程式碼越維護越冗雜，最後一刻轟然坍塌，變成無人想去維護的垃圾。
三、整潔的程式碼
整潔的程式碼如同優美的散文，試想讀過的一本好書，能夠隨著作者的筆鋒跌宕起伏，充滿了畫面感，調動了自己的喜怒哀樂。程式碼雖然沒有那樣的高潮迭起，但整潔的程式碼應當充滿張力，能夠在某一時刻利用這種張力將情節推向高潮。
我更喜歡把寫程式碼類比於寫文章講故事，寫程式碼是創作的過程，作者需要將自己想表達的東西透過程式碼的形式展現出來，而整潔的程式碼如同講故事一般，娓娓道來，引人入勝，不好的程式碼則讓人感覺毫無頭緒，通篇不知道在講什麼。
四、整潔程式碼原則
在現代化的前端開發中，有很多自動化工具可以幫助我們寫出規範的程式碼，如 eslint，tslint 等各種輔助校驗工具，知名的規範如 google 規範、airbnb 規範等等也從各個細節方面約束，幫助我們形成合理規範的程式碼風格。
本小節不再重複語言層面的程式碼風格，根據實際重構專案，總結出一系列開發過程中需要時刻注意的原則，按照重要程度優先順序排列。
1. DRY(Don’t Repeat Yourself)
相信作為一名軟體工程師，大家都聽說過最基本的 DRY 原則，很多設計模式，包括物件導向本身，都是在這條原則上做努力。
DRY 顧名思義，是指 “不要重複自己”，它實際上強調了一個抽象性原則，如果同樣或類似的程式碼片段出現了兩次以上，那麼應該將它抽象成一個通用方法或檔案，在需要使用的地方去依賴引入，確保在改動的時候，只需調整一處，所有的地方都改變過來，而不是到每個地方去找到相應的程式碼來修改。
在實際工作中，我見過兩種在這條原則上各自走向極端的程式碼：
● 一種是完全沒有抽象概念，重複的程式碼散落在各處，更奇葩的是，有一部分的抽象，但更多的是重複，比如在 common 下抽取了一個 data.js 的資料處理檔案，部分頁面中引用了該檔案，而更多頁面完全複製了該檔案中的幾個不同方法程式碼。而作者的意圖則是令人啼笑皆非——只用到小部分程式碼，沒必要引入那麼整個檔案。且不論現代化的前端構建層面可以解決這個問題，即使是引入了整個大檔案，這部分多餘的程式碼在 gzip 之後也不會損失多少效能，但這種到處 copy 的行為帶來後續的維護成本是翻倍的。
● 對於這種行為還遇到另外一個理由，就是工期時間短，改不動之前的程式碼，怕造成外網問題，那就複製一份相同的邏輯來修改。比如支付邏輯，原有的邏輯為單獨的 UI 浮層 + 單個支付購買，現在產品提出 “打包購買” 需求，原有的程式碼邏輯又比較複雜，出現了 “改不動” 的現象，於是把 UI 層和購買邏輯的幾個檔案整個複製過來，修改幾下，形成了新的 “打包購買” 模組，後來產品又提出 “按條購買”，按照上述” 改不動 “原則，又複製了一份 “按條購買” 的模組。這樣一來呼叫處的邏輯就會冗餘重複，需要根據不同的購買方式引入不同 UI 元件和支付邏輯，另外如果新添需求，如支援 “分期付款”，那麼將改動的是非常多的檔案，最可悲的是，最後想要把程式碼重構為一處統一呼叫的人，將會面對三份 “改不動” 的壓力，需要眾多邏輯中對比分析提取相同之處，工作量已經不能用翻倍來衡量，而這種工作量往往無法得到產品的認同和理解。
● 另一種極端是過度設計，在寫每個邏輯的時候都去抽象，讓程式碼的可讀性大大下降，一個簡單的 for 迴圈都要複用，甚至變數定義，這種程式碼維護起來也是比較有成本的，還有將迥然不同的邏輯過度抽象，使得抽象方法變得非常複雜，經常 “牽一髮而動全身”，這種行為也是不可取的。
這也是將該原則排在首位的原因，這種行為導致的重構工作量是最大的，保持良好的程式碼維護性是一種素養，更是一種責任，如果自己在這方面逃避或偷懶，將把這塊工作量翻倍地加在將來別人或自己的身上。
2. SRP(Single Responsibility Principle)
SRP 也是一個比較著名的設計原則——單一職責，在物件導向的程式設計中，認為類應該具有單一職責，一個類的改變動機應當只有一個。
對於前端開發來說，最需要貫徹的思想是函式應當保持單一職責，一個函式應當只做一件事，這樣一來是保證函式的可複用性，更單一的函式有更強的複用性，二來可以讓整體的程式碼框架更加清晰，細節都封裝在一個個小函式中。另外一點也和單一職責有關，就是無副作用的函式，也稱純函式，我們應當儘量保證純函式的數量，非純函式是不可避免的，但應當儘量減少它。
把 SRP 原則排在第二位，因為它非常的重要，沒有人願意看一團亂麻的邏輯，在維護程式碼時，如果沒有一個清晰的邏輯結構，所有的資料定義、資料處理、DOM 操作等等一系列細節的程式碼全部放在一個函式中，導致這個函式非常的冗長，讓人本能地產生心理排斥，不願去檢視內部的邏輯。
所有的複雜邏輯放在一個函式中，相信大家看到這樣的程式碼都會眉頭一皺:
show: function(a, b) {
if (!isInit) {
init();
isInit = true;
}
// reset
this.balance = 0;
this.isAllBalance = false;
var shouldShowLayer = true,
preSelectedTermId = 0,
needAddress = course.address_state,
showTerms,
termsObj;
var hasPunish = false;
this.course = course = course || {};
opt = opt || {};
opt.showMax = opt.showMax || 6;
(isIosApp || b.isIAP) && (usekedian = !0, priceSymbol = '<i class="icon-font i-kedian"></i>'),
f.splice(b.showMax), layer.show({
$container:b.$container,
content:termSelectorTpl({
terms:f,
curTermId:b.curTermId || d,
name:a.name,
hasPunish:h,
userInfo:j
}, {
renderTime:T.render.time.renderCourseTime,
renderCourseTime:renderCourseTime,
hideUserInfo:b.hideUserInfo,
hideTitle:b.hideTitle,
hidePayPrice:b.hidePayPrice,
confirmText:b.confirmText,
sys_time:a.sys_time
}),
cls:"term-select-new",
allowMove:function(a) {
return opt.allowMove || ($target.closest('.select-content').length &&
$('.term-select-new .select-time').height() +
$('.term-select-new .select-address').height() +
$('.term-select-new .select-discounts').height() > (winWidth > 360 ? 190 : winWidth > 320 ? 175 : 150));
},
afterInit:function(c) {
if (needAddress) {
that.loadAddress();
// 如果需要地址，且是 app 的話，螢幕可見性切換時需要更新下地址
if (isApp) {
$(document).on(visibilityChange, function (e) {
// console.log('visibilityChange',document[hidden]);
if (!document[hidden]) {
// true 參數列示必須重新整理
that.loadAddress(true);
}
});
}
}
that.afterTermSelect();
$dom.on('click', '.layer-close', function() {
setTimeout(function() {
!opt.noAutoHide && layer.hide();
}, 100);
opt.onCancel && opt.onCancel();
});
$dom.on('click', '.term', function(e) {
var $this = $(this);
var $terms = $('.term');
if (!$this.hasClass('disabled')) {
$terms.removeClass('selected');
$this.addClass('selected');
}
that.afterTermSelect();
});
$dom.on('click', '.layer-comfirm', function(e) {
var $this = $(this);
var termId = $dom.find('.term.selected').data('term-id');
var termName = $dom.find('.term.selected').find('.term-title').html();
var discountId = $dom.find('.discounts-list_item.selected').data('discount-id');
var couId = $dom.find('.discounts-list_item.selected .discounts-coupon').data('cou-id');
var directPay = false;
// ios 手Q IAP
if (that.toRecharge) {
// 需要充值的金額數目
var toRechargePrice = that.curPrice - that.balance;
if (isIosApp) {
require.async('api', function (api) {
api.invoke('api', 'balanceRecharge', {
amount: toRechargePrice
});
// 充值完成設定回撥
api.addEventListener('balanceRechargeCallBack', function(data) {
// 支付成功的話
// code=0為成功，其他表示失敗
// mode=1表示走充值檔位回撥，2表示直接充值回撥,如果ios 直接充值成功則直接支付
var directPay = data.code === 0 && data.mode === 2;
// 執行回撥重新整理資料
that.toGetBalance(that.course, termId, function() {
directPay && $this.trigger('click');
});
});
});
} else {
var toRechargePrice = that.curPrice - that.balance;
if (that.rechargeMap &&
Object.keys(that.rechargeMap).indexOf("" + toRechargePrice) > -1) {
that.opt.onComfirmClick && that.opt.onComfirmClick(1);
iosPay.iosRecharge({
productId: that.rechargeMap[toRechargePrice],
count: toRechargePrice,
succ: function() {
that.toGetBalance(that.course, $('.term.selected').data('term-id'));
}
});
} else {
that.opt.onComfirmClick && that.opt.onComfirmClick(2);
// T.jump('/iosRecharge.html?_bid=167&_wv=2147483651');
that.jumpPage('/iosRecharge.html?_bid=167&_wv=2147483651');
}
}
return;
}
if (!termId) {
require.async(['modules/tip/tip'], function(Tip) {
Tip.show(opt.dialogTitle);
});
return true;
}
// check address
if (needAddress && !that.addressid) {
if (course.must_fill_mailing || !$dom.find('.select-address').hasClass('z-no')) {
// 沒填地址的話地址框要標紅，然後需要滑到視窗讓使用者看到
var $cnt = $dom.find('.select-content');
var $addressWrap = $dom.find('.select-address_wrapper').addClass('z-err');
var cntRect = $cnt[0].getBoundingClientRect();
var addressBoxRect = $addressWrap[0].getBoundingClientRect();
// console.log('>>>>> ', cntRect, addressBoxRect);
if (addressBoxRect.bottom > cntRect.bottom) {
$cnt.scrollTop($cnt.scrollTop() + (addressBoxRect.bottom - cntRect.bottom));
}
return;
}
}
if (that.isAllBalance && that.opt.onComfirmClick) {
that.opt.onComfirmClick(3);
}
opt.cb && opt.cb(termId, discountId, couId, termName, that.isAllBalance, that.payBalance, that.addressid);
setTimeout(function() {
!opt.noAutoHide && layer.hide();
}, 300);
});
$dom.on('click', '.discounts-list_item', function(e) {
var $this = $(this);
var $discounts = $('.discounts-list_item');
var isSelected = $this.hasClass('selected');
if (!$this.hasClass('disabled')) {
$discounts.removeClass('selected');
$this.addClass(isSelected ? '' : 'selected');
that.setPayPrice();
}
});
$dom.on('click', '.address-person .i-edit2, .address-add', function() {
var termId = $dom.find('.term.selected').data('term-id');
var courseId = that.course.cid;
var src = '/addrEdit.html?_bid=167&_wv=2147483649&ns=1&fr=' + (location.pathname.indexOf('allCourse.html') > -1 ?
4 : location.pathname.indexOf('courseDetail.html') > -1 ? 2 : 3) + '&course_id=' + courseId + '&term_id=' + termId;
// T.jump(src);
that.jumpPage(src);
}).on('click', '.select-address_title .i-right-light', function(e) {
var $addressDom = $dom.find('.select-address');
var isOpen = !$addressDom.hasClass('z-no');
if (isOpen) {
$addressDom.addClass('z-no');
that.theAddressid = that.addressid;
that.addressid = undefined;
} else {
$addressDom.removeClass('z-no');
that.addressid = that.theAddressid;
}
});
}
});
} else {
opt.cb && opt.cb(opt.curTermId || preSelectedTermId);
}
}
單一職責並不一定要透過很多函式來完成，也可以用分段達到目的，如同這樣：
show(data) {
data && this.setData(data);
const renderData = {
data: this.data,
courseData: this.data.courseData,
termList: this.termList,
userInfo: this.userInfo,
addrList: this.addrList,
isIAP: this.isIAP,
balance: betterDisplayNum(this.balance),
curPrice: betterDisplayNum(this.curPrice),
curTermId: this.curTermId,
discountList: this.discountList,
curDisId: this.curDisId,
jdSelectId: this.jdSelectId,
curAddrId: this.curAddrId
};
const formatters = {
// formatters
termFormatter,
priceFormatter,
okBtnFormatter,
balanceFormatter,
priceFormatterWithDiscount
};
console.log('[render data]: ', renderData);
const html = payLayerTpl(renderData, formatters);
// 記錄捲軸位置
this._setScrollTop();
// 防止重複append
if (this.$view) {
this.$view.replaceWith(html);
} else {
this.$container.append(html);
}
afterUIRender(() => {
this.$view = $('.' + COMPONENT_NAME).show();
this._setContentHeight(); // 動態設定滾動區域的高度
this._restoreScrollTop(); // 恢復滾動位置
this._initEvent();
this._initCountDown(); // 限時折扣倒數計時
});
}
雖然這個函式也沒有維持單一職責，但透過 “分段” 的形式清晰的表明了內部的流程邏輯，這樣的程式碼看起來就會比所有細節揉在一個函式中好很多。
對於單一職責來說，保持起來還是比較困難的，主要在於職責的拆分，有時過於細緻的職責拆分也會給閱讀帶來比較大的困難，對於這種情況，還是拿寫作來對比，單一職責相當於文章的一個 “段落”，對於文章來說，每個段落都有它的中心思想，可以用一句話描述出來，如果你發現函式的中心思想很模糊，或者需要很多語言去描述它，那也許它已經有很多個職責該拆分了。
3. LKP(Least Knowledge Principle)
LKP 原則是最小知識原則，又稱 “迪米特” 法則，也就是說，一個物件應該對另一個物件有最少的瞭解，你內部如何複雜都沒關係，我只關心呼叫的地方。
保持暴露介面的簡介易用性也是 API 設計的通用規則，在實際中發現了這樣的一個 UI 元件：
module.exports = {
show: function(course, opt) {
// 此處省略一堆邏輯
},
jumpPage: function(url) {
// 此處省略一堆邏輯
},
afterTermSelect: function() {
// 此處省略一堆邏輯
},
setPrice: function() {
// 此處省略一堆邏輯
},
setBalance: function() {
// 此處省略一堆邏輯
},
toGetBalance: function(course, curTermId, cb) {
// 此處省略一堆邏輯
},
setDiscounts: function(course, curTermId, curPrice) {
// 此處省略一堆邏輯
},
filterDiscounts: function(discounts, curPrice) {
// 此處省略一堆邏輯
},
isSuitCoupon: function(cou, curPrice) {
// 此處省略一堆邏輯
},
setPayPrice: function() {
// 此處省略一堆邏輯
},
setTermTips: function(wording) {
// 此處省略一堆邏輯
},
loadAddress: function(needUpdate) {
// 此處省略一堆邏輯
},
setAddress: function(addressid) {
// 此處省略一堆邏輯
}
}
這個 UI 元件暴露了非常多的方法，有業務邏輯，有檢視邏輯，還有工具方法，這時會給維護者帶來比較大的困擾，本能的以為這些暴露出去的方法都在被使用，所以想重構其中某些方法都有些不好下手，而實際上，外部呼叫的方法僅僅是 show 而已。
一個好的封裝，無論內部多麼複雜，它暴露出來的一定是最簡潔實用的介面，而內部邏輯是獨立維護的，如上述程式碼，作為一個 UI 元件來說，提供最基本的 show/hide 方法即可，有必要時可加入 update 方法自更新，而無需暴露眾多細節，造成呼叫者和維護者的困擾。
4. 可讀性基本定理
可讀性基本定理——“程式碼的寫法應當使別人理解它所需的時間最小化”。
程式碼風格和原則不是一概而論的，我們經常需要對一些編碼原則和方案進行取捨，例如對於三元表示式的取捨，當我們覺得兩種方案都佔理時，那麼唯一的評判標準就是可讀性基本定理，無論寫法多麼的高超炫技，最好的程式碼依舊是讓人第一時間能夠理解的程式碼。
5. 有意義的名稱
程式碼的可讀性絕大部分依賴於變數和函式的命名，一個好的名稱能夠一針見血地幫助維護者理解邏輯，如同寫文章中的 “文筆”，文筆優異者總能將故事娓娓道來，引人入勝。
不過要起好名稱還是很難的，尤其是我們不是以英語為母語，更是新增了一層障礙，有些人認為糾結在名稱上會導致效率變低，開發第一時間應該完成需求的開發。這樣說並沒有錯，我們在開發過程中應當專注於功能邏輯，但不要完全忽視命名，所謂 “文筆” 是需要鍛鍊的，思考的越多，命名就會愈加的水到渠成，到後來也就不太會影響工作效率了。
在這裡推薦鮑勃大叔提到的童子軍規，每一次看自己的程式碼，都進行一次重構，最簡單的重構便是改名，也許一開始覺得命名還比較貼合，但邏輯越寫越不符合初始的命名了，當回顧程式碼時，我們可以順手對變數和方法進行重新命名，現代編輯工具也很容易做到這一點。
文不對題的命名是最可怕的，如：
{
if (opts.param.passcard || (T.bom.get('autopay') && T.bom.get('term_id'))) {
selectToPay({
result: {}
}, opts);
} else {
DB.checkTimeConflict({
param: {
course_id: opts.param.courseId,
term_id: opts.param.termId
},
succ: function(data) {
selectToPay(data, opts);
},
err: function(data) {
dealErr(opts, data);
}
});
}
}
這個函式被命名為 check* 開頭的，本意是檢測課程時間是否衝突，但內部邏輯卻包含了支付整個流程，此時對於呼叫者來說，如果不去細看內部邏輯，很有可能就會錯誤的認為 check 函式沒有副作用導致事故發生。
6. 適當的註釋維護
註釋是一個比較有爭議性的話題，有人認為可讀的函式變數就很清晰，不需要額外的註釋，且註釋有不可維護性，如：
// 1-PC, 2-android手QH5, 3-android APP, 4-ios&非手QH5, 5-IOS APP
var platform = isAndroidApp ? 3 : isIosApp ? 5 : 4;
實際上，這個欄位的含義早已發生了改變，但由於修改者只修改了邏輯，並沒有注意到這一行註釋，導致這個老註釋提供了錯誤資訊，此時的註釋不僅變成了無效註釋，甚至會導致維護人的誤解，造成 bug 的產生。
對於這種情況，要麼維護註釋，要麼在註釋裡面註明介面文件，維護文件，在其他情況下，適當的註釋是有必要的，對於複雜的邏輯，如果有一個簡練的註釋，對於程式碼可讀性的幫助是極大的，但有些不必要的註釋可以去掉，註釋的取捨關鍵在於可讀性基本定理，如：
{
if (rule.hideEndTerms && term.is_end) {
return false; // 隱藏已結束的期
}
if (rule.hideSignEndTerms && term.is_out_of_date) {
return false; // 隱藏已結束報名的期
}
if (rule.hideAppliedTerms && courseUtil.isTermApplied(term)) {
return false; // 隱藏已報名的期
}
if (rule.hideZeroAllowedTerms && courseUtil.isTermZero(term)) {
return false; // 隱藏名額已滿的期
}
if (rule.productType === productType.PACKAGE) {
return false; // 隱藏課程包的班級
}
return true;
};
對於上述邏輯來說，雖然透過變數可以大致猜出功能含義，但一眼看上去就能清晰掌握邏輯結構，歸功於註釋的簡明與清晰。
小結
本文提到的 6 個程式碼編寫的原則，前三個偏向於程式碼維護性，後三個偏向於程式碼可讀性，整個可維護性和可讀性構成了程式碼的基本素養。作為一名前端開發工程師，想要擁有良好的程式碼素養，首先要讓自己的程式碼可維護，不給別人的維護帶來巨大的成本和工作量，其次儘量保證程式碼的美觀可讀，整潔的程式碼人見人愛，如同閱讀一本好書，令人心情愉悅。
” 程式碼素養 “是一種態度，真正熱愛程式設計的程式設計師一定不會缺失 “程式碼素養”。我們通常稱 “寫程式碼” 為 “程式設計”，而不是 “程式編寫”，“設計” 一詞體現出了我們的程式碼是一件作品，也許不如 “藝術品” 那麼精緻，但也不是什麼粗麻爛布，如果在寫程式碼時天馬行空，得過且過，抱著只要能實現功能的思想，那這部 “作品 “是不具有觀賞價值的，這不僅僅體現出程式碼編寫者的” 不專業”，更是反映出對待程式設計這件事的態度，程式碼的整潔程度、可維護性取決於你是否真正 “在意” 你的程式碼，每個程式設計師不一定熱愛程式設計，但請你一定要以 “認真” 的態度對待自己的專業。
"clean code"的作者鮑勃大叔提到，有人曾送給他一條腕帶，上面寫著 “Test Obsessed”，他發覺自己帶上後再也無法取下了，不僅是因為腕帶很緊，更是因為它也是一條精神上的緊箍咒。在程式設計時，我們下意識的看下自己的手腕，是否能發現一條隱形的腕帶呢？
騰訊 WeTest 為您提供一站式遊戲/APP 應用測試服務，點選 http://wetest.qq.com 即可使用。
騰訊 WeTest 有獎徵文活動進行中，歡迎投稿！瞭解詳情：
http://wetest.qq.com/lab/view/379.html
如果對使用當中有任何疑問，歡迎聯絡騰訊 WeTest 企業 QQ：800024531
相關文章
- 淺談前端/軟體工程師的程式碼素養前端軟體工程工程師
- 淺談軟體工程中的程式碼評審軟體工程
- 【專業技能】程式設計師的軟體工程素養之畫好 UML 時序圖程式設計師軟體工程時序圖
- 海外IT工程師淺談工程師
- 程式碼整潔之道：程式設計師的職業素養（十三）程式設計師
- 程式設計師的職業素養（一）程式設計師
- 軟體工程師是靠培養就能成才的嗎軟體工程工程師
- 軟體測試工程師需要具備哪些素質?工程師
- 程式碼中的軟體工程軟體工程
- 論軟體工程師的自我修養：角色、重構與質量軟體工程工程師
- 《程式碼整潔之道——程式設計師的職業素養》讀書筆記（一）程式設計師筆記
- 【招聘】前端軟體工程師、高階前端軟體工程師前端軟體工程工程師
- 幽默：程式設計師與軟體工程師的區別程式設計師軟體工程工程師
- 成長之路--論程式設計師的職業素養程式設計師
- 軟體工程博士講師：軟體工程是一個學習過程，程式碼只是學習的副產品軟體工程
- 程式設計師職業素養之讀後感程式設計師
- 從一件小事聊聊軟體工程師的自我修養 | 掘金年度徵文軟體工程工程師
- 很認真的談一談程式設計師的自我修養程式設計師
- 譯：軟體工程師的軟技能（一）軟體工程工程師
- 中國的頂級軟體程式設計工程師和歐美的頂級軟體程式設計工程師差距有多大？程式設計工程師
- 要做軟體工程師，而不是前端工程師軟體工程工程師前端
- 談談一個程式設計師本該具備的素質程式設計師
- 從一個面試官的角度談軟體工程師的面試面試軟體工程工程師
- 依賴——軟體工程師的痛軟體工程工程師
- 淺談軟體開發中的防禦式程式設計程式設計
- 軟體工程師前景分析軟體工程工程師
- 程式碼規範淺談
- [ 招聘 | 上海 ] 軟體工程師 / 全棧工程師 / 晶片設計工程師軟體工程工程師全棧晶片
- 淺談程式設計師的“內卷化”程式設計師
- 一個合格的Webpack4配置工程師素養：第二部分Web工程師
- 一個合格的Webpack4配置工程師素養：第三部分Web工程師
- 談談Java工程師的學習Java工程師
- 淺談軟體效能提升相關的概念
- 如何以軟體工程師的身份工作？軟體工程工程師
- 軟體測試工程師的技能樹工程師
- 軟體測試工程師的尷尬工程師
- 軟體測試工程師的職責工程師
- 一個合格的Webpack4配置工程師素養：第一部分Web工程師