class="topic_img" alt=""/>
英文原文：How to Use a Code Review to Execute Someone’s Soul
代码审查，本身应该是一个相互合作，相互学习，整合团体动力，最终却以消极和敌意为代价向前发展。这种现象是如何造成的，我们又该如何克服呢？原文作者 Erik Dietrich 给出了一些见解。译文如下：
前不久，我收到一封有关讨论代码审查的邮件，对方对其抱着无所谓的态度，我想这可能是大部分人持有的态度，这也一直是大多数的代码审查的面临的尴尬状况，但不是全部。与其冒着把孩子与洗澡水一起倒掉的风险，那不如干脆不要把洗澡水弄脏。我的意思是，完全杜绝糟糕的代码审查。
鸡蛋里挑骨头和无意义的讨论
我想我们大多数人都同意，没有什么比花一两个小时的争论是否要使用隐式类型，或是抛出 ArgumentNullException 还是 NullReferenceException 异常更无聊了。为什么让你的代码审查变成那样呢？你可以不用担忧大局，仅仅进行哲学讨论，如代码的可读性和易维护性。那些曾将代码审查作为学习和合作机会的人，很快就会意识到，他们只会关注产生意见分歧的地方。
居高临下和嘲讽
在正常的代码审查中，一般会产生逻辑错误，但千万不用止步于此。如果错误可以驱动开发，那么你可以添加一句“是个人都不会忘记这点”的评论会让他们更加印象深刻。代码审查是项单向活动，不用担心他们回过头来找你算账。
让审查没完没了
一点点代码审查算是“还不错”，那 10 小时的马拉松会就值得考验了。请确保您审查每一行代码、每一个配置文件的改变、每一个标记标签及每个自动重构。
保证所有审查必须“通过”
当你将情景设置为“教授和学生”，你不妨继续制定“审查必须通过”的政策。这样一来，它就不是一个专业团队检讨彼此的工作，你可以提出批评、建议和见解，而是一个被吓坏了的初级开发人员试图找出这次发布的版本中做的不够好的地方。为什么把每个开发/循环/发布搞得像参加 SAT 考试一样隆重呢？
以事实定位你的意见
也许你会认为静态方法比实例方法更好，这是一个事实。想想你带有个人偏好的设计模式，编码方法，风格等，然后去掉类似“我认为”，“我喜欢”，或者“在我看来”等修饰语，将“我喜欢用下划线命名字段名”变成“你应该用下划线命名你的字段名”；“我觉得你的参数很混乱”变成“我们的参数很混乱”。不管你做什么，不需要有任何证据或引用说明。当你告诉别人，他们的代码太长了，他们会问：“哪里太长了？你只要回答“我是高级程序员，而你的代码比我长。”
逃避所有可以很容易地自动检查出的错误
为什么要花费一天时间坐在一个狭小的会议室，寻找是否有人犯了采用 Camelcase 命名而不是 Pascalcase 命名方法的大罪呢？你可以一行一行地数方法的代码行数，甚至通过手工计算循环的复杂度。当然，有很多工具可以在几秒钟内可以做任何你想做的事情，但这样就失去了公开指责初级开发人员错误的机会了。
保持消极
一点点积极的鼓励都会激励整个项目的进度，代码审查其实有很多这样的机会，因为你可以看到很多新的做事方法。正因为如此，所以你必须要小心，至始至终保持消极。使用白板或电子表格列出别人的错误，并且多多益善。
结语
我相信，良好的代码审查需要一致协作。如果发现了错误，你不需要直接告诉别人他们错了，换成“你觉得，如果我传递 null 给这个方法会怎么样呢？”就足够了，别人可能会说“哦，这个我没考虑到，我马上解决它。”让他们自己意识到错误并提出改进的方法会更好。
代码审查不是考试，也不是为了证明代码的价值，而是提出更好的解决方案的机会。通过结对编程来减少代码审查中的摩擦。这样一来，更多的人一起来捍卫自己的工作而不是一个团队来挑某个人的刺。
研究表明，减少 Bug 最有效的方法不是过于苛刻，不是使用静态分析工具，甚至不是单元测试，而是结对检验。找一种工具来折腾是个不错的选择，只要像待人一样对待它就行了。
相关文章
