对代码评审的感想(回忆篇)
回想之前钱老板开代码评审流程的讨论会，有事没去，有些遗憾，所以谈下这个当前最fashion的话题，分享下之前对代码等评审的体验。
之前在CFT的研发氛围还是比较重视代码评审的，完成度也比较好，原因有以下几个：
- 业务特性。我们是的业务跟钱打交道的，所以一发生问题，损失的都是钱，所以追责很严，惩罚很重，而且罚钱一般都罚老大，所以质量上的规范容易从上往下推动，事半功倍。当然线上出现问题，往往会让QA(质量管理)追着问原因以及要求拿出改进措施，作为小兵也很烦很害怕有木有~
- 严格的流程。所有需求都是走需求系统，通过workflow电子流一步一步走下去，测试经理、测试、开发leader、运维leader有一个审批不过，就走不到上线发布。其中测试要求开发提供代码评审结果，测试经理要求用例的评审，研发leader要求提供风险报告，并判断是否要开安全评审，这三个评审都或多或少和代码评审有关，这里顺便都讲下。
(1) 开发在提交代码之前需要进行代码评审，也有少数推到提测后再进行，这对测试来说很烦躁，因为测了一半了你跟我说要更新评审后的改动，早干嘛去了？
评审形式基本上都是线下订个会议室讲个半天，很少在线评审，由组长级带头，相关项目的开发人员对自己的代码还有逻辑进行讲解，然后总结改动点输出会议纪要。
评审主要评审实现方法上的问题为主，很少涉及编码规范和代码结构方面的问题（一般不是新人的话这方面大家都会遵守），重点关注但不限于超时、锁、系统调用、异常处理、数据字典设计等方面的问题。
测试会不会去参加代码评审呢？一般会邀请测试参加，但效果并不是很好，究其原因主要有三:
- 没有留太多的提前介入时间给测试。以前的系统是大系统下面多个子系统这样子的，某个子系统的特性提测了，那么谁空闲了就谁去测，推崇的是测试人员的业务全精通，像我大部分时间测后台服务，有时候也被拉去测客户端，或者支援其他项目，所以测试被邀请参加评审的时候手头基本都是忙着其他项目，没有预留提前介入的时间，所以往往会一头雾水。
- 测试的代码能力层次不齐。以前部门是很重视代码的，在提交测试报告的时候还要用工具输出代码对比，意思便是：测试人员要知道开发改了什么，有什么影响，测试人员对代码的检视水平就慢慢上去了，有次漏测，组长还拉着我一起看代码，问我为什么没有看出来。但也有一些同事代码能力比较弱的，去参加代码评审就比较吃力。当然代码能力并不决定测试水平，这个不能勉强。
- 有时候只有测试过才对流程和系统有着更深的思考。有时候测着测着发现有地方不合理或者动摇了之前的设计，总是感叹在测试之前发现就好了，但是在测试前并没有这么深刻的实践和思考，所以在测试用例评审的时候才对于开发的实现逻辑有一些挑战
(2)用例评审也是线下通过评审会的方式，主要在测试了一轮以后召开(这个时间点我觉得是蛮好的，测试对系统有了较深的认识)。邀请项目的开发，项目的测试人员，其他资深测试人员参与。主要由项目的测试人员讲解系统实现和对应的测试用例
评审的范围比一般的开发评审用例更为宽泛，对于系统设计或者代码实现上有问题，可以提；如果开发逻辑有问题或者测试用例设计有问题，也会马上拉出代码一起确认，比如一个入参测试的用例为一个fee参数的长度超过32位报错，遭到挑战：为什么是32位，通过开发和代码确认是因为fee字段的值类型用了int，评估后认为int太短，必须用long，于是开发和测试都要进行修正，而由开发评审用例一般看到这个的确符合了代码逻辑往往就放过了。所以一般的评审结果里，测试的用例和开发的代码都会有需要优化的地方。
(3)安全评审。项目需要出具风险报告；高风险的项目需要找安全接口人进行评审（组长或副总监级），讲下涉及的风险点，解决的思路和实现的代码。经常因为需要解决老大新提出的安全风险而延迟上线有木有，说多了都是泪。
风险报告的某一部分，比如这样的
个人感觉代码评审的好处有如下几点：
- 对于开发来说。很多项目将模块分给多人，然后大家分别开发或者是用先有代码再有文档这样的开发模式开发，模块之间的交互可能是支离破碎的，模块代码的风格不一、质量参差。通过评审，让开发对互相的模块有一定了解，同时针对自己不足的代码先优化下，提高代码质量。另外有新人的项目团队，通过资深人士的review，也可以帮助新人更快融入项目，提高水平。
- 对于测试来说。参与代码评审可以了解系统特性，需要关注的功能点，有时会请教开发这个地方如何测试或者要求开发给个工具或者加个开关，有助于测试用例的设计和后续的测试，当然最重要的：不要让垃圾代码浪费我时间。当然线下的评审可以讨论，不懂还可以提问，比线上的评审有意思~~
当然缺点就是耗时~~如果开展了代码评审但又不认真去做，那就是白白耗时。所以在CFT，大家开评审会还是蛮认真的，然而我不知道大家是真认识到了代码评审的好处还是被流程束缚着。直到后来，之前在CFT的几个开发组也一起去了WXG, 由于新部门没有强制的代码review流程，结果大家开始不做代码评审了。。。这说明用流程强制容易，但让质量意识深入人心，难啊~~所以，我一直想在项目中引入代码评审，然而这不是用不用gerrit的问题，而是该如何让开发心甘情愿的接受代码评审，用什么样的方式去实现它并产生应有的效果的难题。
PS:
今天开发看了下另一个开发的代码:说怎么写得那么烂，如果QA推动代码评审，我全力支持。
——感觉这世界还是有救的