今天讓我們來(lái)談?wù)劥a吧。代碼重要嗎？固然，代碼就是設(shè)計(jì)（Jack W.Reeves, 1992）；代碼是最有價(jià)值的交付物。我們需要好代碼嗎？在給“好代碼”下個(gè)定義之前，這個(gè)問(wèn)題沒(méi)法回答。那末，究竟甚么是好代碼？

看下面這段英文解釋：

‘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.

解釋以下：

好的代碼是代碼運(yùn)行正常、bug很少、并且具有可讀性和可保護(hù)性。1些企業(yè)自己有所有開(kāi)發(fā)人員都必須遵照的編碼規(guī)范，但是對(duì)甚么樣的代碼是最好的每一個(gè)人的都有自己的標(biāo)準(zhǔn)、或有太多的或太少的編碼規(guī)則。這有多種原則和標(biāo)準(zhǔn)，例如，McCable 的復(fù)雜度度量。的確使用過(guò)量的編碼標(biāo)準(zhǔn)和規(guī)則可能下降生產(chǎn)率和創(chuàng)造性?！巴性u(píng)審”或“同事檢查”代碼分析工具等，都能用來(lái)檢查問(wèn)題或堅(jiān)持標(biāo)準(zhǔn)。

那末接下來(lái)我們深入介紹下，甚么是好代碼的標(biāo)準(zhǔn)呢，請(qǐng)看下面解釋：

1、代碼命名規(guī)范：

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

2、 class 類名應(yīng)當(dāng)是名詞，每一個(gè)內(nèi)部單詞的頭1個(gè)字母大寫(xiě)。應(yīng)當(dāng)使你的類名簡(jiǎn)單和具有說(shuō)明性。用完全的英語(yǔ)單詞或約定俗成的簡(jiǎn)寫(xiě)命名類名。
【示例】public class UserManager

3、 interface接口名應(yīng)當(dāng)是名詞，每一個(gè)內(nèi)部單詞的頭1個(gè)字母大寫(xiě)。應(yīng)當(dāng)使你的接口名簡(jiǎn)單和具有說(shuō)明性。用完全的英語(yǔ)單詞或約定俗成的簡(jiǎn)寫(xiě)命名接口名。
【示例】interface TicketManagement

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

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

6、數(shù)組的命名，數(shù)組應(yīng)當(dāng)總是用下面的情勢(shì)來(lái)命名：byte[] buffer; 

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

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

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

2、代碼邏輯規(guī)范

1、需求、設(shè)計(jì)中的重點(diǎn)功能（結(jié)合需求/設(shè)計(jì)的評(píng)審產(chǎn)出）

2、代碼格式校驗(yàn)
action/fa?ade等系統(tǒng)入口是不是有數(shù)據(jù)格式校驗(yàn)
需要存入數(shù)據(jù)庫(kù)的數(shù)據(jù)字段是不是有長(zhǎng)度校驗(yàn)

3、分支/循環(huán)
if-else/switch是不是處理了所有分支
分支的條件語(yǔ)句是不是有“副作用”；即，條件語(yǔ)句是不是會(huì)改變系統(tǒng)狀態(tài)/數(shù)據(jù)等
循環(huán)邊界是不是覆蓋了所有元素
是不是有死循環(huán)等

4、異常處理
是不是有“吃掉異?！钡那闆r
是不是記錄了異常日志
如果2次拋出，是不是有公道的異常層次/結(jié)構(gòu)
如果內(nèi)部處理，對(duì)異常的處理是不是能保證后續(xù)代碼正常運(yùn)行

5、單元測(cè)試
是不是有單元測(cè)試
單元測(cè)試是不是自動(dòng)化
單元測(cè)試是不是能完全覆蓋需求

6、 事務(wù)處理
事務(wù)范圍是不是公道；或說(shuō)，是不是把沒(méi)必要要的操作放到了同1個(gè)事務(wù)中
事務(wù)傳播方式是不是公道（required，never，new等配置）

7、sql語(yǔ)句
sql語(yǔ)句是不是正確
使用mybatis的動(dòng)態(tài)語(yǔ)句時(shí)，是不是有潛伏的sql語(yǔ)法問(wèn)題

8、第3方組件
使用Redis，RabbitMQ等組件，是不是真的對(duì)組件完全了解，在使用的進(jìn)程中是不是正確履行了開(kāi)啟與關(guān)閉操作。

寫(xiě)到這里，可能會(huì)有很多讀者認(rèn)為，代碼規(guī)范也就這些了吧，依照上面2類寫(xiě)完算是優(yōu)秀的代碼了嗎？其實(shí)還是遠(yuǎn)遠(yuǎn)不夠。

3、可讀性，可保護(hù)性

曾看過(guò)1段代碼，1個(gè)method幾千行代碼，所有業(yè)務(wù)邏輯都揉在了1起。然后沒(méi)有人愿意再保護(hù)了，修改1點(diǎn)就會(huì)引發(fā)不可預(yù)知的毛病，代碼又臭又長(zhǎng)。在這類情況只能重構(gòu)，因而我在部門內(nèi)部推行2本書(shū)《代碼整潔之道》和《重構(gòu)-改良既有代碼的設(shè)計(jì)》并且制定部門自己的開(kāi)發(fā)風(fēng)格，通過(guò)組織所有開(kāi)發(fā)人員練習(xí)小項(xiàng)目的開(kāi)發(fā)，使全部部門的開(kāi)發(fā)風(fēng)格整齊劃1，不論是老同事還是新同事，都能夠非?？焖俚纳鲜?，程序中依賴度下降，結(jié)構(gòu)非常清晰。

4、性能瓶頸

在真實(shí)工作中，很多程序員其實(shí)在開(kāi)發(fā)完程序后不去真正關(guān)注程序的性能和響應(yīng)時(shí)間到底如何，憑的是以往開(kāi)發(fā)經(jīng)驗(yàn)在開(kāi)發(fā)的進(jìn)程中盡量的去減少問(wèn)題點(diǎn)。

這樣就只能在生產(chǎn)環(huán)境中去驗(yàn)證性能問(wèn)題了，實(shí)際這類做法風(fēng)險(xiǎn)較大，所帶來(lái)的損失也是較大的，我們?cè)陂_(kāi)發(fā)完程序后，不但要采取Junit或JMock這樣的工具進(jìn)行業(yè)務(wù)功能自測(cè)，更重要是能夠采取相應(yīng)的工具和命令進(jìn)行代碼性能和響應(yīng)時(shí)間的測(cè)試，在第1關(guān)就可以夠找出可能出現(xiàn)的1部份問(wèn)題點(diǎn)，那末常常使用的工具和命令以下：
top，vmstat，pidstat，Hprof，Btrace，Dtrace等命令。

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

5、代碼容錯(cuò)

• 曾有1個(gè)案例：
  X同事在“統(tǒng)1配置管理系統(tǒng)“中將1個(gè)參數(shù)配置在里面，當(dāng)參數(shù)進(jìn)行修改的時(shí)候相應(yīng)的程序會(huì)馬上做出改變進(jìn)行相應(yīng)邏輯調(diào)劑，可是另外一個(gè)A同事在操作這個(gè)系統(tǒng)的時(shí)候配錯(cuò)了參數(shù)，這時(shí)候候系統(tǒng)在生產(chǎn)環(huán)境中就開(kāi)始報(bào)錯(cuò)，以致于利用程序崩潰，邏輯沒(méi)法進(jìn)行下去造成較嚴(yán)重的生產(chǎn)事故，最后恢復(fù)完參數(shù)故障時(shí)間已進(jìn)行了10幾分鐘。針對(duì)這個(gè)問(wèn)題當(dāng)時(shí)產(chǎn)生了爭(zhēng)辯，究竟是配置人員的錯(cuò)，還是開(kāi)發(fā)人員的錯(cuò)。

其實(shí)在我看來(lái)，究竟是誰(shuí)的問(wèn)題暫且放在1邊，關(guān)鍵是開(kāi)發(fā)人員是不是在寫(xiě)程序的進(jìn)程中有無(wú)多1絲的思考，多斟酌1些問(wèn)題點(diǎn)，程序員要時(shí)刻懷著1顆懷疑的心和畏敬的心對(duì)待自己寫(xiě)的程序，像上面的問(wèn)題我們完全可以做1些異常捕獲和默許設(shè)置，在出錯(cuò)的時(shí)候最少能夠讓利用程序跑下去而不能整體報(bào)錯(cuò)，讓用戶沒(méi)法繼續(xù)使用。

• 再說(shuō)1個(gè)案例：
  某部門在開(kāi)發(fā)“統(tǒng)1配置管理系統(tǒng)”，使用的是Zookeeper組件，而且它的工作原理是當(dāng)某節(jié)點(diǎn)改變的時(shí)候，主動(dòng)去通知所注冊(cè)的系統(tǒng)，但是有個(gè)條件是如果那些系統(tǒng)，有1部份沒(méi)有得到通知，有1部份得到了通知該怎樣辦，比如某幾個(gè)系統(tǒng)在通知的時(shí)候正好在重啟，這時(shí)候候zookeeper就不能通知到相應(yīng)的系統(tǒng)，因而在使用該“統(tǒng)1配置管理系統(tǒng)”的時(shí)候，出了生產(chǎn)事故。

其實(shí)還應(yīng)當(dāng)再重復(fù)說(shuō)1下，程序員應(yīng)當(dāng)持有懷疑的精神面對(duì)調(diào)用的系統(tǒng)和被調(diào)用的系統(tǒng)，不要把穩(wěn)定、安全、可靠寄托于他人身上。

究竟怎樣寫(xiě)代碼才能算好代碼？這是1個(gè)有爭(zhēng)議的話題，每一個(gè)人的理解可能都不同，關(guān)鍵是通過(guò)討論這個(gè)話題制定1個(gè)符合自己部門要求的規(guī)范，這樣有根據(jù)的代碼才可能成為好的代碼。