隨著軟體行業的不斷髮展，歷史遺留的程式越來越多，程式碼的維護成本越來越大，甚至大於開發成本。而新功能的開發又常常依賴於舊程式碼，閱讀舊程式碼所花費的時間幾乎要大於寫新功能的程式碼。
我前幾天看了一本書，書中有這麼一句話：
“複雜的程式碼往往都是新手所寫，只有經驗老道的高手才能寫出簡單，富有表現力的程式碼”
此話雖然說的有點誇張，可是也說明了經驗的重要性。
我們所寫的程式碼除了讓機器執行外，還需要別人來閱讀。所以我們要：
- 寫讓別人能讀懂的程式碼
- 寫可擴充套件的程式碼
- 寫可測試的程式碼(程式碼應該具備可測試性，對沒有可測試性的程式碼寫測試，是浪費生命的表現)
其中2，3點更多強調的是物件導向的設計原則。而本文則更多關注於區域性的程式碼問題，本文通過舉例的方式，總結平時常犯的錯誤和優化方式。
本文的例子基於兩個指導原則：
一.DRY(Don’t repeat yourself)
此原則如此重要，簡單來說是因為：
- 程式碼越少，Bug也越少
- 沒有重複邏輯的程式碼更易於維護，當你修復了一個bug，如果相同的邏輯還出現在另外一個地方，而你沒意識到，你有沒有覺得自己很冤？
二.TED原則
- 簡潔(Terse)
- 具有表達力(Expressive)
- 只做一件事(Do one thing)
三.舉例說明
1.拒絕註釋，用程式碼來闡述註釋
反例：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
/// <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; } |
重構後：
|
1 2 3 4 5 6 |
public decimal CalculateTotalCash() { var prices=new List<decimal>(){2m,3m,10m}; var itemCount = 2; return prices.Sum(p => p*itemCount); } |
良好的程式碼命名完全可以替代註釋的作用，如果你正在試圖寫一段註釋，從某種角度來看，你正在試圖寫一段別人無法理解的程式碼。
當你無法為你的方法起一個準確的名稱時，很可能你的方法不止做了一件事，違反了(Do one thing)。特別是你想在方法名中加入：And，Or，If等詞時
2. 為布林變數賦值
反例：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
public bool IsAdult(int age) { bool isAdult; if (age > 18) { isAdult = true; } else { isAdult = false; } return isAdult; } |
重構後：
|
1 2 3 4 5 |
public bool IsAdult(int age) { var isAdult = age > 18; return isAdult; } |
3.雙重否定的條件判斷
反例：
|
1 2 3 4 |
if (!isNotRemeberMe) { } |
重構後：
|
1 2 3 4 |
if (isRemeberMe) { } |
不管你有沒有見過這樣的條件，反正我見過。見到這樣的條件判斷，我頓時就暈了。
4.拒絕HardCode,拒絕挖坑
反例：
|
1 2 3 4 |
if (carName == "Nissan") { } |
重構後：
|
1 2 3 4 |
if (car == Car.Nissan) { } |
既然我們們玩的是強型別語言，我們就用上編譯器的功能，讓錯誤發生的編譯階段
5.拒絕魔數，拒絕挖坑
反例：
|
1 2 3 4 |
if (age > 18) { } |
重構後：
|
1 2 3 4 5 |
const int adultAge = 18; if (age > adultAge) { } |
所謂魔數(Magic number)就是一個魔法數字，讀者完全弄不明白你這個數字是什麼，這樣的程式碼平時見的多了
6.複雜的條件判斷
反例：
|
1 2 3 4 5 6 7 |
if (job.JobState == JobState.New || job.JobState == JobState.Submitted || job.JobState == JobState.Expired || job.JobTitle.IsNullOrWhiteSpace()) { //.... } |
重構後：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
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.巢狀判斷
反例：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
var isValid = false; if (!string.IsNullOrEmpty(user.UserName)) { if (!string.IsNullOrEmpty(user.Password)) { if (!string.IsNullOrEmpty(user.Email)) { isValid = true; } } } return isValid; |
重構後：
|
1 2 3 4 |
if (string.IsNullOrEmpty(user.UserName)) return false; if (string.IsNullOrEmpty(user.Password)) return false; if (string.IsNullOrEmpty(user.Email)) return false; return true; |
第一種程式碼是受到早期的某些思想：使用一個變數來儲存返回結果。事實證明，你一旦知道了結果就應該儘早返回。
8.使用前置條件
反例：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
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"); } |
重構後：
|
1 2 3 |
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 |
重構後的風格更接近契約程式設計，首先要滿足前置條件，否則免談。
9.引數過多，超過3個
反例：
|
1 2 3 4 |
public void RegisterUser(string userName, string password, string email, string phone) { } |
重構後：
|
1 2 3 4 |
public void RegisterUser(User user) { } |
過多的引數讓讀者難以抓住程式碼的意圖，同時過多的引數將會影響方法的穩定性。另外也預示著引數應該聚合為一個Model
10.方法簽名中含有布林引數
反例：
|
1 2 3 4 |
public void RegisterUser(User user, bool sendEmail) { } |
重構後：
|
1 2 3 4 5 6 7 8 9 |
public void RegisterUser(User user) { } public void SendEmail(User user) { } |
布林引數在告訴方法不止做一件事，違反了Do one thing
10.寫具有表達力的程式碼
反例：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
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; } |
重構後：
|
1 2 3 4 5 6 7 8 9 |
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; } |
相對於命令式程式碼，宣告性程式碼更加具有表達力，也更簡潔。這也是函數語言程式設計為什麼越來越火的原因之一。
四.關於DRY
平時大家重構程式碼，一個重要的思想就是DRY。我要分享一個DRY的反例：
專案在架構過程中會有各種各樣的MODEL層，例如：DomainModel，ViewModel，DTO。很多時候這幾個Model裡的欄位大部分是相同的，於是有人就會想到DRY原則，乾脆直接用一種型別，省得貼上複製，來回轉換。
這個反例失敗的根本原因在於：這幾種Model職責各不相同，雖然大部分情況下內容會有重複，但是他們擔當著各種不同的角色。
考慮這種場景： DomainModel有一個欄位DateTime Birthday{get;set;}，ViewModel同樣具有DateTime Birthday{get;set;}。需求升級:要求介面不再顯示生日，只需要顯示是否成年。我們只需要在ViewModel中新增一個Bool IsAdult{get{return ….}}即可，DomainModel完全不用變化。
五.利用先進的生產工具
以vs外掛中的Reshaper為例，本文列舉的大部分反例，Reshaprer均能給予不同程度的提示。經過一段時間的練習，當你的程式碼Reshaper給予不了任何提示的時候，你的程式碼會有一個明顯的提高。
截圖說明Reshaper的提示功能：
游標移動在波浪線處，然後Alt+Enter,Resharper 會自動對程式碼進行優化