三年0故障總結，提升代碼質量的秘訣

三年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的內容即可。