1、關于爛代碼的那些事1.摘要這是爛代碼系列的第二篇，在文章中我會跟大家討論一下如何盡可能高效和客觀的評價代碼的優劣。在發布了關于爛代碼的那些事（上）之后，發現這篇文章竟然意外的很受歡迎，很多人也描(tu)述(cao)了各自代碼中這樣或者那樣的問題。最近部門在組織bootcamp，正好我負責培訓代碼質量部分，在培訓課程中讓大家花了不少時間去討論、改進、完善自己的代碼。雖然剛畢業的同學對于代碼質量都很用心，但最終呈現出來的質量仍然沒能達到“十分優秀”的程度。 究其原因，主要是不了解好的代碼“應該”是什么樣的。2.什么是好代碼寫代碼的第一步是理解什么是好代碼。在準備bootcamp的課程的時候，我就為

2、這個問題犯了難，我嘗試著用一些精確的定義區分出“優等品”、“良品”、“不良品”；但是在總結的過程中，關于“什么是好代碼”的描述卻大多沒有可操作性2.1.好代碼的定義隨便從網上搜索了一下“優雅的代碼”，找到了下面這樣的定義:Bjarne Stroustrup，C+之父：邏輯應該是清晰的，bug難以隱藏；依賴最少，易于維護；錯誤處理完全根據一個明確的策略；性能接近最佳化，避免代碼混亂和無原則的優化；整潔的代碼只做一件事。Grady Booch，面向對象分析與設計作者：整潔的代碼是簡單、直接的；整潔的代碼，讀起來像是一篇寫得很好的散文；整潔的代碼永遠不會掩蓋設計者的意圖，而是具有少量的抽象和清晰的控

3、制行。Michael Feathers，修改代碼的藝術作者：整潔的代碼看起來總是像很在乎代碼質量的人寫的；沒有明顯的需要改善的地方；代碼的作者似乎考慮到了所有的事情。看起來似乎說的都很有道理，可是實際評判的時候卻難以參考，尤其是對于新人來說，如何理解“簡單的、直接的代碼”或者“沒有明顯的需要改善的地方”？而實踐過程中，很多同學也確實面對這種問題：對自己的代碼總是處在一種心里不踏實的狀態，或者是自己覺得很好了，但是卻被其他人認為很爛，甚至有幾次我和新同學因為代碼質量的標準一連討論好幾天，卻誰也說服不了誰：我們都堅持自己對于好代碼的標準才是正確的。在經歷了無數次code review之后，我覺得這

4、張圖似乎總結的更好一些：代碼質量的評價標準某種意義上有點類似于文學作品，比如對小說的質量的評價主要來自于它的讀者，由個體主觀評價形成一個相對客觀的評價。并不是依靠字數，或者作者使用了哪些修辭手法之類的看似完全客觀但實際沒有什么意義的評價手段。但代碼和小說還有些不一樣，它實際存在兩個讀者：計算機和程序員。就像上篇文章里說的，即使所有程序員都看不懂這段代碼，它也是可以被計算機理解并運行的。所以對于代碼質量的定義我需要于從兩個維度分析：主觀的，被人類理解的部分；還有客觀的，在計算機里運行的狀況。既然存在主觀部分，那么就會存在個體差異，對于同一段代碼評價會因為看代碼的人的水平不同而得出不一樣的結論，這

5、也是大多數新人面對的問題：他們沒有一個可以執行的評價標準，所以寫出來的代碼質量也很難提高。有些介紹代碼質量的文章講述的都是傾向或者原則，雖然說的很對，但是實際指導作用不大。所以在這篇文章里我希望盡可能把評價代碼的標準用（我自認為）與實際水平無關的評價方式表示出來。2.2.可讀的代碼在權衡很久之后，我決定把可讀性的優先級排在前面：一個程序員更希望接手一個有bug但是看的懂的工程，還是一個沒bug但是看不懂的工程？如果是后者，可以直接關掉這個網頁，去做些對你來說更有意義的事情。2.2.1.逐字翻譯在很多跟代碼質量有關的書里都強調了一個觀點：程序首先是給人看的，其次才是能被機器執行，我也比較認同這個

6、觀點。在評價一段代碼能不能讓人看懂的時候，我習慣讓作者把這段代碼逐字翻譯成中文，試著組成句子，之后把中文句子讀給另一個人沒有看過這段代碼的人聽，如果另一個人能聽懂，那么這段代碼的可讀性基本就合格了。用這種判斷方式的原因很簡單：其他人在理解一段代碼的時候就是這么做的。閱讀代碼的人會一個詞一個詞的閱讀，推斷這句話的意思，如果僅靠句子無法理解，那么就需要聯系上下文理解這句代碼，如果簡單的聯系上下文也理解不了，可能還要掌握更多其它部分的細節來幫助推斷。大部分情況下，理解一句代碼在做什么需要聯系的上下文越多，意味著代碼的質量越差。逐字翻譯的好處是能讓作者能輕易的發現那些只有自己知道的、沒有體現在代碼里的

7、假設和可讀性陷阱。無法從字面意義上翻譯出原本意思的代碼大多都是爛代碼，比如“ms代表messageService“，或者“c()是發消息“，或者“tmp代表當前的文件”。2.2.2.遵循約定約定包括代碼和文檔如何組織，注釋如何編寫，編碼風格的約定等等，這對于代碼未來的維護很重要。對于遵循何種約定沒有一個強制的標準，不過我更傾向于遵守更多人的約定。與開源項目保持風格一致一般來說比較靠譜，其次也可以遵守公司內部的編碼風格。但是如果公司內部的編碼風格和當前開源項目的風格沖突比較嚴重，往往代表著這個公司的技術傾向于封閉，或者已經有些跟不上節奏了。但是無論如何，遵守一個約定總比自己創造出一些

8、規則要好很多，這降低了理解、溝通和維護的成本。如果一個項目自己創造出了一些奇怪的規則，可能意味著作者看過的代碼不夠多。一個工程是否遵循了約定往往需要代碼閱讀者有一定經驗，或者需要借助checkstyle這樣的靜態檢查工具。如果感覺無處下手，那么大部分情況下跟著google做應該不會有什么大問題：可以參考google code style，其中一部分有對應的中文版。另外，沒有必要糾結于遵循了約定到底有什么收益，就好像走路是靠左好還是靠右好一樣，即使得出了結論也沒有什么意義，大部分約定只要遵守就可以了。2.2.3.文檔和注釋文檔和注釋是程序很重要的部分，他們是理解一個工程或項目的途徑之一。兩者在某

9、些場景下定位會有些重合或者交叉（比如javadoc實際可以算是文檔）。對于文檔的標準很簡單，能找到、能讀懂就可以了，一般來說我比較關心這幾類文檔：對于項目的介紹，包括項目功能、作者、目錄結構等，讀者應該能3分鐘內大致理解這個工程是做什么的。針對新人的QuickStart，讀者按照文檔說明應該能在1小時內完成代碼構建和簡單使用。針對使用者的詳細說明文檔，比如接口定義、參數含義、設計等，讀者能通過文檔了解這些功能（或接口）的使用方法。有一部分注釋實際是文檔，比如之前提到的javadoc。這樣能把源碼和注釋放在一起，對于讀者更清晰，也能簡化不少文檔的維護的工作。還有一類注釋并不作為文檔的一部分，比如

10、函數內部的注釋，這類注釋的職責是說明一些代碼本身無法表達的作者在編碼時的思考，比如“為什么這里沒有做XXX”，或者“這里要注意XXX問題”。一般來說我首先會關心注釋的數量：函數內部注釋的數量應該不會有很多，也不會完全沒有，個人的經驗值是滾動幾屏幕看到一兩處左右比較正常。過多的話可能意味著代碼本身的可讀性有問題，而如果一點都沒有可能意味著有些隱藏的邏輯沒有說明，需要考慮適當的增加一點注釋了。其次也需要考慮注釋的質量：在代碼可讀性合格的基礎上，注釋應該提供比代碼更多的信息。文檔和注釋并不是越多越好，它們可能會導致維護成本增加。關于這部分的討論可以參考簡潔部分的內容。2.2.4.推薦閱讀代碼整潔之道

11、2.3.可發布的代碼新人的代碼有一個比較典型的特征，由于缺少維護項目的經驗，寫的代碼總會有很多考慮不到的地方。比如說測試的時候似乎沒什么異常，項目發布之后才發現有很多意料之外的狀況；而出了問題之后不知道從哪下手排查，或者僅能讓系統處于一個并不穩定的狀態，依靠一些巧合勉強運行。2.3.1.處理異常新手程序員普遍沒有處理異常的意識，但代碼的實際運行環境中充滿了異常：服務器會死機，網絡會超時，用戶會胡亂操作，不懷好意的人會惡意攻擊你的系統。我對一段代碼異常處理能力的第一印象來自于單元測試的覆蓋率。大部分異常難以在開發或者測試環境里復現，即使有專業的測試團隊也很難在集成測試環境中模擬所有的異常情況。而

12、單元測試可以比較簡單的模擬各種異常情況，如果一個模塊的單元測試覆蓋率連50%都不到，很難想象這些代碼考慮了異常情況下的處理，即使考慮了，這些異常處理的分支都沒有被驗證過，怎么指望實際運行環境中出現問題時表現良好呢？2.3.2.處理并發我收到的很多簡歷里都寫著：精通并發編程/熟悉多線程機制，諸如此類，跟他們聊的時候也說的頭頭是道，什么鎖啊互斥啊線程池啊同步啊信號量啊一堆一堆的名詞滔滔不絕。而給應聘者一個實際場景，讓應聘者寫一段很簡單的并發編程的小程序，能寫好的卻不多。實際上并發編程也確實很難，如果說寫好同步代碼的難度為5，那么并發編程的難度可以達到100。這并不是危言聳聽，很多看似穩定的程序，在

13、面對并發場景的時候仍然可能出現問題：比如最近我們就碰到了一個linux kernel在調用某個系統函數時由于同步問題而出現crash的情況。而是否高質量的實現并發編程的關鍵并不是是否應用了某種同步策略，而是看代碼中是否保護了共享資源：局部變量之外的內存訪問都有并發風險（比如訪問對象的屬性，訪問靜態變量等）訪問共享資源也會有并發風險（比如緩存、數據庫等）。被調用方如果不是聲明為線程安全的，那么很有可能存在并發問題（比如java的hashmap）。所有依賴時序的操作，即使每一步操作都是線程安全的，還是存在并發問題（比如先刪除一條記錄，然后把記錄數減一）。前三種情況能夠比較簡單的通過代碼本身分辨出來

14、，只要簡單培養一下自己對于共享資源調用的敏感度就可以了。但是對于最后一種情況，往往很難簡單的通過看代碼的方式看出來，甚至出現并發問題的兩處調用并不是在同一個程序里（比如兩個系統同時讀寫一個數據庫，或者并發的調用了一個程序的不同模塊等）。但是，只要是代碼里出現了不加鎖的，訪問共享資源的“先做A，再做B”之類的邏輯，可能就需要提高警惕了。2.3.3.優化性能性能是評價程序員能力的一個重要指標，很多程序員也對程序的性能津津樂道。但程序的性能很難直接通過代碼看出來，往往要借助于一些性能測試工具，或者在實際環境中執行才能有結果。如果僅從代碼的角度考慮，有兩個評價執行效率的辦法：算法的時間復雜度，時間復雜

15、度高的程序運行效率必然會低。單步操作耗時，單步耗時高的操作盡量少做，比如訪問數據庫，訪問io等。而實際工作中，也會見到一些程序員過于熱衷優化效率，相對的會帶來程序易讀性的降低、復雜度提高、或者增加工期等等。對于這類情況，簡單的辦法是讓作者說出這段程序的瓶頸在哪里，為什么會有這個瓶頸，以及優化帶來的收益。當然，無論是優化不足還是優化過度，判斷性能指標最好的辦法是用數據說話，而不是單純看代碼，性能測試這部分內容有些超出這篇文章的范圍，就不詳細展開了。2.3.4.日志日志代表了程序在出現問題時排查的難易程度，經(jing)驗(chang)豐(cai)富(keng)的程序員大概都會遇到過這個場景：排查

16、問題時就少一句日志，查不到某個變量的值不知道是什么，導致死活分析不出來問題到底出在哪。對于日志的評價標準有三個：日志是否足夠，所有異常、外部調用都需要有日志，而一條調用鏈路上的入口、出口和路徑關鍵點上也需要有日志。日志的表達是否清晰，包括是否能讀懂，風格是否統一等。這個的評價標準跟代碼的可讀性一樣，不重復了。日志是否包含了足夠的信息，這里包括了調用的上下文、外部的返回值，用于查詢的關鍵字等，便于分析信息。對于線上系統來說，一般可以通過調整日志級別來控制日志的數量，所以打印日志的代碼只要不對閱讀造成障礙，基本上都是可以接受的。2.3.5.擴展閱讀Release It!: Design and D

17、eploy Production-Ready Software（不要看中文版，翻譯的實在是太爛了）Numbers Everyone Should Know2.4.可維護的代碼相對于前兩類代碼來說，可維護的代碼評價標準更模糊一些，因為它要對應的是未來的情況，一般新人很難想象現在的一些做法會對未來造成什么影響。不過根據我的經驗，一般來說，只要反復的提問兩個問題就可以了：他離職了怎么辦？他沒這么做怎么辦？2.4.1.避免重復幾乎所有程序員都知道要避免拷代碼，但是拷代碼這個現象還是不可避免的成為了程序可維護性的殺手。代碼重復分為兩種：模塊內重復和模塊間重復。無論何種重復，都在一定程度上說明了程序員的水

18、平有問題，模塊內重復的問題更大一些，如果在同一個文件里都能出現大片重復的代碼，那表示他什么不可思議的代碼都有可能寫出來。對于重復的判斷并不需要反復閱讀代碼，一般來說現代的IDE都提供了檢查重復代碼的工具，只需點幾下鼠標就可以了。除了代碼重復之外，很多熱衷于維護代碼質量的程序員新人很容易出現另一類重復：信息重復。我見過一些新人喜歡在每行代碼前面寫一句注釋，比如：/成員列表的長度0并且0&memberList.size()0并且0&memberList.size()0并且0&memberList.size()200|(tmp.isOpen()&flag)/返回當前成員列表/returnmember

19、List;/if(tmp.isOpen()&flag)returnmemberList;隨著項目的演進，無用的信息會越積越多，最終甚至讓人無法分辨哪些信息是有效的，哪些是無效的。如果在項目中發現好幾個東西都在做同一件事情，比如通過注釋描述代碼在做什么，或者依靠注釋替代版本管理的功能，那么這些代碼也不能稱為好代碼。2.4.2.模塊劃分模塊內高內聚與模塊間低耦合是大部分設計遵循的標準，通過合理的模塊劃分能夠把復雜的功能拆分為更易于維護的更小的功能點。一般來說可以從代碼長度上初步評價一個模塊劃分的是否合理，一個類的長度大于2000行，或者一個函數的長度大于兩屏幕都是比較危險的信號。另一個能夠體現模塊

20、劃分水平的地方是依賴。如果一個模塊依賴特別多，甚至出現了循環依賴，那么也可以反映出作者對模塊的規劃比較差，今后在維護這個工程的時候很有可能出現牽一發而動全身的情況。一般來說有不少工具能提供依賴分析，比如IDEA中提供的Dependencies Analysis功能，學會這些工具的使用對于評價代碼質量會有很大的幫助。值得一提的是，絕大部分情況下，不恰當的模塊劃分也會伴隨著極低的單元測試覆蓋率：復雜模塊的單元測試非常難寫的，甚至是不可能完成的任務。所以直接查看單元測試覆蓋率也是一個比較靠譜的評價方式。2.4.3.簡潔與抽象只要提到代碼質量，必然會提到簡潔、優雅之類的形容詞。簡潔這個詞實際涵蓋了很多東西，代碼避免重復是簡潔、設計足夠抽象是簡潔，一切對于提高可維護性的嘗試實際都