淺談項目管理中該如何review與重構
本文之前的內容，請訪問《我們如何開始對項目進行管理：文檔很重要》和《我們如何開始對項目進行管理：需要什么樣的人》
（五）review和重構
說到review，有些筒子可能立刻就想到了：吵架。確實，有的時候review真的可能演變成吵架，但是我們為了項目的成功，這個風險一定要冒，慢慢成熟以后，被人批評的次數多了，臉皮厚點兒就好了。；）玩笑歸玩笑，review確實是需要技巧的：在review別人的代碼時，要注意你的話語有時會傷害別人的自尊心，讓別人覺得你是在雞蛋里頭挑骨頭；在別人review你的代碼時，同樣的你也會覺得別人是在雞蛋里頭挑骨頭，傷害你的自尊心。這里我也沒有太多的技巧可言，一句話，換位思考，臉皮厚點兒吧。哈。
Review可能分成以下幾種：
1， 設計的review。說起review大家更多想到的是大家坐在一起邊侃大山邊看別人的代碼，其實設計的review是更加重要的和更加高級的，也是更有價值的，問題發現的早解決的代價就小嘛。在review別人或者自己的設計時，我們都能學到別人的設計理念，方法和技巧，這能大大提高團隊成員的能力。項目中的技術牛人，項目經理和技術骨干應該作為設計review的主力人員，多多談談自己的看法；同時也要注意尊重設計者的感情，讓大家都有收獲的同時，把項目做好。
2， 代碼的review。代碼review的形式可以多種多樣，兩個人坐在一起看看代碼也是一種review，也沒有必要非得所有人都湊齊。Review代碼的可以讓自己迅速成長，也能讓項目組成員熟悉別人的業務和代碼，以***程度減少人員變動造成的損失；同時也能讓代碼規范更加一致。
不管是設計review還是代碼review，都不一定要全部人員到場，這可能會浪費一些時間；但是設計的review最少要有一個技術骨干或者項目經理在場，否則review就會變成討論會進而升級成戰爭。
Review有時候也會被認為浪費時間，特別是很多程序員對review別人的代碼沒有任何興趣，也不愿意讓別人對自己的代碼說三道四。我想說，作為一個二十一世紀的軟件工程師，我們不但要善于對技術進行鉆研，更要善于把自己的技術傳播出去，也要善于通過別人的指點更快的提高自己的工作能力。這是一個開放的時代，是一個需要交流的時代，是一個迅速發展的時代，你慢，就就完蛋。
在review發現了很多問題之后，我們要怎么辦呢？對，重構。這幾年重構這個詞已經非常的火了，大家都說重構很重要，但是又有幾個人真正的去重構呢？有幾個人真正的不允許自己寫重復代碼呢？大家是不是還在說：“項目schedule太緊了，等有空了再優化吧”？我認為，這句話是有問題的，項目的總時間短，任務重，我們沒辦法；但是優化（重構）卻不會增加這種時間的壓力，相反的，重構會大大減少后續的開發和debug時間。因為重構后，出現的bug更容易被定為，更容易被fix；相反垃圾代碼引起的debug和fix bug的時間將遠遠大于重構的時間。
原文鏈接：http://www.cnblogs.com/GodSpeed/archive/2011/08/16/2140040.html
【編輯推薦】
