重讀 code complete 說說代碼質量

重讀code complete 說說代碼質量

2014年的第一篇文章原本計劃寫些過去一年的總結和新年展望，可是由於還有一些事情要過一陣才能完成，因此姑且不談這個，說說最近重讀code complete 的收穫吧。

記得第一次讀code complete 仍是剛畢業的時候，身邊好多朋友極力向我推薦此書，因而我就買了一本讀起來，多是當時功力不夠，讀起來老是以爲沒啥味道，並且極爲枯燥，總以爲不如<深刻淺出MFC>，<CLR Var C#>，<Windows Internals>等來的痛快，惶惶不得其精髓，只是當小說同樣草草看了一遍。

慢慢的隨着工做深刻，本身也參與到更多的開發週期中，好比Plan, 配置團隊，作計劃，代碼審查，控制代碼質量，尤爲是近兩年，每當我看到某些team member一會兒提交幾十個源文件讓我來審查我就有些爲難。首先，這麼多的代碼是一個工程師近一個月的工做量，而審查的時間一般只有1天，這無疑給保證代碼質量形成了極大的隱患。說實話我遇到這種狀況是的情緒是極爲複雜的，我對這樣的事情也是極爲反感的，這個作根本就是不負責任。固然我也能夠不負責任，隨便看看就pass， 可是反過來想一想，一會兒把一個系統中加入那麼多的代碼，而讓其餘幹別的工做的人用那麼短的時間去review你幾個月的工做自己就是耍流氓。我一般的辦法是既然你耍流氓，那我就不客氣了，我在你的每一個文件上都給你加上幾十個有建設性comments 讓你去改，而後在別人改代碼的時候我再繼續審查在審查代碼。

閒下來的時候往往回憶這樣的事情，實在是太浪費時間了，我就問問本身能不能有辦法處理這些相似問題呢，軟件工程發展到今天，必定有無數的人遇到過這樣的問題，我所須要作的應該只有學習就夠了。

看看下面的條目：

1. 好比一個項目計劃作多久比較合理，計劃文檔應該寫到什麼程度
2. 代碼審查一次提交多少比較適合
3. 如何保證代碼質量
4. 如何配置工程師
5. 如何高效玩轉整個開發週期和流程

　　　　…

有多少是常常困擾你的呢? 固然若是這些問題你都沒想過，或者全靠拍腦殼，那我也很差說你什麼啦。對於一樣的問題，有些團隊就能夠處理的很是好，而有些團隊就極爲混亂，我不能說某些團隊不行，要怪也只能說團隊的領導不行，根本沒辦法駕馭這些問題。

帶着這些問題在最近的兩年我在桌上放了兩本code complete, 一本中文，一本英文原版，每當遇到相似的問題我就問問它，固然有些問題，它裏面也沒有描述，其實也不怎麼全，呵呵。可是大部分的問題仍是讓我受益不淺。

 

按照我對每一個問題的理解我對每種狀況做了相應的總結，造成規範，首先本身follow，而後慢慢的潛移默化給整個團隊，我發現慢慢的你們的開發效率，代碼質量和代碼審查效率都有了顯著的提升。

這一輪帶着經驗，帶着問題讀code complete 讓我受益不淺，若是非要總結緣由的話，我想說的是，其實代碼大全最少要讀兩遍，由於沒寫過必定的代碼，沒遇到過必定的問題去讀它是不可能明白所有的精髓。