21CTO导读：代码审查是每个高品质软件开发团队的强制性实践，我们希望在本文中没有关于审查的反对声音。
有的团队会预先合并代码审查，以保护他们的master/dev分支免受意外错误的影响。也有一些人会大合并后定期审查，以免在合并后发现Bug或不一致。
有些团队则两种方式都做。
代码审查与白盒测试技术非常类似，其中测试人员通过完全查看源代码来寻找缺陷。在任何一种情况下，代码审查都会有效提高软件质量，是提高团队积极性的重要工具。
但是，要做到这一点并非易事。要做代码审查这件事也难也能很舒服，我见过很多代码测试者和他们犯过的错误。
下面是我们总结的一个优秀测试工程师(代码审核员)的四项基本原则，希望对大家有帮助。
金统帅都在做代码审查，你害想咋滴？
不要怕
严格的代码审核者应该抛弃一些不必要的担忧，比如一个首要原因就是怕得罪代码的作者。“我最好闭上眼睛，假装今天没有他的bug，明天他会忽视我提的问题”，这就是恐惧产生的态度。这样的情况，虽然和代码作者友好相处了，但起的作用会适得其反，那就是严重降低代码质量和团队士气。
我们的建议是：直接，诚实，直截了当。
如果你对同事一直有这种感觉和方法，那么可以管理方式出了问题。你害怕被团队拒绝“不是团队一成员”，这是团队中最弱的成员的说辞，而不是项目领导所应该有的标签。甲方付费给团队开发高质量的软件，他们并不关心你想提高软件质量的想法会得罪他人，谁也不会在意。他们希望他的钱能够交付出可售卖或可运营的产品，他们也不会付钱给你在办公室里交朋友。
下一个类似的恐惧，听起来是这样式的：“如果我不让这个代码审核过去，会推迟项目的上线”。这样的思虑不言而喻，对整个项目都有很多的不利影响。你接受这些代码睁一只眼闭一只眼假装看到合格的code。团队里再没人会再说你是产品上线的瓶颈，不会因推迟发布而损失金钱。如果你想成为一个优秀的代码审查者和团队合作者，这样做对吗？答案肯定是错误的。
我们之前提到过，一个专业的团队非常了解他或她在项目中的个人角色，但不包括为任何人擦屁股。如果因拒绝不良代码而延迟发布，那就是作者的错误。代码审查者的责任就是让此故障可见。
这是你帮助团队学习和提高的方法。
我认为提高非常明显，要让团队学习与改进，首先先摆脱糟糕的程序员，推出优秀的程序员。诚实无畏的代码审核员可以帮助团队向更好方向发展。
第三个恐惧：“我可能错了，他们会笑话我”。更难堪的是，他们可能会发现我缺乏专业知识，会发现我不知道自己在做什么。安静地并假装代码中没错反正更安全，至少我不会用愚蠢的点评来掩饰尴尬。如果你闭嘴，看起来更聪明对吗？错误！
这个项目并没有你看起来好就很好，你拿到的薪水并不是因为团队喜欢你，而是因为你每天都会产生可交付的成果。您的职业责任是项目做有利的事情，忽视每个人的意见，包括老板的意见。我想说的是，尊重团队是一个错误的目标，不要试图获得尊重，创建干净的代码并尊重技术。
我再重复一下：不要害怕通过对某人的代码做出“错误或愚蠢”的评论而感到难堪。忠诚于项目，而不是周围人的期望。人们可能希望你能聪明，但是项目希望你能说出对代码的真实看法。所以不必担心人们的意见，去做正确的事，说出你的真实想法。
不妥协
现在，我们可以无畏的说出你对代码的看法，并拒绝审核通过。你正正审查的分支变得不顺利，你解释了原因，并要求代码作者重构或者重写。
下一步会出现什么情况？
他/她会尝试和你达成协议。这一切很自然，我的团队中看到几乎每一个分支都在发生这种情况。代码的作者也是专业开发人员，他似乎毫不畏惧，坚持他自己的实施方法是正确的，而你的想法是错误的。
在这种情况下，专业代码审查员应该怎么做？
在最坏的情况下，是双方妥协，这是破坏质量比烂代码快愉快的东西。妥协是一种冲突解决方案，双方一致同意不是为解决冲突而得到他们各自想要的东西。换句话说，就是“让和平只是为了停止战斗”，坦白说，这是一个有些糟糕的做法。
我们不做这种解决方案，有一个关于代码的“斗争”有三个专业的解决方案：
1）“你是对的，我接受此建议”
这种情况有可能会发生，而且应该经常发生，你应该准备好承认自己的错误。虽然你不喜欢那些代码，但是它的作者向你解释了它的好处，原因，一定不是你想停止与他战斗，而是你真正的理解了他的逻辑并接受它。愿意说“我错了”，这是一个成熟而认真的开发者的第一个表现。
2）“现在，我决不接受这段代码！”
有些代码值得你这样做，以这种直接的方式没有任何问题。对方可以接受这种情况并全部重写，去学习新的技术。
3）“我们来听架构师怎么说的！”
在每个项目中，都有一位软件架构师做出终极决定。你只需听取他的意见，得到他的最终决定。在事情发生后，邀请他参加讨论，请他站在冲突的某一边，如果他告诉你错了，全然接受这个决定并在此中吸取教训即可。
所以，要么坚持自己的立场并为之而奋斗，要么承认自己是错的，此种方式或另一种方式。但就是不要妥协！
别误会我的意思，不管多么糟糕，都不要固执已见。需要我们在现场保持灵活性。您的立场可能会在谈判期间发生变化，但不要接受自己不喜欢的立场。
你可以通过完全确信对方是正确的，或者当架构师出现时的判断时退出冲突。
不说废话
再一次，我们无畏地说出真实的话语。一种方法也可以有不同的方式设计，比如说对方，代码的作者，他回答他不是这么认为。我们再看，决定站在你位置，你仍然认为自己是对的，不会做出妥协。怎么处理？马上打电话给架构师还为时过早，所以你要尽量说服你的对手。
在大多数情况下，让人心服口服是的教学——你懂得他从不懂得的事情，这也是他以你不喜欢的方式编码的原因。团队的某个人需要额外的教育，这是你成为同事老师的最好机会。
要成为一名有效的老师，你需要出示证明，根据自己的逻辑来确保他能够理解并完全接受它。
方法是，准备好足够的页面链接，文章，书籍，报表，示例等材料。不要只是说：“我已经写了15年的Java了”这类话是不够的，这种论证也不会让自己有足够的说服力。
如果你没有足够令人信服的证据，那请你再好好想一想，也许是自己错了。
另外，请牢记，代码审查员的角色是审核错误的代码的，代码的作者不应该用什么来证明，他写的代码默认很棒。审查员的工作是解释说明为什么以及为何实际情况并非如此。换句话说，你是原告，他是辩护人。
没有冒犯之意
这是我们说的最后一个也是最难遵循的原则。无论代码多么烂，你的对手有多顽固，你必须保持专业性。在现实生活中，说实话，这种情况确实很难。在我现在的团队，每周都在远程团队中都有新人加入，尽管我们有较严格的选人标准，但是总会有一些人有些愚蠢而且比较难对付。
一年前，我遇到一个有意思的事，当时一位新人在现有的Java代码库创建了一个非常小功能，大概20-30行代码就能完成，但是他却输入了几百行，接着他发起pull请求。我是代码审核员，发现那段代码绝对是垃圾，很明显不是他自己写的。我立即看到复制下来去找他。我该怎么处理？我为什么拒绝它，而不是指责它，对于专业的软件开发者这是不可接受的。我接下来还花了大量时间来用客观事实，指出他的代码风格、设计等。我必须严肃指出一些错误的问题，并告诉他要彻底解决掉，他应该立即删除垃圾，代码从头开始写。在完成这个任务后，我再也没有见过这位仁兄。
我的观点是，当你与任何专业人士打交道时，也要保持自己的专业性。虽然在某些时刻，情况不总是这样理想，但是无论摆在你面前的代码有多糟糕，我们都要足够的耐心和说服力。你认为呢？
编译：洛逸
作者：Yegor Bugayenko
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/257729.html