程式碼審查：好事？壞事？

　　在軟體開發領域，程式碼審檢視起來是一個少有爭議、相當平和的話題。

　　主流觀點普遍認為程式碼審查是個好東西。有些公司或組織甚至強制要求把程式碼互審作為必須的流程。

　　審查是一種捕捉bug和問題的好措施。通過程式碼審查能夠分享領域知識，提高程式碼質量。程式碼審查提供了一個對團隊進行監控，教育和強化的好機會。

　　至少理論上是這樣的…

　　當挽起袖子開幹，當面對真正的專案計劃產生的壓力時，程式碼審查很有可能轉而變成一件壞事。

　　審查是一種能夠導致憎恨和分裂的活動。它能使人對編寫的程式碼是否正確產生懷疑，會激起人們為他們自己的編碼標準而宣揚說教。程式碼審查是一種日常活動，它執行的正確與否帶來的是團隊的開發效率的提升或是扼殺。

　　對於一個團隊，有效的程式碼審查走的是一條中庸的路線——它既不會成為解決一切問題的銀彈，也不會成為傷害團隊的毒藥。

　　經過一些思考和跟一些同事討論之後，我認為，成功的程式碼審查的關於因素是 信任和訓練。

　　團隊成員必須相信，來自程式碼審查中的反饋意見並不是對個人攻擊或對自己能力的評判。審查者必須相信，受審查者不會因為你提出了改進意見而憎恨你。

　　團隊成員必須把程式碼稽核看著是一個能不斷得到建設性反饋意見的平臺，而不是用來對團隊成員評分評級或製造消極激進言論的工具。

　　當一個團隊組成時，信任並不是天生就存在於團隊成員中的。

　　而訓練人們如何正確的展開一次程式碼審查，可以讓人們在審查過程中建立信任。

　　所有我呆過的專案團隊中，我發現，學習如何正確的做程式碼審查的方法就是讓大家審查自己的程式碼。這樣之後，你才會知道如何給別人做程式碼審查！這種方法提供了很多真實情景來解釋如何進行程式碼審查。

　　訓練新手如何正確的提出評審意見，告訴他們應該關注什麼才能給有經驗的程式設計師提出有價值的意見。指導團隊負責人在合適的時候給予評審者支援，點出有意義的評審意見，這樣能強化團隊的信任，使團隊成員互相尊敬。

　　那麼，程式碼審查是好事還是壞事呢？

　　這依賴於你的團隊的願望，是否努力把它變成一種積極的措施。就像對於任何這種開發方法論，簡單拿過來用是不行的——你必須保證你在以正確的方式用它。

　　原文連結：Code Reviews: Good idea, bad idea?