本文之前的內(nèi)容，請訪問《我們?nèi)绾伍_始對項目進行管理：文檔很重要》和《我們?nèi)绾伍_始對項目進行管理：需要什么樣的人》

（五）review和重構(gòu)

　　說到review，有些筒子可能立刻就想到了：吵架。確實，有的時候review真的可能演變成吵架，但是我們?yōu)榱隧椖康某晒?，這個風(fēng)險一定要冒，慢慢成熟以后，被人批評的次數(shù)多了，臉皮厚點兒就好了。；）玩笑歸玩笑，review確實是需要技巧的：在review別人的代碼時，要注意你的話語有時會傷害別人的自尊心，讓別人覺得你是在雞蛋里頭挑骨頭；在別人review你的代碼時，同樣的你也會覺得別人是在雞蛋里頭挑骨頭，傷害你的自尊心。這里我也沒有太多的技巧可言，一句話，換位思考，臉皮厚點兒吧。哈。

　　Review可能分成以下幾種：

　　1， 設(shè)計的review。說起review大家更多想到的是大家坐在一起邊侃大山邊看別人的代碼，其實設(shè)計的review是更加重要的和更加高級的，也是更有價值的，問題發(fā)現(xiàn)的早解決的代價就小嘛。在review別人或者自己的設(shè)計時，我們都能學(xué)到別人的設(shè)計理念，方法和技巧，這能大大提高團隊成員的能力。項目中的技術(shù)牛人，項目經(jīng)理和技術(shù)骨干應(yīng)該作為設(shè)計review的主力人員，多多談?wù)勛约旱目捶?；同時也要注意尊重設(shè)計者的感情，讓大家都有收獲的同時，把項目做好。

　　2， 代碼的review。代碼review的形式可以多種多樣，兩個人坐在一起看看代碼也是一種review，也沒有必要非得所有人都湊齊。Review代碼的可以讓自己迅速成長，也能讓項目組成員熟悉別人的業(yè)務(wù)和代碼，以***程度減少人員變動造成的損失；同時也能讓代碼規(guī)范更加一致。

　　不管是設(shè)計review還是代碼review，都不一定要全部人員到場，這可能會浪費一些時間；但是設(shè)計的review最少要有一個技術(shù)骨干或者項目經(jīng)理在場，否則review就會變成討論會進而升級成戰(zhàn)爭。

　　Review有時候也會被認為浪費時間，特別是很多程序員對review別人的代碼沒有任何興趣，也不愿意讓別人對自己的代碼說三道四。我想說，作為一個二十一世紀(jì)的軟件工程師，我們不但要善于對技術(shù)進行鉆研，更要善于把自己的技術(shù)傳播出去，也要善于通過別人的指點更快的提高自己的工作能力。這是一個開放的時代，是一個需要交流的時代，是一個迅速發(fā)展的時代，你慢，就就完蛋。

　　在review發(fā)現(xiàn)了很多問題之后，我們要怎么辦呢？對，重構(gòu)。這幾年重構(gòu)這個詞已經(jīng)非常的火了，大家都說重構(gòu)很重要，但是又有幾個人真正的去重構(gòu)呢？有幾個人真正的不允許自己寫重復(fù)代碼呢？大家是不是還在說：“項目schedule太緊了，等有空了再優(yōu)化吧”？我認為，這句話是有問題的，項目的總時間短，任務(wù)重，我們沒辦法；但是優(yōu)化（重構(gòu)）卻不會增加這種時間的壓力，相反的，重構(gòu)會大大減少后續(xù)的開發(fā)和debug時間。因為重構(gòu)后，出現(xiàn)的bug更容易被定為，更容易被fix；相反垃圾代碼引起的debug和fix bug的時間將遠遠大于重構(gòu)的時間。

原文鏈接：http://www.cnblogs.com/GodSpeed/archive/2011/08/16/2140040.html

【編輯推薦】

1. 新手軟件項目經(jīng)理該如何入門
2. 項目經(jīng)理的力量應(yīng)該從哪里來？
3. 軟件項目管理總體流程設(shè)計
4. 新手軟件項目經(jīng)理之***期限的迷局
5. 向新手軟件項目經(jīng)理推薦敏捷