寫(xiě)讓別人能讀懂的代碼
隨著軟件行業(yè)的不斷發(fā)展,歷史遺留的程序越來(lái)越多,代碼的維護(hù)成本越來(lái)越大,甚至大于開(kāi)發(fā)成本。而新功能的開(kāi)發(fā)又常常依賴(lài)于舊代碼,閱讀舊代碼所花費(fèi)的時(shí)間幾乎要大于寫(xiě)新功能的代碼。
我前幾天看了一本書(shū),書(shū)中有這么一句話:
“復(fù)雜的代碼往往都是新手所寫(xiě),只有經(jīng)驗(yàn)老道的高手才能寫(xiě)出簡(jiǎn)單,富有表現(xiàn)力的代碼”
此話雖然說(shuō)的有點(diǎn)夸張,可是也說(shuō)明了經(jīng)驗(yàn)的重要性。
我們所寫(xiě)的代碼除了讓機(jī)器執(zhí)行外,還需要?jiǎng)e人來(lái)閱讀。所以我們要寫(xiě):
-
讓別人能讀懂的代碼
-
可擴(kuò)展的代碼
-
可測(cè)試的代碼(代碼應(yīng)該具備可測(cè)試性,對(duì)沒(méi)有可測(cè)試性的代碼寫(xiě)測(cè)試,是浪費(fèi)生命的表現(xiàn))
其中2,3點(diǎn)更多強(qiáng)調(diào)的是面向?qū)ο蟮脑O(shè)計(jì)原則。而本文則更多關(guān)注于局部的代碼問(wèn)題,本文通過(guò)舉例的方式,總結(jié)平時(shí)常犯的錯(cuò)誤和優(yōu)化方式。
本文的例子基于兩個(gè)指導(dǎo)原則:
一.DRY(Don't repeat yourself)
此原則如此重要,簡(jiǎn)單來(lái)說(shuō)是因?yàn)椋?/strong>
-
代碼越少,Bug也越少
-
沒(méi)有重復(fù)邏輯的代碼更易于維護(hù),當(dāng)你修復(fù)了一個(gè)bug,如果相同的邏輯還出現(xiàn)在另外一個(gè)地方,而你沒(méi)意識(shí)到,你有沒(méi)有覺(jué)得自己很冤?
二.TED原則
-
簡(jiǎn)潔(Terse)
-
具有表達(dá)力(Expressive)
-
只做一件事(Do one thing)
三.舉例說(shuō)明
1.拒絕注釋?zhuān)么a來(lái)闡述注釋
反例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
重構(gòu)后:
1 2 3 4 5 6 |
|
良好的代碼命名完全可以替代注釋的作用,如果你正在試圖寫(xiě)一段注釋?zhuān)瑥哪撤N角度來(lái)看,你正在試圖寫(xiě)一段別人無(wú)法理解的代碼。
當(dāng)你無(wú)法為你的方法起一個(gè)準(zhǔn)確的名稱(chēng)時(shí),很可能你的方法不止做了一件事,違反了(Do one thing)。特別是你想在方法名中加入:And,Or,If等詞時(shí)
2. 為布爾變量賦值
反例:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
重構(gòu)后:
1 2 3 4 5 |
|
3.雙重否定的條件判斷
反例:
1 2 3 4 |
|
重構(gòu)后:
1 2 3 4 |
|
不管你有沒(méi)有見(jiàn)過(guò)這樣的條件,反正我見(jiàn)過(guò)。見(jiàn)到這樣的條件判斷,我頓時(shí)就暈了。
4.拒絕HardCode,拒絕挖坑
反例:
1 2 3 4 |
|
重構(gòu)后:
1 2 3 4 |
|
既然咱們玩的是強(qiáng)類(lèi)型語(yǔ)言,咱就用上編譯器的功能,讓錯(cuò)誤發(fā)生在編譯階段
5.拒絕魔數(shù),拒絕挖坑
反例:
1 2 3 4 |
|
重構(gòu)后:
1 2 3 4 5 |
|
所謂魔數(shù)(Magic number)就是一個(gè)魔法數(shù)字,讀者完全弄不明白你這個(gè)數(shù)字是什么,這樣的代碼平時(shí)見(jiàn)的多了
6.復(fù)雜的條件判斷
反例:
1 2 3 4 5 6 7 |
|
重構(gòu)后:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
有沒(méi)有豁然開(kāi)朗的趕腳?
7.嵌套判斷
反例:
1 2 3 4 5 6 7 8 9 10 11 12 |
|
重構(gòu)后:
1 2 3 4 |
|
***種代碼是受到早期的某些思想:使用一個(gè)變量來(lái)存儲(chǔ)返回結(jié)果。事實(shí)證明,你一旦知道了結(jié)果就應(yīng)該盡早返回。
8.使用前置條件
反例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
重構(gòu)后:
1 2 3 |
|
重構(gòu)后的風(fēng)格更接近契約編程,首先要滿(mǎn)足前置條件,否則免談。
9.參數(shù)過(guò)多,超過(guò)3個(gè)
反例:
1 2 3 4 |
|
重構(gòu)后:
1 2 3 4 |
|
過(guò)多的參數(shù)讓讀者難以抓住代碼的意圖,同時(shí)過(guò)多的參數(shù)將會(huì)影響方法的穩(wěn)定性。另外也預(yù)示著參數(shù)應(yīng)該聚合為一個(gè)Model
10.方法簽名中含有布爾參數(shù)
反例:
1 2 3 4 |
|
重構(gòu)后:
1 2 3 4 5 6 7 8 9 |
|
布爾參數(shù)在告訴方法不止做一件事,違反了Do one thing
10.寫(xiě)具有表達(dá)力的代碼
反例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
重構(gòu)后:
1 2 3 4 5 6 7 8 9 |
|
相對(duì)于命令式代碼,聲明性代碼更加具有表達(dá)力,也更簡(jiǎn)潔。這也是函數(shù)式編程為什么越來(lái)越火的原因之一。
四.關(guān)于DRY
平時(shí)大家重構(gòu)代碼,一個(gè)重要的思想就是DRY。我要分享一個(gè)DRY的反例:
項(xiàng)目在架構(gòu)過(guò)程中會(huì)有各種各樣的MODEL層,例如:DomainModel,ViewModel,DTO。很多時(shí)候這幾個(gè)Model里的字段大部分是相同的,于是有人就會(huì)想到DRY原則,干脆直接用一種類(lèi)型,省得粘貼復(fù)制,來(lái)回轉(zhuǎn)換。
這個(gè)反例失敗的根本原因在于:這幾種Model職責(zé)各不相同,雖然大部分情況下內(nèi)容會(huì)有重復(fù),但是他們擔(dān)當(dāng)著各種不同的角色。
考慮這種場(chǎng)景: DomainModel有一個(gè)字段DateTime Birthday{get;set;},ViewModel同樣具有DateTime Birthday{get;set;}。需求升級(jí):要求界面不再顯示生日,只需要顯示是否成年。我們只需要在ViewModel中添加一個(gè)Bool IsAdult{get{return ....}}即可,DomainModel完全不用變化。
五.利用先進(jìn)的生產(chǎn)工具
以vs插件中的Reshaper為例,本文列舉的大部分反例,Reshaprer均能給予不同程度的提示。經(jīng)過(guò)一段時(shí)間的練習(xí),當(dāng)Reshaper對(duì)你的代碼給予不了任何提示的時(shí)候,你的代碼會(huì)有一個(gè)明顯的提高。
截圖說(shuō)明Reshaper的提示功能:
光標(biāo)移動(dòng)在波浪線處,然后Alt+Enter,Resharper 會(huì)自動(dòng)對(duì)代碼進(jìn)行優(yōu)化