敲代碼也要講“基本法”：​程序員應(yīng)該遵守的編碼原則
本文轉(zhuǎn)載自公眾號(hào)“讀芯術(shù)”(ID：AI_Discovery)
怎樣才能算作是一名優(yōu)秀的程序員?Martin Fowler如是說(shuō)：“任何傻瓜都可以編寫計(jì)算機(jī)可以理解的代碼。優(yōu)秀的程序員只編寫人類可以理解的代碼。”
能夠理解問題，以可行的方式向最終用戶展示解決方案，并團(tuán)結(jié)協(xié)作共同實(shí)現(xiàn)這個(gè)最終目標(biāo)，這才能算作是好的程序員。那么問題來(lái)了，如何在人數(shù)眾多的情況下管理如此龐大的代碼呢?
這就要求大家去遵守一些原則，讓每個(gè)成員都編寫干凈且易于維護(hù)的代碼。畢竟，敲代碼也得講“基本法”呀~
單一職責(zé)
編碼一段時(shí)間之后，你的代碼很可能會(huì)將變得笨拙，也許具有執(zhí)行多種功能的類/模塊，最終你將得到成百上千行代碼的類。
單一職責(zé)就是針對(duì)這一問題——程序中的類或模塊應(yīng)該只負(fù)責(zé)一個(gè)特定功能的任務(wù)，這有助于保持模塊最小且干凈。
迪米特法則
當(dāng)模塊相互依賴時(shí)，它們就變得緊密耦合，這意味著一個(gè)類將對(duì)其他模塊產(chǎn)生依賴關(guān)系。而緊密耦合降低了代碼的靈活性和可重用性。
迪米特法則是由伊恩·荷蘭(Ian Holland)1987年在東北大學(xué)首次提出。該原理總結(jié)如下：
- 每個(gè)單元對(duì)其他單元的了解應(yīng)該有限：只了解與當(dāng)前單元“緊密”相關(guān)的單元。
- 每個(gè)單元只能與朋友交談;不要跟陌生人說(shuō)話。
- 只與直系朋友交談。
該原理可以擁有獨(dú)立的類和代碼，因?yàn)橐蕾囆暂^弱，其之間的關(guān)聯(lián)也更加松散，而你所做的任何更改都應(yīng)反映在最直接的朋友身上。
干凈的代碼比聰明的代碼好
一些程序員在寫代碼時(shí)會(huì)忍不住“炫技”，然而這種看起來(lái)很厲害的代碼比實(shí)際易懂的代碼更難理解。
這相當(dāng)于對(duì)于讀者來(lái)說(shuō)并不友好，相當(dāng)于給他們出難題。事實(shí)上，只要代碼干凈且易于理解，沒人會(huì)真正在乎代碼有多聰明。
例如，有些人想用三元運(yùn)算來(lái)執(zhí)行傳統(tǒng)的if-else語(yǔ)句。三元操作是標(biāo)準(zhǔn)編程操作，這當(dāng)然沒問題，但問題出在嵌套三元語(yǔ)句時(shí)。
- let A = 10;
- let B = 3;
- let C = 25;(A>B?A:B)// fine(A>B?(A>C?A:C):(B>C?B:C))//notfineif(A>B){
- (A>C?A:C)
- }else{
- (B>C?B:C)
- }//better
YAGNI(You Aren’t Gonna Need It)
生活中，人們做一件事時(shí)會(huì)提前計(jì)劃并做好準(zhǔn)備。但這在編程中不是很適用。YAGNI原則就在談這一點(diǎn)，永遠(yuǎn)不要為將來(lái)可能需要的功能編寫代碼。它很可能不需要，這是在在浪費(fèi)時(shí)間。
你可以將這一條其視為對(duì)KISS原則的具體應(yīng)用，同時(shí)也是對(duì)那些認(rèn)真遵循DRY原則的人的回應(yīng)。缺乏經(jīng)驗(yàn)的程序員通常會(huì)盡最大努力避免編寫最抽象和通用的代碼，避免使自己代碼變得笨拙。但是太多的抽象最終會(huì)導(dǎo)致無(wú)法維護(hù)的代碼膨脹。
你要做的是，只在看到需要抽象的代碼時(shí)才抽象代碼。相反，不要將DRY原則應(yīng)用于將來(lái)可能會(huì)反復(fù)編寫的代碼。
簡(jiǎn)而言之，就是活在當(dāng)下，而不是將來(lái)。
用正確的工具去運(yùn)用這些規(guī)則
有一些工具可以幫助更輕松地遵循這些原則，例如，前端開發(fā)人員使用像Bit.dev這樣的云組件中心來(lái)發(fā)布獨(dú)立的組件。你需要去尋找這些工具。
那么它們又是如何幫助程序員遵循這些原則的呢?
- 將組件構(gòu)建為獨(dú)立的代碼段(旨在作為獨(dú)立代碼進(jìn)行發(fā)布，重用和協(xié)作)，自然使每個(gè)開發(fā)人員都更加注意單一職責(zé)原則。
- 從任何代碼庫(kù)發(fā)布組件的自由意味著可以共享和重用更多代碼，也免不了遵循DRY原則。這也意味著不會(huì)用從不使用的UI組件來(lái)構(gòu)建完整的設(shè)計(jì)系統(tǒng)，而是遵循YAGNI原則，僅在需要時(shí)才構(gòu)建和發(fā)布每個(gè)組件。
圖源：unsplash
編寫干凈易懂的代碼聽起來(lái)簡(jiǎn)單，實(shí)際做起來(lái)卻并不容易。如今，這已經(jīng)成為一項(xiàng)必不可少的要求了。我們需要不斷實(shí)踐，必須慢慢改變處理問題的方式，并以一種清晰的方式得出解決方案。這不是一夜之間的過渡，而是需要幾個(gè)月和幾個(gè)項(xiàng)目的積累。
編程是一項(xiàng)團(tuán)隊(duì)合作任務(wù)，項(xiàng)目成功與否很大程度上取決于團(tuán)隊(duì)表現(xiàn)。在爭(zhēng)取不做“豬隊(duì)友”的基礎(chǔ)上，努力去做那個(gè)帶飛團(tuán)隊(duì)的大神吧!
