三年0故障總結，提高代碼質量的祕訣

我的經歷

對我代碼質量影響最大的是在一家外資企業，在這家公司我以爲有如下幾個方面作的很不錯。

• 團隊編碼風格統一
  • 統一到什麼程度? 不看代碼做者，你很難區分代碼是誰寫的(在目前公司一些團隊也能達到這個標準)。

我的觀點:

1. 這樣作有什麼好處？團隊中每一個人閱讀代碼都很容易，減小不少溝通,維護成本( 代碼閱讀的次數遠遠大於變動的次數)，而且心情很是愉悅。有人確定以爲愉悅有點誇張，舉個栗子: 有一些代碼，若是不是因爲與工做內容有關聯，你是否有種這輩子都不情願去接觸它的感覺。但也有一些代碼，閱讀下來一鼓作氣，心情舒暢，促使你有種繼續閱讀下去的衝動(而且你也會有種不想破壞這種統一的想法).
2. 基礎層面越統一，效率越高(不只僅是指統一編碼規範，還有基本的作事的原則). 舉個栗子: 咱們團隊規定我的週報必須在每週五上班前必須發出來，不然罰款10元。以前團隊週報遲發現象比較突出，規則一出，明顯改善(開會缺席狀況也同樣獲得明顯改善)。罰錢是否不太合理？註釋寫多少纔算合理？與其花大量精力討論這些不痛不癢的問題，不如及時統一規範(通常制定的規範不會差的)，嚴格執行。後續針對問題即便作調整。關鍵是統一和嚴格執行。

• 代碼簡潔
  • 能1行解決就不要寫2行(不影響可讀性的狀況下)
  • 多餘的代碼(好比註釋代碼 or 無實際意義)必須刪除

我的觀點: 你們都懂的, 沒啥好說的

• codereview
  • 團隊的PLA(團隊骨幹)進行codereview, 團隊中PLA之間的代碼質量意識/以及代碼規範很是統一.不會出現一個團隊，多個標準的狀況
  • 每週五週會會對這周代碼review出來的問題進行回顧，得出結論。將例子放在wiki上，以供後續遇到相似問題的一個參照。新同窗也可參照此內容學習規範，避免犯同類問題。規範中不少內容就是這麼累計起來的。

我的觀點:

1. 我在阿里所經歷的一個團隊中，PLA有3,4位, 分別負責各自的一塊業務。PLA之間codereview不多,代碼質量的意識交流彷佛也很少。但團隊的普通開發同窗在這些PLA之間輪流被codereview, 代碼質量的評比標準差別較大。這可能會致使2種現象:開發傾向review寬鬆的同窗, 由於寬鬆review發現問題(不只僅是bug)較少，變更成本不大，不會有改動形成的故障風險，不會影響項目進度(但後續的維護和溝通成本會明顯增長);另外一種現象, 開發向不一樣的PLA提出疑義，PLA之間統一代碼質量標準，在團隊內達成共識並造成文檔，以做爲後續參考。

2. 一個團隊的代碼質量主要取決於團隊幾位PLA，建議團隊早期先統一PLA的代碼質量意識和規範。例如: 先由1-2位PLA對整個團隊開發作review,這個review工做量初期會很大, 而且團隊工做效率不高，但後期的review工做量應該會明顯減少, 代碼質量也會明顯提升, 團隊的工做效率也會明顯提高.

   我在外企這家公司剛入職的那一個月是我最痛苦的一個月，被codereview感受很不適應:和之前編碼習慣差別較大，review太嚴格(變量名,空行,註釋有單詞語法錯誤也會糾正)，感受限制編碼自由.... 1個多月後體會到了明顯的好處: 編碼bug少; 溝通少,代碼和註釋已經解決了大部分疑問;閱讀代碼效率高; 感受別人寫的代碼就像是本身寫的同樣,很是有親切感.一個多月後, revew我代碼的PLA明顯放鬆了對我review的內容，由於他已經不少次沒有review出問題，而且讓我在每次review前告知需重點review的內容便可。

3. 閱讀全文請點擊：http://click.aliyun.com/m/8717/