你的代碼完成了嗎？（之二）——可維護性和規范性

二. 可維護性和規范性

對于代碼來說，這兩個屬性其實是緊密相連的。什么樣的代碼最好維護呢？當然是規范的代碼了。再差的規范也要比沒有規范強得多。

之前做對日項目的時候，日本人對于“規范”這個東西（他們稱之為開發規約）要求的極為嚴格。一方面會制定嚴格的規范來供大家遵守，其中不僅僅會包括對命名、代碼格式的規定，甚至還包括了每個控件之間的距離，代碼的注釋的格式，代碼中的注釋要達到什么樣的比例，每種代碼結構（循環、選擇等等）要怎么寫，什么時候應該加空行等等，一般他們的代碼規范都至少會有10頁左右的內容。另一方面，他們還制定了比較完備的流程來保證規范的執行，代碼開發完畢，首先是要進行代碼Review，然后是進行單體測試。這兩個過程并非是在某些國內項目中，就是走個過場，在對日的項目中甚至還制定了標準，每千行代碼中必須Review出多少個問題，必須要測試出多少個Bug，都是有數量限制的，如果達不到標準，除非有充分的理由，否則這個過程是無法通過的。

經過了這么多嚴格的過程之后，對日項目想要達到的目的就是“所有代碼看起來像是一個人寫的”。盡管這有些理想化，畢竟每個人處理問題的思路還是會有些不同，但僅就代碼來說，的確看起來干干凈凈，就像是同一個人編寫的一樣。自然在維護的時候，看起來至少不會有太嚴重的問題。

相反，在某些國內項目中，對于代碼規范的重視程度明顯不夠，很多代碼中連最基本的縮進和命名問題都沒有解決好，更別提每個方法的長度，類和接口的設計等問題了。有時，不得不對那樣的代碼進行修改的時候，我都會先把規范整理一遍，然后再開始修改。但是，就像破窗子理論一樣，有時心情不爽的時候，根本就不會做修改，甚至還會加入更多的不符合規范的東西。（那種情況是極少的了，哈哈。而且我不會署名啊，偷偷地閃！）

由此看來，新編寫的代碼是否遵從了代碼規范會給以后的維護和修改工作帶來很大的影響。

可維護性體現在什么地方呢？我覺得就在于對現有的程序進行修改的時候，能否快速定位到問題所在，而且在讀代碼的時候，很容易就能理解代碼所要完成的工作，那樣才能夠更快速有效地對代碼進行修改。

在此必然會涉及到注釋的問題，關于這個東西的討論已經有很多了，我的觀點是，如果能夠用較好的命名和清晰的代碼說明的問題，就可以不寫注釋了。相反，如果僅僅看代碼無法理解的東西，尤其是業務上的知識，或者是業務流程上的一些特殊的要求，就非常有必要寫上注釋，否則以后維護的人就不明白其所以然了。而對于對日項目中規定代碼中的注釋率要有多少，就有些過分了。

對于自身來說，想要編寫規范和可維護的代碼，其實也不是很難的事兒，主要在于態度。記得當初我給公司的新人培訓的時候，曾經說過：“我們應該編寫什么樣的代碼呢？我覺得有一個原則，那就是別人在以后修改、維護你寫的代碼的時候，不會一邊改，一邊罵人，他***，這是誰寫的鬼代碼，讓我有打人的沖動。”呵呵，玩笑而已，但還是能說明一些問題的吧。

?