三年0故障總結，提升程式碼質量的祕訣

該文章來自於阿里巴巴技術協會（ATA）精選文章。

個人經歷

對我程式碼質量影響最大的是在一家外資企業，在這家公司我覺得有以下幾個方面做的很不錯。

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

個人觀點:

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

• 執行力和壓力
  • codereview出來的問題一旦得出結論，就會立馬執行。如果有疑義，可以繼續討論，一直到得出結論為止。規範中的內容可以改進，但一旦形成規範就必須嚴格執行。
  • 一旦有不合規範的程式碼提交上去，就會郵件提醒給團隊PLA以及老大，提醒次數多了還是繼續犯類似問題，甚至會勸退。

個人觀點:

1. 我在阿里所經歷的幾個部門規範都很不錯，但有的執行起來卻比較寬鬆。因為專案進度一緊, 程式碼質量就容易妥協, 常見的現象 “我下個版本會改過來的”, “這個應該暫時沒有問題”, “這個程式碼是沒有按規範來做，但改動風險太大，出故障怎麼辦”. 這時候, 如果你在這妥協, 基本以後程式碼規範就很難維持了。因為一旦ugly的程式碼上線, 這程式碼很可能就會在專案裡擴散開來(和破窗效應類似).
2. 很多人對程式碼質量/規範有強烈的意識，但少數人可能感受不那麼明顯或者還沒有體會到這些帶來的益處，或者和自己已有習慣差異而產生排斥心裡，這時候得用外部壓力刺激一下。比如上面提到的每週五 review當週的問題–沒人會願意自己的程式碼經常被拎出來作反面教材。迫使他朝正向發展, 做到對事不對人就可以了。新人對壓力可能感觸更明顯，壓力會促使你做事更謹慎, 也有可能讓你做事畏首畏尾, 這時候對新人要多加關注。

程式碼質量理解

• 程式碼的可讀性放在第一位, 程式碼儘量做到don`t make me think( 這裡對集團中介軟體的開發同學提個建議，希望你們繼續提高程式碼的可讀性，因為你們的程式碼被閱讀了無數遍了，你們提高一點可讀性，將節約很多人的時間, 你們的程式碼很可能被很多同學模仿)
• 沒有bug的程式碼不一定是高質量的程式碼, 寫程式碼不能緊緊滿足於功能
• 你的程式碼規範不一定要達到開源規範標準(能達到最好)，但不要低(鬆)於團隊的程式碼規範.
• 寫程式碼要有敬畏之心。想想如果讓你開發載人火箭的程式,你敢隨意去寫麼? 網站一樣需要重視.
• 團隊的程式碼質量重要程度高於個人程式碼質量。如果只滿足個人程式碼質量提高，而不去幫助團隊提高程式碼質量，你很可能會踩上別人留下的坑，你在工作中很可能遇到各種不便(當然你也要避免給其他人留坑)。
• 良好的程式碼規範不一定會讓你避免bug.但可以幫助你/他人提升找到bug的速度, 以及提升工作效率
• 讀優秀的原始碼(書籍),關注一些細節，對程式碼質量提升非常有幫助.
• codereview不僅僅是為了review出bug。這也是知識分享的一個過程， 團隊更有經驗的同學會對你的程式碼提出建議;review人員可以從中獲取業務/技術相關資訊;被review人員因為有人會review你的程式碼，而不得不提升自己的程式碼質量，以及程式碼的熟悉程度。
• 程式碼規範不會影響開發效率, 你的開發效率應該通過其他的方式去提升。 相反，他會節省你很多成本(閱讀,溝通)
• 故障多少和自己的技術能力關係其實不是很大,和自身的工作習慣非常大(我看了很多故障案例,絕大多數不是開發同學沒有相應的技術能力)
• 對自己擅長什麼，不擅長什麼要有清楚的認識.有的故障產生的原因是對自己某方面能力太過自信.在不擅長的地方去諮詢其他有經驗的同學，這不會顯得自己能力差, 反而給他人的印象是你很重視你的工作，工作謹慎.
• 程式碼有bug是正常現象, 關鍵是找到有效方法預防和避免再次出現類似問題

工作習慣

• 當你拿到需求時,分析下自己的需求功能點的重要性(不同重要程度的需求，重視程度和花費的精力也不一樣).
• 設計時多花點時間思考, 編碼通常是比較快的
• 單元測試一定要寫, 這是底線(除非這個成本非常大)
• findbugs，pmd這些工具在前幾年我用的比較多，但近幾年用的已經很少了，原因是發現的問題少,誤判的機率還高，現在只是少數情況才會使用。但是新人建議還是多使用一下。
• 在團隊中尋找比你程式碼質量要求更高的同學來review自己的程式碼，一起探討問題，這能幫自己很快的提升。有疑義的地方一定要達成共識，立刻執行，並告知團隊，並形成規範。
• 儘量不要在情緒低落，體力不支的情況下做需要大量思考性的工作(我個人比較喜歡運動,體力不支的情況比較多.哈哈).
• 寫程式碼就難免會有bug/故障發生.另外一種避免故障的方案是如何儘快知道異常情況(比如做好監控), 在使用者投訴之前儘快解決掉，或者提前做好預備方案(通常是比較重要的需求).
• 不要因為錯小而放置不理，那會成為你的習慣。
• 週四儘量減少釋出, 你可能沒有足夠時間去觀察/驗證,釋出時尤其需要重視.
• 讀原始碼是我比較喜歡做的一件事情。一方面能夠熟悉一些技術原理/業務，開發時更胸有成竹，bug的機率當然也越少，當然你花費的時間可能就會多(你得去衡量). 這個做法也是不得已而為之: 一些部門的文件/程式碼註釋都有問題,溝通又可能不便，讀原始碼反而解決問題比較快.
• 當別人向你提建議時, 心胸開闊點, 你會獲取他人更多的幫助機會/建議

續

這篇文章被關注的程度遠遠超出了我的想像, 原本我並不打算在文章裡過多去描述一些影響程式碼質量的現象，但是評論裡提到的問題(比如說如何落地)多少都涉及這些。文章裡主要是從普通開發的角度去看程式碼質量，關於如何落地, 我知道落地肯定不容易, 肯定會面臨很多來自團隊內外的壓力.
舉幾個栗子:

• 你的老闆是否能夠接受短期工作效率普遍偏低麼(如果採用我在文章中提到的codereview方案)?
• 團隊成員是否都和你有類似的程式碼質量理念, 如果沒有, 你得不斷去影響他們, 得影響你的老闆。 如果做不到, 落地也無從說起.
• 每次故障頻率比較高的時候, 高層傳達的意思是重視使用者體驗,提升程式碼質量。到開發這裡，可能是採取更安全的編碼, 但不一定是合理的. 要不了多長時間，程式碼一定會變質.

坦白講, 我沒有很完整的, 可量化的, 可複製的方案, 我現在所在的團隊也沒有達到這個標準,
但我在alibaba經歷過這樣的團隊, 一個讓我終身難忘的團隊(還有那家外企)。這樣更加讓我堅信
我上面的這些想法應該是能落地的, 我也正在努力去影響我現在所在的團隊, 即使達不到我預想
的那樣, 但我相信一定會有改善.
Alibaba一直被認為是業務驅動型公司, 也許哪天整個集團的程式碼規範統一併嚴格執行了, 估計成為技術驅動型的公司就不遠了(O(∩_∩)O~~)。