軟體随想--寫牛B的代碼

1：寫不易出錯的代碼

第一次聽說“寫明顯沒有什麼錯誤的代碼”時，我覺得這個說法很新鮮，讓我記憶深刻。其他的很多觀點聽得我耳朵生繭，基本都是左耳進右耳出。明顯沒有什麼錯了的代碼肯定是思路清晰、很容易了解的。而要做到這點很難，牛人才能寫出牛叉的代碼，要做到這一點要有足夠的閱曆和實戰，隻能當做目标啦，哪天也和雲風一樣：今天完成了XX功能，代碼明顯沒有什麼錯誤。現在還不知道明顯沒有什麼錯誤的代碼是怎麼樣的，但我知道很多代碼讓我半天不知所雲。如從類名和方法名看不出其職能；變量命名讓人蛋疼；不對參數做任何驗證；參數到處都是都是基本類型；方法參數十幾個；一個方法幾屏；不能适應半點變化的方法；要麼沒有注釋，要麼一堆廢話；排版稀爛。這些都是不好了解，半天找不到問題的代碼，也是容易出錯的代碼。

2：寫容易查錯的代碼

一直想寫很幹淨的代碼，代碼除了功能沒有多餘的代碼，但是代碼必須有日志，如果代碼沒有日志，要是出錯了，查錯肯定很麻煩，有時候真的是無從下手，一個功能涉及到一堆的子產品，要想很快的定位錯誤，就必須記好日志。越清楚越好，程式執行到哪一步，目前的狀态最好都要記下來，日志不在多，清楚記錄有效的日志非常重要，過多無效的日志不友善檢視，而且對于快速定位錯誤的位置沒有任何幫助。如果日志都記錄在文本檔案中，最好能寫一個分析日志的工具。可能是我寫的和維護的代碼太容易出錯了，個人覺得記好日志真他媽重要。一看到日志就能知道出了什麼問題那不是一般的爽，當然聽說又出問題了讓人郁悶。我以前所在的一家公司記錄日志的方式是在很多類中都定義一個int類型的成員變量，每隔幾行讓它自增1，将這個值記錄起來，當出錯了就能大緻估計是哪幾行出錯了。這種方法雖然有點蹩腳，代碼中到處是這個變量，但的确能幫助我們快速定位錯誤的位置，日志的作用就是儲存案發現場，隻有記錄犯罪分子作案的過程才能更好的抓住它。

3：寫擴充性好的代碼

“今天說要這樣，明天說要那樣，在上線的前一天說：還是覺得開始的做法是最好的”。而我們程式員總是為這種人2B的想法買單。寫擴充性好的代碼真的就是不僅要滿足需求還要超越需求。我們到處可以聽到這樣的口号，當然很多情況下是這樣的人自己都不知道需求是什麼。最讓人無語的是菜鳥提需求，我來實作。殺了我吧。但現實是殺了我之前我先要滿足他的需求。當這種需求像滔滔江水綿延不絕的襲來時，我想到了四個字：生不如死。既然死不了，生活還得繼續。代碼還是要做到超越需求（你說這世界對程式員要求怎麼就這麼高呢），要做到這點難啊，我們是幫别人實作夢想的開拓者。前途是光明的，道路是坎坷的，現實是殘酷的，代碼必須是擴充性好的。當然這裡所說都是人為因素。

還有就是項目的需求本來就是變化的，或者說你現在完成的是一期，還有二期，三期......，你在做的時候就必須考慮這些情況，不要把代碼寫死。我以前總是想：這個可能以後不會變化，可以寫死，少一個參數，少一個變量性能會更好寫。其實性能的提升相當于一個千萬富翁突然多了幾毛錢。但是要是以後需求變了，你就得改寫代碼，還得擔心是否會出問題。有時候我就有點怕重構，就怕一個好的功能，被重構壞了，當然也和時間緊，測試不專業有關。寫擴充性好的代碼别在乎所謂的那點性能，那真的就是九牛一毛不值一提。一個項目維護時間久了，發現那些本來看是不變的很多都變了，而代碼也被改了很多次，每一次修改就要做一堆本來沒有必要的事情（修改代碼，寫測試說明，送測，協調上線，而這些溝通時間也不少，真叫一個低效浪費時間），如果能考慮到可能發生的變化，寫好代碼，效率會高很多，這一點就能展現高手和菜鳥的差別。

4：寫高性能的代碼

這是我一直渴望的（我當然也會說是我還沒有做到的）。我覺得要寫出高效的代碼首先要非常明白你要實作的功能，将功能分析得很透徹，你找到了解決方案，回想你的實作，如果你的思路非常清晰，你就大緻知道每一步是否夠好，大緻知道你的代碼是否高效，或者更進一步說，你确定這就是最優解；如果功能實作了，但是你對自己實作的功能不是很了解，記憶模糊，那肯定不是最優解，你肯定會對自己不是很清楚的代碼不放心（我經常是這樣），就别談性能，是否正确都待定。很多高效的代碼都很簡潔，容易了解，而有些代碼總讓人看起來很郁悶，如一堆看起來類似的代碼實作一個很簡單的功能。用數組和一個循環經常能将這樣的代碼簡化，讓你輕松實作簡潔容易了解的代碼，或許它不是最高效的。82法則告訴我們，我們應該對影響系統性能的20%的代碼進行優化，而不應對其他的80%的代碼耿耿于懷。20%影響性能的代碼應注重性能進行優化，而其他80%則更多應該考慮了解性，擴充性等。

高手的代碼特點有很多，很多優點是并存的。上面隻是我個人認為最重要的四點。

順便說一句：蛋扯多了才能扯得更好。