回到目录

Code Review是协作编程当中非常重要的一环。任何一个程序员在公司里工作，都不可能随意的修改代码，任何的改动必须产生一条称为Change List的记录，其中包含了这次修改的所有内容。然后此条ChangeList的作者把该记录发给同事，同事提出修改意见，作者再根据修改意见修改，直到最后大家都认为没有问题了，才把这条记录合并到代码库里。这个过程顺利的话很快，但慢到能慢到令人发指的地步。

系统有个新功能要做，我答应经理帮助另一位同事完成这个工作。我写的代码会发Code Review给经理和那位同事，经理经验比较丰富，很积极的帮我Review代码。那位同事从没有给我的代码提过任何意见，大概是他忙着写自己的代码，没有时间吧。

突然有一天我收到了一个那位同事发来的Code Review请求。我第一时间就点开邮件，开始review他的代码。之前我比较少review别人代码，因为是新人，通常都是发给别人review，我自己也把code review作为一个学习的过程，同事提出的每个意见我都会作出修改，也确实从中学习到了很多的技巧和技术。我从各种角度来review同事的代码，发现之前别人提给过我的意见也都适用于他的代码，于是我提出了很多的修改意见。

几分钟之后，就收到了同事的反馈。我心想同事工作效率好高，这么短时间内就处理完了我的所有意见。点开回复，发现同事在我的每个意见后面都回复了一两句话，意思大概都是这些修改建议不影响功能，因此不需要修改。我当时心里就发火了，难道不是reviewer的建议如果合理就应该尽量尊重吗？一条都不修改什么意思？其中有些coding style的误差也不修改吗？我为这位同事的傲慢和对工作的不负责任的态度深深感到厌恶。他比我进组早几个月，然而在公司的资历比我深很多，而且给我的感觉就是无论我提什么意见，他也不会做出任何修改。于是我回复到，我就这些意见，如果经理觉得可以就通过吧。同事居然回复多谢，不知他是真觉得感谢我的帮助，还是为我那他没有办法而得意洋洋。

经理劈头盖脸的提出了很多修改的意见，同事几乎跟回复我的建议采取了同样的策略 - 表示理解但坚决不改。与我的做法不同的是，经理并没有继续Code Review。我猜他们单独聊了一次，因为几天后那位同事像换了一个人一样，把经理所有提出的问题都解决了一遍。经理继续提出修改意见，同事一改之前的态度，回复当中还不时夸赞经理的技术深厚以及洞察问题目光锐利。一周后，代码终于合并进了代码库。直到这个小功能完成，同事也没有再给我发过Code Review，我发给那位同事的Code Review他自始至终也没有回复过。我们各自写自己的部分，经理分别帮我与那位同事Review各自的代码。

这件事情让我心里很不爽，我的同事貌似自始至终也没有得到好处，而我们的经理却不得不加班帮我们review代码，肯定更是不爽。我现在依然认为，即使当时我与那位同事据理力争，最后也不见得落的更好的局面。让经理知道同事的消极工作态度是必要的，然而我应该做的更加艺术些。我慢慢意识到在团队中工作的难度，时而都会遇到让人厌恶的人和事，怎样把握做事的分寸，使得事情朝有利于自己的方向发展，的确是一门学问。而我想要成就自己的目标，必须要成为这项学问中的顶尖。