定義程式碼質量

首先當你開始意識到專案裡程式碼質量差的時候，恭喜你已經有了程式碼審美。這是推進程式設計水平的重要的一步。很顯然，如果你不知道什麼是差的程式碼，你就寫不出好的程式碼。寫不出好的程式碼，更高的架構也就無從談起。

先來定義團隊程式碼質量的黃金標準：易維護。

程式碼最基本的要求，易讀。現代的軟體專案都不是一朝一夕，有團隊合作，有新需求，要修bug，程式碼不只是只給機器讀的，是給人讀的。一份清晰、易懂的程式碼就包括了：良好的程式碼風格，清晰的邏輯，合理的結構。也許做到90分和天賦有關，做到70分其實沒難度，單純看你花了多少努力在這件事。

很多人用中文寫幾百個字描述一件事都說不清，一個邏輯有兩千行程式碼又怎麼可能寫的清楚呢。鍛鍊過程也和提高表達能力相似，只是之前是某種文字，現在是用程式碼。文學裡有修辭手法，有總分總，程式碼裡有語法糖，有MVC。

程式碼質量從何開始

如果重視程式碼質量，如何達成程式碼質量的基本共識呢？

解決這個問題的核心並不是一本萬能手冊。不存在一本黃金寶典，包含了各式各樣的程式碼，任何時候都可以按圖索驥得到一個檢驗標準。你能得到的是一個評判的方式，可以從哪些角度去認知程式碼，最後發現這樣的程式碼在這個條件會引起一些問題，所以這程式碼不夠好。

我認為的起點是這幾本書：《編寫可讀程式碼的藝術》《程式碼整潔之道》《重構》《程式碼大全》。就如前面說過的，這些書的重點並不是具體某個程式碼、某種條件下好的程式碼長什麼樣，而是他們怎麼得出了這樣的結果。當你理解了這幾本書的核心思想後可以開始正確審視自己的程式碼質量了，可以開始code review了。

追求程式碼質量是一個成長的過程

程式碼質量就像作者寫出好的文章一樣，是一個不斷進步、不斷推進的過程。

一開始你可能寫十幾行就要停下來思考，這個命名合不合適，這樣的邏輯是不是有點亂。後面可能到一個類的封裝是不是合適。再後面可能幾個月回頭看自己的程式碼才意識到，當時這樣寫會有歧義，擴充套件性不好等等。

這也是自己不斷提高程式設計能力的過程，寫出易維護的程式碼只是第一步。

沒有code review的團隊沒有未來

如何提高團隊的程式碼質量？

程式碼是有程式設計師寫出來的，如果每個人都是老江湖，團隊的程式碼質量就高了啊。可是能有幾個團隊每個人都能寫出高質量的程式碼？

其實真的非常簡單，嚴格的執行code review就可以了。讓那些知道好程式碼長什麼樣的人控制程式碼質量。就像工廠裡的質檢，不合格的程式碼不會被合進程式碼庫。

沒有code review的團隊沒有未來。

要不就是這個團隊技術能力差，沒有能力進行review。

要不就是專案簡單，不需要review，什麼垃圾程式碼都可以完美支撐。

要不就是專案複雜，團隊技術實力也可以。核心程式碼由救火隊員控制，他們根本不關心其他人程式碼寫成怎麼樣。出問題了他們救火，他們會保證專案執行，其他成員技術能力的提高不在意。

最後一種情況可能是最常見的情況，但是也是最可悲的情況。他意味技術團隊的負責人本質上並不關心成員的技術成長。提高專案程式碼質量的最終實現還是靠每個成員的能力可以寫出高質量的程式碼。每個人都成長了，最後專案程式碼質量自然就提高了。然而管理技術團隊的人沒有意識去促成這件事情的發生，那麼一個新手在這樣的團隊成長還是靠自我摸索，這會是一個緩慢的過程。

Code review就像快進的結對程式設計，一個老手點評一個新手程式碼的時候，就會產生交流，要闡明為什麼不能這樣寫。在保證專案質量的同時，對新手也進行了指引。兩個水平相當的人review則得到了其他視角的審視結果，最後交流的結果就是兩個人都得到了更全面的見解。

所以沒有code review的團隊沒有未來。每個團隊都有自己的基因，如果你在團隊沒有話語權，只能祝你早日找到一個有review的團隊，不要期望通過自己的努力改變他們。以我的經驗來看，無法叫醒一個裝睡的人，一個真正好的團隊，推進code review不會有任何阻力，如果有，開掉那個人。