今天讓我們來談?wù)劥a吧鹃觉。代碼重要嗎？當(dāng)然睹逃，代碼就是設(shè)計(jì)（Jack W.Reeves, 1992）盗扇；代碼是最有價(jià)值的交付物。我們需要好代碼嗎沉填？在給“好代碼”下個(gè)定義之前疗隶，這個(gè)問題無法回答。那么翼闹，究竟什么是好代碼斑鼻？

看下面這段英文解釋：

'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ù)性坚弱。一些企業(yè)自己有所有開發(fā)人員都必需遵守的編碼規(guī)范蜀备，但是對(duì)于什么樣的代碼是最好的每個(gè)人的都有自己的標(biāo)準(zhǔn)、或者有太多的或太少的編碼規(guī)則荒叶。這有多種原則和標(biāo)準(zhǔn)琼掠，例如，McCable 的復(fù)雜度度量停撞。的確使用過多的編碼標(biāo)準(zhǔn)和規(guī)則可能降低生產(chǎn)率和創(chuàng)造性瓷蛙。“同行評(píng)審”或“同事檢查”代碼分析工具等戈毒，都能用來檢查問題或堅(jiān)持標(biāo)準(zhǔn)艰猬。

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

一冠桃、代碼命名規(guī)范：

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

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

3襟士、 interface接口名應(yīng)當(dāng)是名詞盗飒，每個(gè)內(nèi)部單詞的頭一個(gè)字母大寫。應(yīng)當(dāng)使你的接口名簡(jiǎn)單和具有說明性陋桂。用完整的英語單詞或約定俗成的簡(jiǎn)寫命名接口名逆趣。
【示例】interface TicketManagement

4、 Class 成員屬性及變量的命名 (*) 變量名全部由字母組成嗜历，頭一個(gè)字母小寫宣渗，以后每個(gè)內(nèi)部單詞的頭一個(gè)字母大寫。變量名應(yīng)該短而有意義秸脱。變量名的選擇應(yīng)該易于記憶落包。一個(gè)字符的變量名應(yīng)避免部蛇，除非用于臨時(shí)變量摊唇。通常臨時(shí)變量名的命名規(guī)則為：i，j涯鲁，k巷查，m有序，n用于整數(shù)；c岛请，d旭寿，e用于字符。

5崇败、常量的命名盅称，Java 里的常量，是用static final 修飾的后室，應(yīng)該用全大寫加下劃線命名缩膝，并且盡量指出完整含義。
【示例】static final String SMTH_BBS="bbs.tsinghua.edu.cn";

6岸霹、數(shù)組的命名疾层，數(shù)組應(yīng)該總是用下面的形式來命名：byte[] buffer;

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

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

以上幾條如果符合就算是好代碼了嗎蝇恶？當(dāng)然不是，這只是代碼中最基本的命名規(guī)范而已惶桐，就算不符合最多就是代碼不好看撮弧，沒什么其他影響。

二姚糊、代碼邏輯規(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是否處理了所有分支
分支的條件語句是否有“副作用”；即肠槽，條件語句是否會(huì)改變系統(tǒng)狀態(tài)/數(shù)據(jù)等
循環(huán)邊界是否覆蓋了所有元素
是否有死循環(huán)等

4擎淤、異常處理
是否有“吃掉異成萆叮”的情況
是否記錄了異常日志
如果二次拋出，是否有合理的異常層次/結(jié)構(gòu)
如果內(nèi)部處理嘴拢，對(duì)異常的處理是否能保證后續(xù)代碼正常運(yùn)行

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

6、 事務(wù)處理
事務(wù)范圍是否合理席吴；或者說赌结，是否把不必要的操作放到了同一個(gè)事務(wù)中
事務(wù)傳播方式是否合理（required，never孝冒，new等配置）

7姑曙、sql語句
sql語句是否正確
使用mybatis的動(dòng)態(tài)語句時(shí)，是否有潛在的sql語法問題

8迈倍、第三方組件
使用Redis伤靠，RabbitMQ等組件，是否真的對(duì)組件完全了解啼染，在使用的過程中是否正確執(zhí)行了開啟與關(guān)閉操作宴合。

寫到這里，可能會(huì)有不少讀者認(rèn)為迹鹅，代碼規(guī)范也就這些了吧卦洽，按照上面二類寫完算是優(yōu)秀的代碼了嗎？其實(shí)還是遠(yuǎn)遠(yuǎn)不夠斜棚。

三阀蒂、可讀性，可維護(hù)性

曾經(jīng)看過一段代碼弟蚀，一個(gè)method幾千行代碼蚤霞，所有業(yè)務(wù)邏輯都揉在了一起。然后沒有人愿意再維護(hù)了义钉，修改一點(diǎn)就會(huì)引發(fā)不可預(yù)知的錯(cuò)誤昧绣，代碼又臭又長(zhǎng)。在這種情況只能重構(gòu)捶闸，于是我在部門內(nèi)部推廣二本書《代碼整潔之道》和《重構(gòu)-改善既有代碼的設(shè)計(jì)》并且制訂部門自己的開發(fā)風(fēng)格夜畴，通過組織所有開發(fā)人員練習(xí)小項(xiàng)目的開發(fā)，使整個(gè)部門的開發(fā)風(fēng)格整齊劃一删壮，不管是老同事還是新同事贪绘，都能夠非常快速的上手央碟，程序中依賴度降低税灌，結(jié)構(gòu)非常清晰。

四、性能瓶頸

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

這樣就只能在生產(chǎn)環(huán)境中去驗(yàn)證性能問題了狸窘，實(shí)際這種做法風(fēng)險(xiǎn)較大，所帶來的損失也是較大的坯认，我們?cè)陂_發(fā)完程序后翻擒，不僅要采用Junit或者JMock這樣的工具進(jìn)行業(yè)務(wù)功能自測(cè)，更重要是能夠采用相應(yīng)的工具和命令進(jìn)行代碼性能和響應(yīng)時(shí)間的測(cè)試牛哺，在第一關(guān)就能夠找出可能出現(xiàn)的一部分問題點(diǎn)陋气，那么經(jīng)常使用的工具和命令如下：
top，vmstat引润，pidstat巩趁，Hprof，Btrace淳附，Dtrace等命令议慰。

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

五、代碼容錯(cuò)

• 曾經(jīng)有一個(gè)案例：
  X同事在“統(tǒng)一配置管理系統(tǒng)“中將一個(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)境中就開始報(bào)錯(cuò)洽糟，以致于應(yīng)用程序崩潰炉菲，邏輯無法進(jìn)行下去造成較嚴(yán)重的生產(chǎn)事故，最后恢復(fù)完參數(shù)故障時(shí)間已經(jīng)進(jìn)行了十幾分鐘坤溃。針對(duì)這個(gè)問題當(dāng)時(shí)產(chǎn)生了爭(zhēng)論拍霜，到底是配置人員的錯(cuò)，還是開發(fā)人員的錯(cuò)薪介。

其實(shí)在我看來沉御，到底是誰的問題暫且放在一邊，關(guān)鍵是開發(fā)人員是否在寫程序的過程中有沒有多一絲的思考昭灵，多考慮一些問題點(diǎn)吠裆，程序員要時(shí)刻懷著一顆懷疑的心和敬畏的心對(duì)待自己寫的程序，像上面的問題我們完全可以做一些異常捕獲和默認(rèn)設(shè)置烂完，在出錯(cuò)的時(shí)候至少能夠讓應(yīng)用程序跑下去而不能整體報(bào)錯(cuò)试疙，讓用戶無法繼續(xù)使用。

• 再說一個(gè)案例：
  某部門在開發(fā)“統(tǒng)一配置管理系統(tǒng)”抠蚣，使用的是Zookeeper組件祝旷，而且它的工作原理是當(dāng)某節(jié)點(diǎn)改變的時(shí)候，主動(dòng)去通知所注冊(cè)的系統(tǒng)，但是有個(gè)前提是如果那些系統(tǒng)怀跛，有一部分沒有得到通知距贷，有一部分得到了通知該怎么辦，比如某幾個(gè)系統(tǒng)在通知的時(shí)候正好在重啟吻谋，這時(shí)候zookeeper就不能通知到相應(yīng)的系統(tǒng)忠蝗，于是在使用該“統(tǒng)一配置管理系統(tǒng)”的時(shí)候，出了生產(chǎn)事故漓拾。

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

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