敏捷有没有代码评审？
XP推荐结对编程：
结对完成了两个人的代码评审
新手和老手结对，可以让新手快速成长
软件设计和普通开发结对，可以提升开发人员的设计能力
实力相当和人结对，可以认知互补、设计互补、技能互补
大多数国内的团队都没有实践结对编程，但传统的代码评审费时费力，到底做，还是不做？
答案是，要回归初心，看代码评审到底要解决什么问题
代码评审要分类进行
我们先达成一些共识：
每一行新增代码都要进行代码评审吗？答案：不
新员工和老员工的代码要用相同的方式评审吗？答案：不
所以，我们要先对代码进行分类，看哪些代码需要做代码评审，哪些不需要
代码分类
我们可以将代码分为四类
A、语言不熟的BUG，应聘生会犯的错
B、平台代码不熟的BUG，应聘生+社招会犯的错
C、静态代码扫描工具发现的BUG，应聘生+社招+老鸟会犯的错
D、业务逻辑导致的BUG
A是语言不熟（或Java SDK不熟），比如我带的一个应聘生写过这样的逻辑：明明只有一个值，却放到集合里，用的时候又循环访问第1个元素。这种代码语法没问题（语法问题编译器会提示），纯粹就是语言的问题，说不好听点儿，就是脱裤子放P代码。校招生或代码量不足的人会出现这种问题
B是平台代码不熟（或第三方SDK不熟），我们常常会写一些胶水代码（将业务逻辑和第三方库融合的代码）。胶水代码不熟会用错API导致代码低效或存在隐晦的错误
C是基于规则对代码扫描，从而提升代码的规范度
D不在代码评审之列，关于业务逻辑正确性，应该通过设计评审来保证
分场景进行代码评审
如果团队进行了校招，应聘生入职就要针对A和B进行代码评审
如果团队进行了社招，社招入职就要针对B进行代码评审
C不用进行代码评审，有问题的代码会被工具检查出来
代码评审的形式
方案一：会议室代码评审
这种代码评审的方式是，开发人员坐在一个会议室，轮流进行代码评审。即，同一时刻，多人评审某个人的代码。
如果是在评审老员工的代码，新员工一般没有发言的机会。并且我遇到过，老员工之间对代码互相不服，因为代码风格的问题讨论一个小时未果的情况。
评审类型：A+B
耗费：5颗星
效果：4颗星
结论：这种方法不敏捷，应该淘汰
方案二：导师责任制
我目前的要求，每位新员工指定一名导师，新员工三个月内不能提交代码到SVN，要由导师提交。即，工作是新员工做的，但质量由导师负责。强制导师在提交代码时即时进行代码评审。
导师对新员工的工作任务比较清楚，所以这种代码评审，与结对编程效果差不多。
评审类型：A+B
耗费：1颗星
效果：3颗星
结论：可以评审出一些问题，加强了导致与新员工的互动，可以推广
方案三：基于CheckList评审
团队指定一位代码专家的角色（请参考我关于代码专家的文章），将A+B+C中，遇到的问题收集到CheckList中，定期分享CheckList，让大家了解以前犯过哪些错，避免以后再犯。
更进一步，将CheckList中常犯问题，直接写成静态代码扫描工具的规则，由工具强制约束大家不再犯错
能做到无二过的人就是伟人，能做到无二过的团队就是伟大的团队！
评审类型：A+B+C
耗费：前期3颗星，中后期1颗星
效果：5颗星
结论：随着团队成员的变化，将这项工作持续下去，效果和力量是无穷的，可以推广
方案四：最牛B的方案
请往下看，最后告诉大家
回归代码评审的本质
回归初心，代码评审到底要解决什么问题？
不要用领导视角，站在团队外部去看“如何帮助团队成长”！而要站在个人视角，从每一位开发人员自身出发，如何自我成长、自我提高：“做为一名工程技术人员，我有责任提升自己的技术能力、提升现有代码的质量；做为团队的一员，我有责任让团队不再犯我犯过的错误！”
如果每个人都对自己有要求，做为团队负责人，是不是可以做些什么，帮助个人更好地达成目标？组织大家做些什么呢？或者说：如何组织代码评审呢？……明白思考路径了吗？
代码评审除了促进个人成长外，还可以：加速提升团队成员对平台代码的熟悉程度，统一团队的编码风格！
如果这两点也能做到，就更好了！
我的故事
我要讲的是，我刚加入金蝶时，自己是如何快速提升平台代码熟悉度的。
求人不如求己，争取第一次就做对！
我被社招进金蝶，在金蝶EAS-BOS平台负责一款新产品的研发。BOS平台是自主研发，所有API都是金蝶自己的。我做的每一个功能，都会让需求人员给我找三个老产品上的相似功能作为参考。功能相似但实现方式相同，我就认为该实现方案是比较靠谱的；如果功能相似但实现方案不同，我就会按自己的判断，选择一个比较靠谱的实现，并且在代码中用TODO标识出？，以及说明其他方案。
我刚进金蝶那会儿，金蝶在做CMMI4，也有项目管理部，项目管理部要求每周做代码评审（这个要求不算扯淡，但有很多事情比较扯淡，最终这个项目管理部被解散了），并且要求项目管理软件支持录入评审缺陷并跟踪（CMMI4嘛）。
我很喜欢这个过程，有一群老员工围着我，我把我标识出的每一个？拿出来，和大家讨论哪种实现方案好，哪种实现方案不好。这样做，评审我代码的同时，顺便把相似功能的老代码也一起过了一遍。最重要的是，在这个过程中，我知道哪种解决方案是最佳的！
有时候，大家对某个功能讨论不出最佳解决方案，这会让我更加开心，因为，超越这些人的时候到了。我会拿着这个功能，找BOS的同事，十在不行就找首架去讨论解决方案。当我了解到最佳的解决方案时，我知道，这是那些老员工们不知道的！所以，分享干货的时间就到了！
你认真对待你的工作，你就会有更大的收获！
方案四：有目的地进行代码评审
从我的故事出发，最牛B的代码评审，应该是在写代码的同时，有拿不准的代码，我们就在代码上做TODO标识，并在代码评审时，有目的地进行代码评审。有疑问则进行代码评审，没有疑问则不进行代码评审。
所以，新员工较多时，代码评审会频繁些；较少时，代码评审可以少很多。
该方案应该结合方案二：导师责任制一同进行，低级问题可以由导师解决，中级问题在代码评审时解决，高级问题找专家解决。
评审类型：A+B
耗费：前期5颗星
效果：3颗星
结论：形式上仍是在会议室进行代码评审，但实际效率和效果上，会与会议室代码评审有本质的不同！既高效地解答了新员工的困扰，又统一了团队对解决方案共识，还能加速提升其他新员工对代码的理解，也能一定程度地统一编码风格。真是一举四得！
写在最后
不过，代码评审不能代替代码规范，阿里的代码规范在很大程度上也是降低代码评审频率的情况下，让更多的开发通过规范达成共识。