陳太漢:軟體隨想之編寫出色的程式碼

發表於2012-05-21

來源:陳太漢

1:寫不易出錯的程式碼

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

There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.

 

 

2:寫容易查錯的程式碼

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

 

3:寫擴充套件性好的程式碼

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

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

 

4:寫高效能的程式碼

這是我一直渴望的(我當然也會說是我還沒有做到的)。我覺得要寫出高效的程式碼首先要非常明白你要實現的功能,將功能分析得很透徹,你找到了解決方案,回想你的實現,如果你的思路非常清晰,你就大致知道每一步是否夠好,大致知道你的程式碼是否高效,或者更進一步說,你確定這就是最優解;如果功能實現了,但是你對自己實現的功能不是很瞭解,記憶模糊,那肯定不是最優解,你肯定會對自己不是很清楚的程式碼不放心(我經常是這樣),就別談效能,是否正確都待定。很多高效的程式碼都很簡潔,容易理解,而有些程式碼總讓人看起來很鬱悶,如一堆看起來類似的程式碼實現一個很簡單的功能。用陣列和一個迴圈經常能將這樣的程式碼簡化,讓你輕鬆實現簡潔容易理解的程式碼,或許它不是最高效的。82法則告訴我們,我們應該對影響系統效能的20%的程式碼進行優化,而不應對其他的80%的程式碼耿耿於懷。20%影響效能的程式碼應注重效能進行優化,而其他80%則更多應該考慮理解性,擴充套件性等。

 

高手的程式碼特點有很多,很多優點是並存的。上面只是我個人認為最重要的四點。

 

相關文章