好程式碼的科學定義

本文由碼農網 – 小峰原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

你如何定義好的程式碼？本文通過諮詢65個開發人員同一個問題從而得出了一個偽科學的答案。

首先我們相信寫好程式碼是非常重要的。為什麼呢？首先，好程式碼比差程式碼更有趣，成本更低。其次，程式碼好，就意味著你正在構建的產品有可能會更好。第三，也是非常關鍵的一點，寫出好的程式碼是我們的職責：畢竟，我們的工作就是寫程式碼。

方法

由於此65名開發人員都是我們某個職位的應聘者，所以這意味著這些樣品開發人員大多偏向於使用Java或Scala技能，並且通常有著5年及以上的工作經驗。

問題統一：“怎樣寫好程式碼？你如何定義好程式碼？”並且在面試時由同一人（面對面或通過電話），歷時約1年，從2014年1月至2015年1月，來執行此地調查。

梳理這些問題的答案之後，可以分為31個不同的類，每組至少有2個相似的答案。例如，下面這些答案通通歸納為可讀一類：
可讀。

• 人腦可閱讀。
• 能自我解釋。
• 人們能讀懂。
• 很容易理解。
• 不用5分鐘就能瞭解。
• 沒有文件，你也可以閱讀並理解。
• 可讀，新來的開發人員也能夠理解。
• 就如同文字一樣可讀。
• 易於閱讀，直線化的思維。

結果

這65位開發人員的答案總共統計出288條不同的內容，平均一個人4.43條。

當然，目前最常見的答案是，程式碼必須可讀（78.46％），幾乎10分之8的開發人員認為，好的程式碼應該易於閱讀和理解。

然後是可測試的/測試過的（29.23％），這說明好的程式碼應當是經過自動化測試的（或至少是有可能執行測試的）。25%的受訪者認為，良好的程式碼還應該是簡單的——不過於複雜，當然還應該是可以工作的，意味其能夠按照我們的意願正常執行功能。前五條是，程式碼應該是可維護的（21.54％）。

奇怪的是，我們發現有兩項內容是關於同一主題的：文件和程式碼註釋。有的開發人員認為程式碼應該自文件化（不需要用文件解釋），而有些開發人員則表示應該在程式碼中著重於註解，說明程式碼目的。

其他的，如，可擴充套件的/可重複使用的，恰當的命名規律，程式碼解耦或者稱為小方法的重要性——當然這個“小”在不同開發人員的眼中概念還不一樣：“10-15行”到“<50行”莫衷一是。

探討

面試中的回答給了我們很多有趣的可用於分析的定量資料，而有些資料非常值得一提。下面這些是我們點贊量最多的答案，有的讓我們會心一笑，有的有理有據值得深思：

• 再怎麼測試也不會發生崩潰。
• 不要建立那些並不需要的玩意兒。
• 任何人都需要寫點註釋。好不好以後自然會知道。
• 你看到它，它才有意義。
• 你需要了解業務目的。
• 你需要做的不僅僅是寫程式碼。
• 不需要太過於特立獨行。
• 差的程式碼也能做很多事情，但就是通通做不好。

開發人員重視程式碼的可讀性和可理解性並不奇怪。但是令人有一點點驚訝的是，其餘的回答卻差不多至少有50％的差異！

以下這四條就屬於讓人驚訝的後者：

• 可維護：因為我們大多數人都有過維護別人程式碼的經歷（或者一段時間以後維護自己的程式碼），並且很有可能度過了一段非常悲慘的日子。所以，我們期待更多的開發人員能夠編寫出可維護的程式碼。可能有的人假設程式碼可讀，那麼一定易於維護，所以就忽略了這一條。
• 可工作：編寫程式碼的目的，就是能夠為他人提供價值。編寫可工作的程式碼，是我們的首要任務之一。所以我們很驚訝為什麼並不是每一個開發人員的答案中都囊括這一條。
• 可測試/已測試過的：測試的重要性在這裡我就不多說了，相信大家已經聽到過不知道幾百遍了。
• 高效：話說，答案中包含“高效”的開發人員比強調“不可過早優化”的開發人員，要多兩倍，而眾所周知，“過早的優化是萬惡之源”，所以，這太讓人納悶了。

最後，我們總結出好程式碼的定義：

“好的程式碼是可讀的，可理解的，覆蓋了自動化測試的，不過於複雜，並且能辦好我們需要它做的事情。”

聽起來就相當美，right？