今天讓我們來談談代碼吧。代碼重要嗎？固然，代碼就是設計（Jack W.Reeves, 1992）；代碼是最有價值的交付物。我們需要好代碼嗎？在給“好代碼”下個定義之前，這個問題沒法回答。那末，究竟甚么是好代碼？

看下面這段英文解釋：

‘Good code’ is code that works, is bug free, and is readable and maintainable. Some organizations have coding ‘standards’ that all developers are supposed to adhere to, but everyone has different ideas about what’s best, or what is too many or too few rules. There are also various theories and metrics, such as McCabe Complexity metrics. It should be kept in mind that excessive use of standards and rules can stifle productivity and creativity. ‘Peer reviews’, ‘buddy checks’ code analysis tools, etc. can be used to check for problems and enforce standards.

解釋以下：

好的代碼是代碼運行正常、bug很少、并且具有可讀性和可保護性。1些企業自己有所有開發人員都必須遵照的編碼規范，但是對甚么樣的代碼是最好的每一個人的都有自己的標準、或有太多的或太少的編碼規則。這有多種原則和標準，例如，McCable 的復雜度度量。的確使用過量的編碼標準和規則可能下降生產率和創造性。“同行評審”或“同事檢查”代碼分析工具等，都能用來檢查問題或堅持標準。

那末接下來我們深入介紹下，甚么是好代碼的標準呢，請看下面解釋：

1、代碼命名規范：

1、 package包名全部由小寫的ASCII字母組成，用“.”分隔。在此項目中，所有的包均以“com.abc.ticket”開頭。

2、 class 類名應當是名詞，每一個內部單詞的頭1個字母大寫。應當使你的類名簡單和具有說明性。用完全的英語單詞或約定俗成的簡寫命名類名。
【示例】public class UserManager

3、 interface接口名應當是名詞，每一個內部單詞的頭1個字母大寫。應當使你的接口名簡單和具有說明性。用完全的英語單詞或約定俗成的簡寫命名接口名。
【示例】interface TicketManagement

4、 Class 成員屬性及變量的命名 (*) 變量名全部由字母組成，頭1個字母小寫，以后每一個內部單詞的頭1個字母大寫。變量名應當短而成心義。變量名的選擇應當易于記憶。1個字符的變量名應避免，除非用于臨時變量。通常臨時變量名的命名規則為：i，j，k，m，n用于整數；c，d，e用于字符。

5、常量的命名，Java 里的常量，是用static final 修飾的，應當用全大寫加下劃線命名，并且盡可能指出完全含義。
【示例】static final String SMTH_BBS=”bbs.tsinghua.edu.cn”; 

6、數組的命名，數組應當總是用下面的情勢來命名：byte[] buffer; 

7、方法的參數和變量的命名規范1致，且應使用成心義的參數命名，如果可能的話，使用和要賦值的字段1樣的名字。
【示例】setCounter(int size){ this.size = size; } 

8、 方法命名(*)方法的命名應當使用動詞，頭1個字母小寫，以后每一個內部單詞的頭1個字母大寫。在方法名的選擇上應意義明確便于記憶。對屬性的存取方法，應使用getXXX()和setXXX()名稱，以isXXX()，hasXXX()來命名返回值為boolean 類型的方法。

以上幾條如果符合就算是好代碼了嗎？固然不是，這只是代碼中最基本的命名規范而已，就算不符合最多就是代碼不好看，沒甚么其他影響。

2、代碼邏輯規范

1、需求、設計中的重點功能（結合需求/設計的評審產出）

2、代碼格式校驗
action/fa?ade等系統入口是不是有數據格式校驗
需要存入數據庫的數據字段是不是有長度校驗

3、分支/循環
if-else/switch是不是處理了所有分支
分支的條件語句是不是有“副作用”；即，條件語句是不是會改變系統狀態/數據等
循環邊界是不是覆蓋了所有元素
是不是有死循環等

4、異常處理
是不是有“吃掉異常”的情況
是不是記錄了異常日志
如果2次拋出，是不是有公道的異常層次/結構
如果內部處理，對異常的處理是不是能保證后續代碼正常運行

5、單元測試
是不是有單元測試
單元測試是不是自動化
單元測試是不是能完全覆蓋需求

6、 事務處理
事務范圍是不是公道；或說，是不是把沒必要要的操作放到了同1個事務中
事務傳播方式是不是公道（required，never，new等配置）

7、sql語句
sql語句是不是正確
使用mybatis的動態語句時，是不是有潛伏的sql語法問題

8、第3方組件
使用Redis，RabbitMQ等組件，是不是真的對組件完全了解，在使用的進程中是不是正確履行了開啟與關閉操作。

寫到這里，可能會有很多讀者認為，代碼規范也就這些了吧，依照上面2類寫完算是優秀的代碼了嗎？其實還是遠遠不夠。

3、可讀性，可保護性

曾看過1段代碼，1個method幾千行代碼，所有業務邏輯都揉在了1起。然后沒有人愿意再保護了，修改1點就會引發不可預知的毛病，代碼又臭又長。在這類情況只能重構，因而我在部門內部推行2本書《代碼整潔之道》和《重構-改良既有代碼的設計》并且制定部門自己的開發風格，通過組織所有開發人員練習小項目的開發，使全部部門的開發風格整齊劃1，不論是老同事還是新同事，都能夠非常快速的上手，程序中依賴度下降，結構非常清晰。

4、性能瓶頸

在真實工作中，很多程序員其實在開發完程序后不去真正關注程序的性能和響應時間到底如何，憑的是以往開發經驗在開發的進程中盡量的去減少問題點。

這樣就只能在生產環境中去驗證性能問題了，實際這類做法風險較大，所帶來的損失也是較大的，我們在開發完程序后，不但要采取Junit或JMock這樣的工具進行業務功能自測，更重要是能夠采取相應的工具和命令進行代碼性能和響應時間的測試，在第1關就可以夠找出可能出現的1部份問題點，那末常常使用的工具和命令以下：
top，vmstat，pidstat，Hprof，Btrace，Dtrace等命令。

具體可以參考我之前寫過的文章2篇：
http://blog.csdn.net/u013970991/article/details/52035153
http://blog.csdn.net/u013970991/article/details/52035133

5、代碼容錯

• 曾有1個案例：
  X同事在“統1配置管理系統“中將1個參數配置在里面，當參數進行修改的時候相應的程序會馬上做出改變進行相應邏輯調劑，可是另外一個A同事在操作這個系統的時候配錯了參數，這時候候系統在生產環境中就開始報錯，以致于利用程序崩潰，邏輯沒法進行下去造成較嚴重的生產事故，最后恢復完參數故障時間已進行了10幾分鐘。針對這個問題當時產生了爭辯，究竟是配置人員的錯，還是開發人員的錯。

其實在我看來，究竟是誰的問題暫且放在1邊，關鍵是開發人員是不是在寫程序的進程中有無多1絲的思考，多斟酌1些問題點，程序員要時刻懷著1顆懷疑的心和畏敬的心對待自己寫的程序，像上面的問題我們完全可以做1些異常捕獲和默許設置，在出錯的時候最少能夠讓利用程序跑下去而不能整體報錯，讓用戶沒法繼續使用。

• 再說1個案例：
  某部門在開發“統1配置管理系統”，使用的是Zookeeper組件，而且它的工作原理是當某節點改變的時候，主動去通知所注冊的系統，但是有個條件是如果那些系統，有1部份沒有得到通知，有1部份得到了通知該怎樣辦，比如某幾個系統在通知的時候正好在重啟，這時候候zookeeper就不能通知到相應的系統，因而在使用該“統1配置管理系統”的時候，出了生產事故。

其實還應當再重復說1下，程序員應當持有懷疑的精神面對調用的系統和被調用的系統，不要把穩定、安全、可靠寄托于他人身上。

究竟怎樣寫代碼才能算好代碼？這是1個有爭議的話題，每一個人的理解可能都不同，關鍵是通過討論這個話題制定1個符合自己部門要求的規范，這樣有根據的代碼才可能成為好的代碼。