編者按：

7月12日，weibo上 @自律自強 發表了一條微博：十幾年來的軟件項目經歷告訴我，評審是最有效也是成本最低的質量保證和提升的手段，設計書和代碼100%肉眼全覆蓋絕對值得，而且還是迅速提高新人能力及其成果物的規范性的有效手段。

各路朋友紛紛參與討論，各有觀點，真知灼見也許就在其中，讀來很有收益。所以匯總得本文。

@自律則強 ?十幾年來的軟件項目經歷告訴我，評審是最有效也是成本最低的質量保證和提升的手段，設計書和代碼100%肉眼全覆蓋絕對值得，而且還是迅速提高新人能力及其成果物的規范性的有效手段。


BG4DUK：同感！但同樣蘊含著巨大的風險即無產出。其背后原因是僅僅依賴人。好的辦法是行程review的辦法，步驟等等，同時不斷匯總評估review的質量，才能真正做好


liangjz：目前實踐看輸出一般，對人依賴重


女皇碎碎：評審耗時多，規則的定義也比較難。。。沒結果前，領導都不愿抽出多余的人力，時力做這


至簡李云：對于評審的實施，發自內心地改變意識是關鍵，不然效果一定不好。?


自律則強：意識不改變，在資源的投入上就會縮手縮腳；只有把評審做到位，才能體會到評審活動的高效，初級團隊那種走馬觀花式的“評審”，是浪費時間，不是真正的評審。到位地完成評審后，會有那種對系統質量“踏實了”的感覺，之后輔以嚴密的變更管理，系統質量就不會出大問題


自律則強：歸根到底，系統質量是要靠上游工程做出來的，依賴下游工程(種種測試)來把質量關，不僅低效而且昂貴。


高阿達：質量保證需要讓上游可以時刻俯瞰下游的每一個細節。


jackywgw：確實如此，不過能堅持認真評審下來的公司和團隊也確實不多


張克強-敏捷307：贊同。在多種評審形式中，雙人同級互查是最經濟的，性價比高，值得推薦


武劍鋒：贊同。不過獨立測試仍然有很高價值。再好的設計人員也有局限。?


張克強-敏捷307：Yes，測試與評審不可互相替代。但最困難的是多數團隊不相信100%覆蓋的代碼評審能夠帶來正收益，所以不嘗試。前期各項質量保證手段往往通過測試階段的縮短來獲得項目中的收益。


火星人陳勇：我最相信肉眼，肉眼看過感覺不舒服的代碼，即使看不到直接的bug，也要改。


張克強-敏捷307：回復@火星人陳勇:贊！為了提高效率，我同樣推薦代碼檢查工具，工具可以把不符合既定義規則的地方找出來。但工具不能替代人。 推薦工具先查，然后肉眼再看?




李智勇SZ：回復@項目管理郭致星:現在我這邊限制取得更大成果的主因素是：代碼的熟悉程度與項目的有效時間。一旦跨領域代碼量又大，人員對代碼的理解就直接限制評審的深度。一旦時間逼的緊，評審的優先級往往會被降低。而留給評審的時間似乎總不夠。各位那里什么狀況?


張克強-敏捷307：看到的最大障礙：進度緊張，工作量有限，沒時間搞代碼評審。


PMO之道---蔡德輝：IT行業缺少質量保證手段，也缺少質量專家來進行研究與推廣。評審是其中最有效的手段之一。測試本來是驗證手段，現在變成了找Bug手段，所以IT行業質量成本在40%以上，這是巨大的浪費，但我們好像沒找到啥好辦法。


拯救與逍遙：最大的障礙是從來就不知道代碼評審的好處，自然也就排不出時間


火星人陳勇：正在評測resharper，先用工具弄到零錯誤，再肉眼。


火星人陳勇：回復@朱少民:我們現在很重視工具的警告，要仔細看明白才能處理，也因此不讓工具自動運行，要人做出判斷。 //@朱少民:所以嗎，工具作用也不可忽視，沒必要肉眼100%?


PMO之道---蔡德輝：回復@質量市場學:是應該總結出來IT項目質量保證方法，從策劃開始保證質量。測試作為最后的手段，現在的研究把測試前移到開發前，這還不夠。至少目前應該大力推廣評審，接下來應在策劃和設計階段推廣潛在失效分析等。現在不是方法多，而是少，并且沒被掌握。所以就無所謂按照實際情況調整了。


蟈蟈俊：前期要有技術評審，后期要有Code Review。


袁斌_AgileDo：Bug是代碼注入的，如果在寫代碼之前和寫代碼過程中消除bug的風險，則會減輕評審的壓力


自律則強：有經驗數據顯示，代碼完成后，即使程序員經驗豐富，每KLOC中也會注入12-16件Bug,有效地評審應該摘出大約2/3(7-10件)，而且使程序有良好的結構


pkuxkxjason：相當贊同。不過我不贊同“評審”這個詞，英文code review比較準確。這是一個大家一起來讀代碼，通過頭腦風暴，早期檢出問題的過程。不是評，更不是審。有很多code review搞成了參會人員指點江山，代碼作者極力自衛。在我做code view的經歷中，幾乎每次都能檢出重大問題，而且對形成優良代碼結構有益。


Glen-Wang：評審是社會化活動 1. 威懾被評審者 2.評審者學習


張克強-敏捷307：寶信軟件伍治平和我早在n年前寫過一篇論文，強調高頻次小增量全覆蓋的代碼評審是代碼評審的好實踐。


王忠杰rainy：代碼評審和自動測試要配合起來。


Bluebell--半失業中：貌似國內喜歡搞成過堂，我們是每段代碼提交前都必須code review,reviewer 可以由自己邀請對這塊比較熟悉的其他開發人員，一個人通過就行，當然將來這段代碼出問題了，reviewer 也要擔責。


pkuxkxjason：不使用。code review主要流程由開發者先介紹需求和針對需求的設計與實現。其他人針對需求review代碼。 //@守候_盛開:請問使用checklist么？


stephen_wang_7971：我還是堅持：度量千行代碼bug率不僅沒有正面意義，反而誤導開發人員把質量做的更差。因為其公式定義決定了：要是沒有辦法減少bug那就增加代碼行數。而增加行數會引入新的bug。度量密度是為了減少密度，結果卻增加了密度。


lvxinke：有人會故意把代碼寫得裹腳布。我的觀點，可以度量作為參考，但不能作為考量，影響程序猿的職業心智。


lvxinke：我想說的，工具、統計都不是問題，關鍵是這些數據用來干什么。 //@自律則強: 在有統計意義的樣式空間中，有些發生幾乎是從然的，這是科學不是巫術。


自律則強：我更喜歡做的是，通讀所有代碼，把其中的錯誤和認為不是好程序的地方指出來，如：變量和方法的命名是否準確，是否有注釋的作用，對內存使用是否粗暴無禮，程序結構是否思路順暢，自然美觀等等。然后再比對數據，它就在那里，沒有太多刻意。


Jack_孫長虹：看度量為誰所用，如果開發者用來自我評估和改進，還是很有價值的。?


hackersoul：評審本身就要浪費大量時間和人力成本，有時候有問題也不一定是bug，效率或者沖突什么的更煩人


劉東流：認同，在項目初期有效審查代碼保證了后期開發的規范。逐行審查代碼很多人認為麻煩，但為后期打下夯實基礎。開始累點，讓開發人員形成習慣，后期就輕松，并且還有質量保證。


__漁舟唱晚__：“引入階段”是確實存在的：例如有制造缺陷的汽車可以返修，而有設計缺陷的汽車則必須召回。對用戶而言是制造的問題，對廠商而言則是設計的問題。“引入階段”的分析正是“明確責任，以圖改進”。

總結

以上是生活随笔為你收集整理的关于代码评审的微博讨论汇集的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。