寫讓別人能讀懂的優(yōu)質(zhì)代碼
隨著軟件行業(yè)的不斷發(fā)展，歷史遺留的程序越來越多，代碼的維護(hù)成本越來越大，甚至大于開發(fā)成本。而新功能的開發(fā)又常常依賴于舊代碼，閱讀舊代碼所花費(fèi)的時間幾乎要大于寫新功能的代碼。
我前幾天看了一本書，書中有這么一句話：
“復(fù)雜的代碼往往都是新手所寫，只有經(jīng)驗(yàn)老道的高手才能寫出簡單，富有表現(xiàn)力的代碼”
此話雖然說的有點(diǎn)夸張，可是也說明了經(jīng)驗(yàn)的重要性。
我們所寫的代碼除了讓機(jī)器執(zhí)行外，還需要別人來閱讀。所以我們要寫：
- 讓別人能讀懂的代碼
- 可擴(kuò)展的代碼
- 可測試的代碼(代碼應(yīng)該具備可測試性，對沒有可測試性的代碼寫測試，是浪費(fèi)生命的表現(xiàn))
其中2，3點(diǎn)更多強(qiáng)調(diào)的是面向?qū)ο蟮脑O(shè)計原則。而本文則更多關(guān)注于局部的代碼問題，本文通過舉例的方式，總結(jié)平時常犯的錯誤和優(yōu)化方式。
本文的例子基于兩個指導(dǎo)原則：
一.DRY(Don't repeat yourself)
此原則如此重要，簡單來說是因?yàn)椋?/p>
- 代碼越少，Bug也越少
- 沒有重復(fù)邏輯的代碼更易于維護(hù)，當(dāng)你修復(fù)了一個bug，如果相同的邏輯還出現(xiàn)在另外一個地方，而你沒意識到，你有沒有覺得自己很冤？
二.TED原則
- 簡潔(Terse)
- 具有表達(dá)力(Expressive)
- 只做一件事(Do one thing)
三.舉例說明
1.拒絕注釋，用代碼來闡述注釋
反例：
- /// <summary>
- /// !@#$%^&^&*((!@#$%^&^&*((!@#$%^&^&*((!@#$%^&^&*((
- /// </summary>
- /// <returns></returns>
- public decimal GetCash()
- {
- //!@#$%^&^&*((!@#$%^&^&*((
- var a = new List<decimal>() { 2m, 3m, 10m };
- var b = 2;
- var c = 0m;
- //!@#$%^&^&*((!@#$%^&^&*((!@#$%^&^&*((
- foreach (var p in a)
- {
- c += p*b;
- }
- return c;
- }
重構(gòu)后：
- public decimal CalculateTotalCash()
- {
- var prices=new List<decimal>(){2m,3m,10m};
- var itemCount = 2;
- return prices.Sum(p => p*itemCount);
- }
良好的代碼命名完全可以替代注釋的作用，如果你正在試圖寫一段注釋，從某種角度來看，你正在試圖寫一段別人無法理解的代碼。
當(dāng)你無法為你的方法起一個準(zhǔn)確的名稱時，很可能你的方法不止做了一件事，違反了(Do one thing)。特別是你想在方法名中加入：And，Or，If等詞時
2. 為布爾變量賦值
反例：
- public bool IsAdult(int age)
- {
- bool isAdult;
- if (age > 18)
- {
- isAdult = true;
- }
- else
- {
- isAdult = false;
- }
- return isAdult;
- }
重構(gòu)后：
- public bool IsAdult(int age)
- {
- var isAdult = age > 18;
- return isAdult;
- }
3.雙重否定的條件判斷
反例：
- if (!isNotRemeberMe)
- {
- }
重構(gòu)后：
- if (isRemeberMe)
- {
- }
不管你有沒有見過這樣的條件，反正我見過。見到這樣的條件判斷，我頓時就暈了。
4.拒絕HardCode,拒絕挖坑
反例：
- if (carName == "Nissan")
- {
- }
重構(gòu)后：
- if (car == Car.Nissan)
- {
- }
既然咱們玩的是強(qiáng)類型語言，咱就用上編譯器的功能，讓錯誤發(fā)生在編譯階段
5.拒絕魔數(shù)，拒絕挖坑
反例：
- if (age > 18)
- {
- }
重構(gòu)后：
- const int adultAge = 18;
- if (age > adultAge)
- {
- }
所謂魔數(shù)(Magic number)就是一個魔法數(shù)字，讀者完全弄不明白你這個數(shù)字是什么，這樣的代碼平時見的多了
6.復(fù)雜的條件判斷
反例：
- if (job.JobState == JobState.New
- || job.JobState == JobState.Submitted
- || job.JobState == JobState.Expired
- || job.JobTitle.IsNullOrWhiteSpace())
- {
- //....
- }
重構(gòu)后：
- if (CanBeDeleted(job))
- {
- //
- }
- private bool CanBeDeleted(Job job)
- {
- var invalidJobState = job.JobState == JobState.New
- || job.JobState == JobState.Submitted
- || job.JobState == JobState.Expired;
- var invalidJob = string.IsNullOrEmpty(job.JobTitle);
- return invalidJobState || invalidJob;
- }
有沒有豁然開朗的趕腳？
7.嵌套判斷
反例：
- var isValid = false;
- if (!string.IsNullOrEmpty(user.UserName))
- {
- if (!string.IsNullOrEmpty(user.Password))
- {
- if (!string.IsNullOrEmpty(user.Email))
- {
- isValid = true;
- }
- }
- }
- return isValid;
重構(gòu)后：
- if (string.IsNullOrEmpty(user.UserName)) return false;
- if (string.IsNullOrEmpty(user.Password)) return false;
- if (string.IsNullOrEmpty(user.Email)) return false;
- return true;
***種代碼是受到早期的某些思想：使用一個變量來存儲返回結(jié)果。事實(shí)證明，你一旦知道了結(jié)果就應(yīng)該盡早返回。
8.使用前置條件
反例：
- if (!string.IsNullOrEmpty(userName))
- {
- if (!string.IsNullOrEmpty(password))
- {
- //register
- }
- else
- {
- throw new ArgumentException("user password can not be empty");
- }
- }
- else
- {
- throw new ArgumentException("user name can not be empty");
- }
重構(gòu)后：
- if (string.IsNullOrEmpty(userName)) throw new ArgumentException("user name can not be empty");
- if (string.IsNullOrEmpty(password)) throw new ArgumentException("user password can not be empty");
- //register
重構(gòu)后的風(fēng)格更接近契約編程，首先要滿足前置條件，否則免談。
9.參數(shù)過多，超過3個
反例：
- public void RegisterUser(string userName, string password, string email, string phone)
- {
- }
重構(gòu)后：
- public void RegisterUser(User user)
- {
- }
過多的參數(shù)讓讀者難以抓住代碼的意圖，同時過多的參數(shù)將會影響方法的穩(wěn)定性。另外也預(yù)示著參數(shù)應(yīng)該聚合為一個Model
10.方法簽名中含有布爾參數(shù)
反例：
- public void RegisterUser(User user, bool sendEmail)
- {
- }
重構(gòu)后：
- public void RegisterUser(User user)
- {
- }
- public void SendEmail(User user)
- {
- }
布爾參數(shù)在告訴方法不止做一件事，違反了Do one thing
10.寫具有表達(dá)力的代碼
反例：
- private string CombineTechnicalBookNameOfAuthor(List<Book> books, string author)
- {
- var filterBooks = new List<Book>();
- foreach (var book in books)
- {
- if (book.Category == BookCategory.Technical && book.Author == author)
- {
- filterBooks.Add(book);
- }
- }
- var name = "";
- foreach (var book in filterBooks)
- {
- name += book.Name + "|";
- }
- return name;
- }
重構(gòu)后：
- private string CombineTechnicalBookNameOfAuthor(List<Book> books, string author)
- {
- var combinedName = books.Where(b => b.Category == BookCategory.Technical)
- .Where(b => b.Author == author)
- .Select(b => b.Name)
- .Aggregate((a, b) => a + "|" + b);
- return combinedName;
- }
相對于命令式代碼，聲明性代碼更加具有表達(dá)力，也更簡潔。這也是函數(shù)式編程為什么越來越火的原因之一。
四.關(guān)于DRY
平時大家重構(gòu)代碼，一個重要的思想就是DRY。我要分享一個DRY的反例：
項目在架構(gòu)過程中會有各種各樣的MODEL層，例如：DomainModel，ViewModel，DTO。很多時候這幾個Model里的字段大部分是相同的，于是有人就會想到DRY原則，干脆直接用一種類型，省得粘貼復(fù)制，來回轉(zhuǎn)換。
這個反例失敗的根本原因在于：這幾種Model職責(zé)各不相同，雖然大部分情況下內(nèi)容會有重復(fù)，但是他們擔(dān)當(dāng)著各種不同的角色。
考慮這種場景： DomainModel有一個字段DateTime Birthday{get;set;}，ViewModel同樣具有DateTime Birthday{get;set;}。需求升級:要求界面不再顯示生日，只需要顯示是否成年。我們只需要在ViewModel中添加一個Bool IsAdult{get{return ....}}即可，DomainModel完全不用變化。
五.利用先進(jìn)的生產(chǎn)工具
以vs插件中的Reshaper為例，本文列舉的大部分反例，Reshaprer均能給予不同程度的提示。經(jīng)過一段時間的練習(xí)，當(dāng)Reshaper對你的代碼給予不了任何提示的時候，你的代碼會有一個明顯的提高。
截圖說明Reshaper的提示功能：
光標(biāo)移動在波浪線處，然后Alt+Enter,Resharper 會自動對代碼進(jìn)行優(yōu)化
如果你能夠避免本文總結(jié)的反例，你的代碼就已經(jīng)具備了優(yōu)秀代碼應(yīng)有的基因。當(dāng)然高質(zhì)量的代碼還需要良好的設(shè)計和遵循面向?qū)ο缶幊痰脑瓌t。 如果想了解更多相關(guān)內(nèi)容，請閱讀《代碼大全》，《代碼整潔之道》，《重構(gòu) 改善既有代碼的設(shè)計》，《敏捷軟件開發(fā) 原則、模式與實(shí)踐》
