三年 0 故障總結 —— 阿里B2B技術部

阿里技術部

源碼堂(不聞) · 2015-05-05 17:33

原文地址：http://weibo.com/p/230418e59371cc0102vhmv

近段時間我的團隊，其他團隊一直在強調代碼質量,減少故障。入職快三年半了，距離我上次故障也快三年半了，所以在這方面有些感觸和大家分享一下,我從 個人經歷, 代碼質量理解,以及針對代碼質量這塊的 工作習慣三個方面來分析總結一下。

個人經歷

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

• 團隊編碼風格統(tǒng)一

• 統(tǒng)一到什么程度?不看代碼作者，你很難區(qū)分代碼是誰寫的(在目前公司一些團隊也能達到這個標準)。

個人觀點:

1. 這樣做有什么好處？團隊中每個人閱讀代碼都很容易，減少很多溝通,維護成本( 代碼閱讀的次數遠遠大于變更的次數)，并且心情非常愉悅。有人肯定覺得愉悅有點夸張，舉個栗子:有一些代碼，如果不是由于與工作內容有關聯(lián)，你是否有種這輩子都不情愿去接觸它的感受。但也有一些代碼，閱讀下來一氣呵成，心情舒暢，促使你有種繼續(xù)閱讀下去的沖動(并且你也會有種不想破壞這種統(tǒng)一的想法).

2. 基礎層面越統(tǒng)一，效率越高(不僅僅是指統(tǒng)一編碼規(guī)范，還有基本的做事的原則).舉個栗子:我們團隊規(guī)定個人周報必須在每周五上班前必須發(fā)出來，否則罰款10元。之前團隊周報遲發(fā)現象比較突出，規(guī)則一出，明顯改善(開會缺席情況也一樣得到明顯改善)。罰錢是否不太合理？注釋寫多少才算合理？與其花大量精力討論這些不痛不癢的問題，不如及時統(tǒng)一規(guī)范(一般制定的規(guī)范不會差的)，嚴格執(zhí)行。后續(xù)針對問題即使做調整。關鍵是統(tǒng)一和嚴格執(zhí)行。

***************************************************

• 代碼簡潔

• 能1行解決就不要寫2行(不影響可讀性的情況下)

• 多余的代碼(比如注釋代碼or 無實際意義)必須刪除

個人觀點: 大家都懂的, 沒啥好說的

*************************************************

• codereview

• 團隊的PLA(團隊骨干)進行codereview,團隊中PLA之間的代碼質量意識/以及代碼規(guī)范非常統(tǒng)一.不會出現一個團隊，多個標準的情況

• 每周五周會會對這周代碼review出來的問題進行回顧，得出結論。將例子放在wiki上，以供后續(xù)遇到類似問題的一個參照。新同學也可參照此內容學習規(guī)范，避免犯同類問題。規(guī)范中很多內容就是這么累計起來的。

個人觀點:

1. 我在阿里所經歷的一個團隊中，PLA有3,4位,分別負責各自的一塊業(yè)務。PLA之間codereview很少,代碼質量的意識交流似乎也不多。但團隊的普通開發(fā)同學在這些PLA之間輪流被codereview,代碼質量的評比標準差異較大。這可能會導致2種現象:開發(fā)傾向review寬松的同學,因為寬松review發(fā)現問題(不僅僅是bug)較少，變動成本不大，不會有改動造成的故障風險，不會影響項目進度(但后續(xù)的維護和溝通成本會明顯增加);另一種現象,開發(fā)向不同的PLA提出疑義，PLA之間統(tǒng)一代碼質量標準，在團隊內達成共識并形成文檔，以作為后續(xù)參考。

2. 一個團隊的代碼質量主要取決于團隊幾位PLA，建議團隊早期先統(tǒng)一PLA的代碼質量意識和規(guī)范。例如:先由1-2位PLA對整個團隊開發(fā)做review,這個review工作量初期會很大,并且團隊工作效率不高，但后期的review工作量應該會明顯減小, 代碼質量也會明顯提高, 團隊的工作效率也會明顯提升.我在外企這家公司剛入職的那一個月是我最痛苦的一個月，被codereview感覺很不適應:和以前編碼習慣差異較大，review太嚴格(變量名,空行,注釋有單詞語法錯誤也會糾正)，感覺限制編碼自由....1個多月后體會到了明顯的好處: 編碼bug少; 溝通少,代碼和注釋已經解決了大部分疑問;閱讀代碼效率高;感覺別人寫的代碼就像是自己寫的一樣,非常有親切感.一個多月后,revew我代碼的PLA明顯放松了對我review的內容，因為他已經很多次沒有review出問題，并且讓我在每次review前告知需重點review的內容即可。

   
   

**********************************************************

• 執(zhí)行力和壓力

• codereview出來的問題一旦得出結論，就會立馬執(zhí)行。如果有疑義，可以繼續(xù)討論，一直到得出結論為止。規(guī)范中的內容可以改進，但一旦形成規(guī)范就必須嚴格執(zhí)行。

• 一旦有不合規(guī)范的代碼提交上去，就會郵件提醒給團隊PLA以及老大，提醒次數多了還是繼續(xù)犯類似問題，甚至會勸退。

個人觀點:

1. 我在阿里所經歷的幾個部門規(guī)范都很不錯，但有的執(zhí)行起來卻比較寬松。因為項目進度一緊, 代碼質量就容易妥協(xié), 常見的現象"我下個版本會改過來的", "這個應該暫時沒有問題", "這個代碼是沒有按規(guī)范來做，但改動風險太大，出故障怎么辦". 這時候,如果你在這妥協(xié), 基本以后代碼規(guī)范就很難維持了。因為一旦ugly的代碼上線,這代碼很可能就會在項目里擴散開來(和破窗效應類似).
   

2. 很多人對代碼質量/規(guī)范有強烈的意識，但少數人可能感受不那么明顯或者還沒有體會到這些帶來的益處，或者和自己已有習慣差異而產生排斥心里，這時候得用外部壓力刺激一下。比如上面提到的每周五review當周的問題--沒人會愿意自己的代碼經常被拎出來作反面教材。迫使他朝正向發(fā)展,做到對事不對人就可以了。新人對壓力可能感觸更明顯，壓力會促使你做事更謹慎, 也有可能讓你做事畏首畏尾,這時候對新人要多加關注。

*************************************************************

代碼質量理解

• 代碼的可讀性放在第一位,代碼盡量做到don't make me think( 這里對集團中間件的開發(fā)同學提個建議，希望你們繼續(xù)提高代碼的可讀性，因為你們的代碼被閱讀了無數遍了，你們提高一點可讀性，將節(jié)約很多人的時間,你們的代碼很可能被很多同學模仿)

• 沒有bug的代碼不一定是高質量的代碼, 寫代碼不能緊緊滿足于功能

• 你的代碼規(guī)范不一定要達到開源規(guī)范標準(能達到最好)，但不要低(松)于團隊的代碼規(guī)范.

• 寫代碼要有敬畏之心。想想如果讓你開發(fā)載人火箭的程序,你敢隨意去寫么? 網站一樣需要重視.

• 團隊的代碼質量重要程度高于個人代碼質量。如果只滿足個人代碼質量提高，而不去幫助團隊提高代碼質量，你很可能會踩上別人留下的坑，你在工作中很可能遇到各種不便(當然你也要避免給其他人留坑)。

• 良好的代碼規(guī)范不一定會讓你避免bug.但可以幫助你/他人提升找到bug的速度, 以及提升工作效率

• 讀優(yōu)秀的源碼(書籍),關注一些細節(jié)，對代碼質量提升非常有幫助.

• codereview不僅僅是為了review出bug。這也是知識分享的一個過程，團隊更有經驗的同學會對你的代碼提出建議;review人員可以從中獲取業(yè)務/技術相關信息;被review人員因為有人會review你的代碼，而不得不提升自己的代碼質量，以及代碼的熟悉程度。

• 代碼規(guī)范不會影響開發(fā)效率,你的開發(fā)效率應該通過其他的方式去提升。 相反，他會節(jié)省你很多成本(閱讀,溝通)

• 故障多少和自己的技術能力關系其實不是很大,和自身的工作習慣非常大(我看了很多故障案例,絕大多數不是開發(fā)同學沒有相應的技術能力)

• 對自己擅長什么，不擅長什么要有清楚的認識.有的故障產生的原因是對自己某方面能力太過自信.在不擅長的地方去咨詢其他有經驗的同學，這不會顯得自己能力差,反而給他人的印象是你很重視你的工作，工作謹慎.

工作習慣

• 當你拿到需求時,分析下自己的需求功能點的重要性(不同重要程度的需求，重視程度和花費的精力也不一樣).

• 設計時多花點時間思考,編碼通常是比較快的

• 單元測試一定要寫,這是底線(除非這個成本非常大)

• findbugs，pmd這些工具在前幾年我用的比較多，但近幾年用的已經很少了，原因是發(fā)現的問題少,誤判的幾率還高，現在只是少數情況才會使用。但是新人建議還是多使用一下。

• 在團隊中尋找比你代碼質量要求更高的同學來review自己的代碼，一起探討問題，這能幫自己很快的提升。有疑義的地方一定要達成共識，立刻執(zhí)行，并告知團隊，并形成規(guī)范。

• 盡量不要在情緒低落，體力不支的情況下做需要大量思考性的工作(我個人比較喜歡運動,體力不支的情況比較多.哈哈).

• 寫代碼就難免會有bug/故障發(fā)生.另外一種避免故障的方案是如何盡快知道異常情況(比如做好監(jiān)控),在用戶投訴之前盡快解決掉，或者提前做好預備方案(通常是比較重要的需求).

• 不要因為錯小而放置不理，那會成為你的習慣。

• 周四盡量減少發(fā)布,你可能沒有足夠時間去觀察/驗證,發(fā)布時尤其需要重視.

• 讀源碼是我比較喜歡做的一件事情。一方面能夠熟悉一些技術原理/業(yè)務，開發(fā)時更胸有成竹，bug的幾率當然也越少，當然你花費的時間可能就會多(你得去衡量).這個做法也是不得已而為之: 一些部門的文檔/代碼注釋都有問題,溝通又可能不便，讀源碼反而解決問題比較快.

• 當別人向你提建議時,心胸開闊點, 你會獲取他人更多的幫助機會/建議

續(xù)

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

舉幾個栗子:

• 你的老板是否能夠接受短期工作效率普遍偏低么(如果采用我在文章中提到的codereview方案)?

• 團隊成員是否都和你有類似的代碼質量理念, 如果沒有, 你得不斷去影響他們, 得影響你的老板。 如果做不到, 落地也無從說起.

• 每次故障頻率比較高的時候,高層傳達的意思是重視用戶體驗,提升代碼質量。到開發(fā)這里，可能是采取更安全的編碼, 但不一定是合理的.要不了多長時間，代碼一定會變質.

坦白講, 我沒有很完整的, 可量化的, 可復制的方案, 我現在所在的團隊也沒有達到這個標準,但我在alibaba經歷過這樣的團隊,一個讓我終身難忘的團隊(還有那家外企)。這樣更加讓我堅信我上面的這些想法應該是能落地的, 我也正在努力去影響我現在所在的團隊,即使達不到我預想的那樣, 但我相信一定會有改善.