重讀code complete 說說代碼質量
2014年的第一篇文章本來計划寫些過去一年的總結和新年展望，但是因為還有一些事情要過一陣才能完成，所以姑且不談這個，說說最近重讀code complete 的收獲吧。
記得第一次讀code complete 還是剛畢業的時候，身邊好多朋友極力向我推薦此書，於是我就買了一本讀起來，可能是當時功力不夠，讀起來總是覺得沒啥味道，而且極為枯燥，總覺得不如<深入淺出MFC>，<CLR Var C#>，<Windows Internals>等來的痛快，惶惶不得其精髓，只是當小說一樣草草看了一遍。
慢慢的隨着工作深入，自己也參與到更多的開發周期中，比如Plan, 配置團隊，做計划，代碼審查，控制代碼質量，尤其是近兩年，每當我看到某些team member一下子提交幾十個源文件讓我來審查我就有些為難。首先，這么多的代碼是一個工程師近一個月的工作量，而審查的時間通常只有1天，這無疑給保證代碼質量造成了極大的隱患。說實話我遇到這種情況是的情緒是極為復雜的，我對這樣的事情也是極為反感的，這個做根本就是不負責任。當然我也可以不負責任，隨便看看就pass， 但是反過來想想，一下子把一個系統中加入那么多的代碼，而讓其他干別的工作的人用那么短的時間去review你幾個月的工作本身就是耍流氓。我通常的辦法是既然你耍流氓，那我就不客氣了，我在你的每個文件上都給你加上幾十個有建設性comments 讓你去改，然后在別人改代碼的時候我再繼續審查在審查代碼。
閑下來的時候每每回憶這樣的事情，實在是太浪費時間了，我就問問自己能不能有辦法處理這些類似問題呢，軟件工程發展到今天，一定有無數的人遇到過這樣的問題，我所需要做的應該只有學習就夠了。
看看下面的條目：
- 比如一個項目計划做多久比較合理，計划文檔應該寫到什么程度
- 代碼審查一次提交多少比較適合
- 如何保證代碼質量
- 如何配置工程師
- 如何高效玩轉整個開發周期和流程
…
有多少是經常困擾你的呢? 當然如果這些問題你都沒想過，或者全靠拍腦袋，那我也不好說你什么啦。對於同樣的問題，有些團隊就可以處理的非常好，而有些團隊就極為混亂，我不能說某些團隊不行，要怪也只能說團隊的領導不行，根本沒辦法駕馭這些問題。
帶着這些問題在最近的兩年我在桌上放了兩本code complete, 一本中文，一本英文原版，每當遇到類似的問題我就問問它，當然有些問題，它里面也沒有描述，其實也不怎么全，呵呵。但是大部分的問題還是讓我受益匪淺。
按照我對每個問題的理解我對每種情況作了相應的總結，形成規范，首先自己follow，然后慢慢的潛移默化給整個團隊，我發現慢慢的大家的開發效率，代碼質量和代碼審查效率都有了顯著的提高。
這一輪帶着經驗，帶着問題讀code complete 讓我受益匪淺，如果非要總結原因的話，我想說的是，其實代碼大全最少要讀兩遍，因為沒寫過一定的代碼，沒遇到過一定的問題去讀它是不可能明白全部的精髓。