對我代碼質量影響最大的是在一家外資企業，在這家公司我覺得有以下幾個方面做的很不錯。
- 團隊編碼風格統一
- 統一到什麼程度? 不看代碼作者，你很難區分代碼是誰寫的(在目前公司一些團隊也能達到這個標準)。
個人觀點:
- 這樣做有什麼好處？團隊中每個人閱讀代碼都很容易，減少很多溝通,維護成本( 代碼閱讀的次數遠遠大於變更的次數)，並且心情非常愉悅。有人肯定覺得愉悅有點誇張，舉個栗子: 有一些代碼，如果不是由於與工作內容有關聯，你是否有種這輩子都不情願去接觸它的感受。但也有一些代碼，閱讀下來一氣呵成，心情舒暢，促使你有種繼續閱讀下去的衝動(並且你也會有種不想破壞這種統一的想法).
- 基礎層面越統一，效率越高(不僅僅是指統一編碼規範，還有基本的做事的原則) . 舉個栗子: 我們團隊規定個人週報必須在每週五上班前必須發出來，否則罰款10元。之前團隊週報遲發現象比較突出，規則一出，明顯改善(開會缺席情況也一樣得到明顯改 善)。罰錢是否不太合理？註釋寫多少才算合理？與其花大量精力討論這些不痛不癢的問題，不如及時統一規範(一般制定的規範不會差的)，嚴格執行。後續針對 問題即使做調整。關鍵是統一和嚴格執行。
- 代碼簡潔
- 能1行解決就不要寫2行(不影響可讀性的情況下)
- 多餘的代碼(比如註釋代碼 or 無實際意義)必須刪除
個人觀點: 大家都懂的, 沒啥好說的
- codereview
- 團隊的PLA(團隊骨幹)進行codereview, 團隊中PLA之間的代碼質量意識/以及代碼規範非常統一.不會出現一個團隊，多個標準的情況
- 每週五週會會對這周代碼review出來的問題進行回顧，得出結論。將例子放在wiki上，以供後續遇到類似問題的一個參照。新同學也可參照此內容學習規範，避免犯同類問題。規範中很多內容就是這麼累計起來的。
個人觀點:
- 我在阿里所經歷的一個團隊中，PLA有3,4位, 分別負責各自的一塊業務。PLA之間codereview很少,代碼質量的意識交流似乎也不多。但團隊的普通開發同學在這些PLA之間輪流被 codereview, 代碼質量的評比標準差異較大。這可能會導致2種現象:開發傾向review寬鬆的同學, 因為寬鬆review發現問題(不僅僅是bug)較少，變動成本不大，不會有改動造成的故障風險，不會影響項目進度(但後續的維護和溝通成本會明顯增 加);另一種現象, 開發向不同的PLA提出疑義，PLA之間統一代碼質量標準，在團隊內達成共識並形成文檔，以作為後續參考。
- 一個團隊的代碼質量主要取決於團隊幾位PLA，建議團隊早期先統一PLA的代碼質量意識和規範。例如: 先由1-2位PLA對整個團隊開發做review,這個review工作量初期會很大, 並且團隊工作效率不高，但後期的review工作量應該會明顯減小, 代碼質量也會明顯提高, 團隊的工作效率也會明顯提升.我在外企這家公司剛入職的那一個月是我最痛苦的一個月，被codereview感覺很不 適應:和以前編碼習慣差異較大，review太嚴格(變量名,空行,註釋有單詞語法錯誤也會糾正)，感覺限制編碼自由…. 1個多月後體會到了明顯的好處: 編碼bug少; 溝通少,代碼和註釋已經解決了大部分疑問;閱讀代碼效率高; 感覺別人寫的代碼就像是自己寫的一樣,非常有親切感.一個多月後, revew我代碼的PLA明顯放鬆了對我review的內容，因為他已經很多次沒有review出問題，並且讓我在每次review前告知需重點 review的內容即可。
- 執行力和壓力
- codereview出來的問題一旦得出結論，就會立馬執行。如果有疑義，可以繼續討論，一直到得出結論為止。規範中的內容可以改進，但一旦形成規範就必須嚴格執行。
- 一旦有不合規範的代碼提交上去，就會郵件提醒給團隊PLA以及老大，提醒次數多了還是繼續犯類似問題，甚至會勸退。
個人觀點:
- 我在阿里所經歷的幾個部門規範都很不錯，但有的執行起來卻比較寬鬆。因為項目進度一緊, 代碼質量就容易妥協, 常見的現象 “我下個版本會改過來的”, “這個應該暫時沒有問題”, “這個代碼是沒有按規範來做，但改動風險太大，出故障怎麼辦”. 這時候, 如果你在這妥協, 基本以後代碼規範就很難維持了。因為一旦ugly的代碼上線, 這代碼很可能就會在項目裡擴散開來(和破窗效應類似).
- 很多人對代碼質量/規範有強烈的意識，但少數人可能感受不那麼明顯或者還沒有體會到這些帶來的 益處，或者和自己已有習慣差異而產生排斥心裡，這時候得用外部壓力刺激一下。比如上面提到的每週五 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~~)。
八戒推薦
Linux高級運維架構【視頻教程】
Java版設計模式視頻【免費】
分享到:
閱讀更多 八戒程序猿 的文章
