Code Review的那些事

为什么你做不好CodeReview

在微信上看到池建强的文章，想到对自己参与过的code Review，做个小小的回顾。

其中一个项目的管理工具是RTC, IBM Rational Team Concert。RTC为软件交付和团队协作开发提供了“集成工作项目”、“源代码控制和构建管理”等支持。RTC可以独立运行，也可以作为Eclipse的插件运行。除了内置的管理模式，还可以自定义一些规则，甚至可以用java代码扩展。

在RTC中，可以定义自己团队的代码提交规则。比如说可以定义有人Review，有人Approve，之后才能提交代码。Review这个一般是Peer Review，对于紧急而关键的变更，也可以找资深的架构师做Review。而Approver，可能是资深的架构师，也可能是项目管理人员。有人Review、有人Approve，这个ChangeSet就可以提交到主线了。

对于团队新成员，Code Review是个很好的学习机会。可以跟着特定的Story、Task或者Defect，看问题是怎么被解决的，都考虑了哪些方面，从中学习代码的架构和解决问题的办法。

对于团队资深成员，Code Review是个相互备份工作任务的机会，也是很好的教人的机会。有人为你备份工作，团队在有人请假或者离职的时候，才不用害怕影响工作进度。而在Review 新人的代码的时候，也可以从代码的逻辑、风格、解决问题的全面性等各方面，有的放矢地给与新人直接的指导。

另外一个项目的管理工具是Github。在我们开始使用的时候，PR这个概念已经很成熟了。不过从这个项目开始，可以Review和Approve代码的人变少了，每个Squad team只有一个核心成员，通常是资深架构师或者主程，可以Review code，并将之merge。这种管理模式在一定程度上保证了主线代码的质量，但是这同时也会成为瓶颈。整个团队都担心核心成员不在，而无法merge code，耽误项目进度。好处是每个代码接受Review的团队成员，都在一次一次的Review中，跟资深的核心成员学习到了更多。

池建强文章中的所说的制度问题，倒不是我们在工作中需要考虑的。团队从一开始建立就有一套相对完善的流程。不过制度的影响确实很大，团队的Code Review不成问题，写注释却是问题。因为注释，笔者自己就坑过自己。写好的代码，过了一段时间，需要再次用到的时候，因为注释不完整，差不多花了跟第一次一样的时间，重新读懂了自己的代码。这件事情给笔者留下了时刻的印象，对其耿耿于怀。