淺談前端/軟件工程師的代碼素養
「程序是寫給人讀的，只是偶爾讓計算機執行一下。」 ——Donald Ervin Knuth（高德納）javascript
關於代碼素養
咱們經常談到「素養」一詞，是指我的在專業領域內實踐訓練而成的一種修養，在不一樣的領域中有不一樣的體現，如在音樂領域中，「音樂素養」是指我的對於音樂的感受程度，對音高節奏的把控，對不一樣流派音樂的鑑賞能力等，而在編程領域，也有不一樣的素養，反映出對基本功、代碼整潔度、專業態度等等方面，所謂「代碼素養」，簡單來講，就是指代碼寫的是否優雅美觀可維護。html
絕對完美的代碼是不存在的，代碼素養並非指完美主義。在翻譯領域有「信，達，雅」的標準，「雅」之因此放在最後，是由於要達到它，須要有比較高的水準和經驗積累。類比到編程領域，咱們在編程時，第一時間想到的是如何將業務邏輯實現出來，而不是如何把代碼優雅地寫出來，因此寫代碼沒有所謂的絕對優雅。可是，做爲一名專業的前端工程師，確切的說，應該是專業的軟件工程師，編寫優雅的代碼應當是時刻保持的追求，它更像是一個準繩，如同每一個人知道本身該作什麼，不應作什麼，所謂原則，所謂底線，體現出所謂的「代碼素養」。前端
破窗理論
破窗理論，原義指窗戶破損了，建築無人照管，人們聽任窗戶繼續破損，最終本身也參與破壞活動，在外牆上塗鴉，任垃圾堆積，最後走向傾頹。java
破窗理論在實際中很是容易出現，每每第一我的的代碼寫的很差，第二我的就會有相似「反正他已經寫成這樣了，那我也只能這樣了」的思想，致使代碼越維護越冗雜，最後一刻轟然坍塌，變成無人想去維護的垃圾。android
整潔的代碼
整潔的代碼如同優美的散文，試想讀過的一本好書，可以隨着做者的筆鋒跌宕起伏，充滿了畫面感，調動了本身的喜怒哀樂。代碼雖然沒有那樣的高潮迭起，但整潔的代碼應當充滿張力，可以在某一時刻利用這種張力將情節推向高潮。ios
我更喜歡把寫代碼類比於寫文章講故事，寫代碼是創做的過程，做者須要將本身想表達的東西經過代碼的形式展示出來，而整潔的代碼如同講故事通常，娓娓道來，引人入勝，很差的代碼則讓人感受毫無頭緒，通篇不知道在講什麼。程序員
整潔代碼原則
在現代化的前端開發中，有不少自動化工具能夠幫助咱們寫出規範的代碼，如eslint，tslint等各類輔助校驗工具，知名的規範如google規範、airbnb規範等等也從各個細節方面約束，幫助咱們造成合理規範的代碼風格。編程
本小節再也不重複語言層面的代碼風格，根據實際重構項目，總結出一系列開發過程當中須要時刻注意的原則，按照重要程度優先級排列。設計模式
1. DRY(Don't Repeat Yourself)
相信做爲一名軟件工程師，你們都據說過最基本的DRY原則，不少設計模式，包括面向對象自己，都是在這條原則上作努力。api
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. 有意義的名稱
代碼的可讀性絕大部分依賴於變量和函數的命名，一個好的名稱可以一針見血地幫助維護者理解邏輯，如同寫文章中的「文筆」，文筆優異者總能將故事娓娓道來，引人入勝。
不過要起好名稱仍是很難的，尤爲是咱們不是以英語爲母語，更是添加了一層障礙，有些人認爲糾結在名稱上會致使效率變低，開發第一時間應該完成需求的開發。這樣說並無錯，咱們在開發過程當中應當專一於功能邏輯，但不要徹底忽視命名，所謂「文筆」是須要鍛鍊的，思考的越多，命名就會越發的水到渠成，到後來也就不太會影響工做效率了。
在這裏推薦鮑勃大叔提到的童子軍規，每一次看本身的代碼，都進行一次重構，最簡單的重構即是更名，也許一開始以爲命名還比較貼合，但邏輯越寫越不符合初始的命名了，當回顧代碼時，咱們能夠順手對變量和方法進行從新命名，現代編輯工具也很容易作到這一點。
文不對題的命名是最可怕的，如：
function checkTimeConflict(opts) {
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的產生。
對於這種狀況，要麼維護註釋，要麼在註釋裏面註明接口文檔，維護文檔，在其餘狀況下，適當的註釋是有必要的，對於複雜的邏輯，若是有一個簡練的註釋，對於代碼可讀性的幫助是極大的，但有些沒必要要的註釋能夠去掉，註釋的取捨關鍵在於可讀性基本定理，如：
const filterFn = (term) => {
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」，他發覺本身帶上後再也沒法取下了，不只是由於腕帶很緊，更是由於它也是一條精神上的緊箍咒。在編程時，咱們下意識的看下本身的手腕，是否能發現一條隱形的腕帶呢？
- 1. 淺談前端/軟件工程師的代碼素養
- 2. 淺談軟件工程師的代碼素養
- 3. 前端工程師的基本素養
- 4. 淺談web前端工程師(轉)
- 5. 淺談硬件工程師
- 6. 淺談前端工程化
- 7. 淺談程序員的基本素養
- 8. 淺談前端開發工程師與美工的區別
- 9. 淺談軟件工程中的代碼評審
- 10. 招聘 Web前端工程師 、.NET軟件工程師 、美工
- 更多相關文章...
- • Markdown 代碼 - Markdown 教程
- • XSL-FO 軟件 - XSL-FO 教程
- • IntelliJ IDEA安裝代碼格式化插件
- • IDEA下SpringBoot工程配置文件沒有提示
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 淺談前端/軟件工程師的代碼素養
- 2. 淺談軟件工程師的代碼素養
- 3. 前端工程師的基本素養
- 4. 淺談web前端工程師(轉)
- 5. 淺談硬件工程師
- 6. 淺談前端工程化
- 7. 淺談程序員的基本素養
- 8. 淺談前端開發工程師與美工的區別
- 9. 淺談軟件工程中的代碼評審
- 10. 招聘 Web前端工程師 、.NET軟件工程師 、美工