該文章來自於雲棲社區，作者不聞，就職於阿里巴巴。此文章發佈於2015年，小編覺得仍然有其現實意義，所謂 "年年歲歲錯相似，歲歲年年人不同"，又道太陽底下無新事。對於作者的不少觀點，小編深感認同，比如嚴格遵守代碼review規約、嚴格執行review制度，不因爲工期而妥協、對於pmd這些檢查工具，小編還是提倡採用，代碼review的精力放在邏輯和設計上去，對於可以規則化定義的內容，交給工具。至於工具規則過多或者少，進行定製即可。
近段時間我的團隊，其他團隊一直在強調代碼質量,減少故障。入職快三年半了，距離我上次故障也快三年半了，所以在這方面有些感觸和大家分享一下,我從 個人經歷 , 代碼質量理解,以及針對代碼質量這塊的 工作習慣三個方面來分析總結一下。
個人經歷
對我代碼質量影響最大的是在一家外資企業，在這家公司我覺得有以下幾個方面做的很不錯。
團隊編碼風格統一
統一到什麼程度?不看代碼作者，你很難區分代碼是誰寫的(在目前公司一些團隊也能達到這個標準)。
個人觀點:這樣做有什麼好處？團隊中每個人閱讀代碼都很容易，減少很多溝通,維護成本( 代碼閱讀的次數遠遠大於變更的次數)，並且心情非常愉悅。有人肯定覺得愉悅有點誇張，舉個栗子:有一些代碼，如果不是由於與工作內容有關聯，你是否有種這輩子都不情願去接觸它的感受。但也有一些代碼，閱讀下來一氣呵成，心情舒暢，促使你有種繼續閱讀下去的衝動(並且你也會有種不想破壞這種統一的想法).
基礎層面越統一，效率越高(不僅僅是指統一編碼規範，還有基本的做事的原則).舉個栗子:我們團隊規定個人週報必須在每週五上班前必須發出來，否則罰款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你的代碼，而不得不提升自己的代碼質量，以及代碼的熟悉程度。
代碼規範不會影響開發效率,你的開發效率應該通過其他的方式去提升。 相反，他會節省你很多成本(閱讀,溝通)
故障多少和自己的技術能力關係其實不是很大,和自身的工作習慣非常大(我看了很多故障案例,絕大多數不是開發同學沒有相應的技術能力)
對自己擅長什麼，不擅長什麼要有清楚的認識.有的故障產生的原因是對自己某方面能力太過自信.在不擅長的地方去諮詢其他有經驗的同學，這不會顯得自己能力差,反而給他人的印象是你很重視你的工作，工作謹慎.
工作習慣
當你拿到需求時,分析下自己的需求功能點的重要性(不同重要程度的需求，重視程度和花費的精力也不一樣).
設計時多花點時間思考,編碼通常是比較快的
單元測試一定要寫,這是底線(除非這個成本非常大)
findbugs，pmd這些工具在前幾年我用的比較多，但近幾年用的已經很少了，原因是發現的問題少,誤判的機率還高，現在只是少數情況纔會使用。但是新人建議還是多使用一下。
在團隊中尋找比你代碼質量要求更高的同學來review自己的代碼，一起探討問題，這能幫自己很快的提升。有疑義的地方一定要達成共識，立刻執行，並告知團隊，並形成規範。
儘量不要在情緒低落，體力不支的情況下做需要大量思考性的工作(我個人比較喜歡運動,體力不支的情況比較多.哈哈).
寫代碼就難免會有bug/故障發生.另外一種避免故障的方案是如何儘快知道異常情況(比如做好監控),在用戶投訴之前儘快解決掉，或者提前做好預備方案(通常是比較重要的需求).
不要因爲錯小而放置不理，那會成爲你的習慣。
週四儘量減少發佈,你可能沒有足夠時間去觀察/驗證,發佈時尤其需要重視.
讀源碼是我比較喜歡做的一件事情。一方面能夠熟悉一些技術原理/業務，開發時更胸有成竹，bug的機率當然也越少，當然你花費的時間可能就會多(你得去衡量).這個做法也是不得已而爲之: 一些部門的文檔/代碼註釋都有問題,溝通又可能不便，讀源碼反而解決問題比較快.
當別人向你提建議時,心胸開闊點, 你會獲取他人更多的幫助機會/建議
續
這篇文章被關注的程度遠遠超出了我的想像,原本我並不打算在文章裏過多去描述一些影響代碼質量的現象，但是評論裏提到的問題(比如說如何落地)多少都涉及這些。文章裏主要是從普通開發的角度去看代碼質量，關於如何落地,我知道落地肯定不容易, 肯定會面臨很多來自團隊內外的壓力.
舉幾個栗子:
你的老闆是否能夠接受短期工作效率普遍偏低麼(如果採用我在文章中提到的codereview方案)?
團隊成員是否都和你有類似的代碼質量理念, 如果沒有, 你得不斷去影響他們, 得影響你的老闆。 如果做不到, 落地也無從說起.
每次故障頻率比較高的時候,高層傳達的意思是重視用戶體驗,提升代碼質量。到開發這裏，可能是採取更安全的編碼, 但不一定是合理的.要不了多長時間，代碼一定會變質.
坦白講, 我沒有很完整的, 可量化的, 可複製的方案, 我現在所在的團隊也沒有達到這個標準,但我在alibaba經歷過這樣的團隊,一個讓我終身難忘的團隊(還有那家外企)。這樣更加讓我堅信我上面的這些想法應該是能落地的, 我也正在努力去影響我現在所在的團隊,即使達不到我預想的那樣, 但我相信一定會有改善.