最近被要求做乙個關於code review的講演。首先要說明的是，我並不是太擅長開展code review的活動。做這個完全是因為答應了別人又不好反悔。不過在做準備的過程中還是有一些感想。
關於code review我所了解到的行業中最著名的是bill gates匯報。這是微軟在軟體開發過程中的乙個重要環節，因為bill gates親自參加而備受關注，在行業中廣為流傳。
ok，進入正題了。
我們面臨的共同問題：
1、對於開發周期較長的軟體專案，可維護差的**對專案造成了極大的困擾
2、結構複雜的，體系不清楚的**會導致新成員或者外部干係人很難融入。
3、軟體專案**質量低下，bug眾多並且有關聯累積效應。
以上三個問題是我在以往的code review活動中總結出來，可以被影響或者解決的問題。也就是說我的觀點是如果沒有上述問題，或者在目前的軟體產品的規模、開發過程的成熟度還沒有達到一定級別時code review是可以不做的。當然優秀的開發人員會做自我審查，這是另外乙個問題了。
總而言之，我認為開展code review活動的前提是
1、開發過程和質量控制達到了一定的成熟的。
code review必然與重構相關聯。如果開發過程中更本就沒有重構這樣的活動，那估計review出來的結果不太容易得到執行。
其次是各種標準和規範的齊備性，沒有規矩是不能成方圓的，如果只有乙個命名規範，那可想而知review的內容不會太深入，效果因此大打折扣。
2、**達到一定那個的規模一般來說，功能單一的小型專案的體系結構不會太複雜。不太會出現bug的累積效應。小型專案完全可以通過daily meeting和test來保證。
code review並不是乙個隨便就可以做，或者做了就有好結果的活動。不過無論如何，一旦條件成熟或者資源充足都應該積極的開展code review的活動。因為它除了進行質量控制以外，還是乙個團隊成員之間進行溝通和相互學習的好機會。
code review的內容：
1、**的規範性
a、混亂而散漫的命名，例如使用a、b、c這樣的單字母對變數進行無意義的命名
b、隨處可見的magic number或則hard code。軟體中const在所難免，不過這些const應該被集中管理起來。而不是可以隨意、隨處的出現
c、缺少注釋，或者注釋不完備甚至錯誤
2、**的結構問題
a、巨大的類或者巨大的方法
b、過於複雜的實現
c、緊耦合
d、重複的**
3、其他問題
a、缺少驗證和異常處理。例如不對資料進行驗證，或者不處理異常又或者捕獲無法處理的異常
b、對工具和框架的錯誤使用。例如有的orm框架提供非常方便的執行時延遲載入功能，方便倒是方便，濫用卻會有效能隱憂
c、缺少可讀性。注釋和命名規範是乙個問題，不過過深的呼叫層次都會影響**可讀性。
d、缺少擴充套件性。例如在沒有dlr的情況下在業務層使用匿名物件。
e、缺少安全控制
f、效能隱患。例如在c#中使用了非託管資源而沒有進行釋放，或者說有過多、過於頻繁的i/o訪問
4、測試問題
a、沒有測試或者覆蓋度不夠
b、測試**滯後，在更改邏輯後沒有對測試進行同步更新
以上是一些通常的code review的內容了。當然這裡再強調一點的就是規範的完備性，和開發過程的成熟度。code review是一種相對高階軟體開發活動，沒有必要一定要執行。不過一旦實施成功將會有巨大的回報。
在實施過程中還有一些心得：
1、做好準備。如果對專案很熟的話，應該知道哪些地方會有問題，code review是重新審視和從內因上解決這些問題的良機。
2、不要考慮業務邏輯。完全專注於**的實現，例如演算法的效率，抽象的粒度。整個**體系結構的平衡性
3、虛心學習。不要有針對性
4、在原則和現實之間平衡。不可能所有事情都完美，所以有的時候我們堅持原則，有的時候修改規範。
5、不要讓自己review自己的**
6、總結跟進review的結果，並且堅持開展這個活動。這才是最重要的
***********************************=分割線******************************==
如何做好Code Review？
一 背景 最近隨著交易業務快速擴充套件，研發組內新專案及新成員越來越多，如何做好code review，把控研發人員開發 質量很是關鍵。對於大部分業務團隊，談到code review就會面露哀狀 上線時間倒排，研發工期這麼緊，連碼 的時間都不夠了，你還要我cr？上版的需求，這版就變了，生命週期太短，...
如何做好PL
最近事情太多，主要有三類 新專案開發，開發團隊有8個人，維護版本過tr5點，如果測試提出問題，必須保證問題單不能過夜，當天解決。網上問題，產品技術問題支援。結果，這個星期有三天晚上是1點後回家的，我在想。pl到底是怎麼樣乙個角色？是管理還是技術主導多一些？那些問題其實組員是能夠搞定的，但是我之前已經...
如何做好專案？
如何評價專案的好壞 從客戶角度 功能 按期，效益，體驗，穩定性 效能 擴充套件 按期完成功能是一定的，不然會被辭退，績效考核才是最重要的 穩定性的指標 可用性 績效考核指標 分鐘 故障分鐘 總分鐘 乙個專案的開發流程 需求 文件 原型 需求可行性 設計 技術選型 技術，測試人員測試，ui設計 ui，...