如何开始对项目进行管理（三）

（五） 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的时间将远远大于重构的时间。