來源:陳太漢
1:寫不易出錯的程式碼
第一次聽說“寫明顯沒有什麼錯誤的程式碼”時,我覺得這個說法很新鮮,讓我記憶深刻。其他的很多觀點聽得我耳朵生繭,基本都是左耳進右耳出。明顯沒有什麼錯誤的程式碼肯定是思路清晰、很容易理解的。而要做到這點很難,牛人才能寫出牛叉的程式碼,要做到這一點要有足夠的閱歷和實戰,只能當做目標啦,哪天也和雲風一樣:今天完成了XX功能,程式碼明顯沒有什麼錯誤。現在還不知道明顯沒有什麼錯誤的程式碼是怎麼樣的,但我知道很多程式碼讓我半天不知所云。如從類名和方法名看不出其職能;變數命名讓人蛋疼;不對引數做任何驗證;引數到處都是都是基本型別;方法引數十幾個;一個方法幾屏;不能適應半點變化的方法;要麼沒有註釋,要麼一堆廢話;排版稀爛。這些都是不好理解,半天找不到問題的程式碼,也是容易出錯的程式碼。
2:寫容易查錯的程式碼
一直想寫很乾淨的程式碼,程式碼除了功能沒有多餘的程式碼,但是程式碼必須有日誌,如果程式碼沒有日誌,要是出錯了,查錯肯定很麻煩,有時候真的是無從下手,一個功能涉及到一堆的模組,要想很快的定位錯誤,就必須記好日誌。越清楚越好,程式執行到哪一步,當前的狀態最好都要記下來,日誌不在多,清楚記錄有效的日誌非常重要,過多無效的日誌不方便檢視,而且對於快速定位錯誤的位置沒有任何幫助。如果日誌都記錄在文字檔案中,最好能寫一個分析日誌的工具。可能是我寫的和維護的程式碼太容易出錯了,個人覺得記好日誌真他媽重要。一看到日誌就能知道出了什麼問題那不是一般的爽,當然聽說又出問題了讓人鬱悶。我以前所在的一家公司記錄日誌的方式是在很多類中都定義一個int型別的成員變數,每隔幾行讓它自增1,將這個值記錄起來,當出錯了就能大致估計是哪幾行出錯了。這種方法雖然有點蹩腳,程式碼中到處是這個變數,但的確能幫助我們快速定位錯誤的位置,日誌的作用就是儲存案發現場,只有記錄犯罪分子作案的過程才能更好的抓住它。
3:寫擴充套件性好的程式碼
“今天說要這樣,明天說要那樣,在上線的前一天說:還是覺得開始的做法是最好的”。而我們程式設計師總是為這種人2B的想法買單。寫擴充套件性好的程式碼真的就是不僅要滿足需求還要超越需求。我們到處可以聽到這樣的口號,當然很多情況下是這樣的人自己都不知道需求是什麼。最讓人無語的是菜鳥提需求,我來實現。殺了我吧。但現實是殺了我之前我先要滿足他的需求。當這種需求像滔滔江水綿延不絕的襲來時,我想到了四個字:生不如死。既然死不了,生活還得繼續。程式碼還是要做到超越需求(你說這世界對程式設計師要求怎麼就這麼高呢),要做到這點難啊,我們是幫別人實現夢想的開拓者。前途是光明的,道路是坎坷的,現實是殘酷的,程式碼必須是擴充套件性好的。當然這裡所說都是人為因素。
還有就是專案的需求本來就是變化的,或者說你現在完成的是一期,還有二期,三期……,你在做的時候就必須考慮這些情況,不要把程式碼寫死。我以前總是想:這個可能以後不會變化,可以寫死,少一個引數,少一個變數效能會更好寫。其實效能的提升相當於一個千萬富翁突然多了幾毛錢。但是要是以後需求變了,你就得改寫程式碼,還得擔心是否會出問題。有時候我就有點怕重構,就怕一個好的功能,被重構壞了,當然也和時間緊,測試不專業有關。寫擴充套件性好的程式碼別在乎所謂的那點效能,那真的就是九牛一毛不值一提。一個專案維護時間久了,發現那些本來看是不變的很多都變了,而程式碼也被改了很多次,每一次修改就要做一堆本來沒有必要的事情(修改程式碼,寫測試說明,送測,協調上線,而這些溝通時間也不少,真叫一個低效浪費時間),如果能考慮到可能發生的變化,寫好程式碼,效率會高很多,這一點就能體現高手和菜鳥的區別。
4:寫高效能的程式碼
這是我一直渴望的(我當然也會說是我還沒有做到的)。我覺得要寫出高效的程式碼首先要非常明白你要實現的功能,將功能分析得很透徹,你找到了解決方案,回想你的實現,如果你的思路非常清晰,你就大致知道每一步是否夠好,大致知道你的程式碼是否高效,或者更進一步說,你確定這就是最優解;如果功能實現了,但是你對自己實現的功能不是很瞭解,記憶模糊,那肯定不是最優解,你肯定會對自己不是很清楚的程式碼不放心(我經常是這樣),就別談效能,是否正確都待定。很多高效的程式碼都很簡潔,容易理解,而有些程式碼總讓人看起來很鬱悶,如一堆看起來類似的程式碼實現一個很簡單的功能。用陣列和一個迴圈經常能將這樣的程式碼簡化,讓你輕鬆實現簡潔容易理解的程式碼,或許它不是最高效的。82法則告訴我們,我們應該對影響系統效能的20%的程式碼進行優化,而不應對其他的80%的程式碼耿耿於懷。20%影響效能的程式碼應注重效能進行優化,而其他80%則更多應該考慮理解性,擴充套件性等。
高手的程式碼特點有很多,很多優點是並存的。上面只是我個人認為最重要的四點。