为什么要 Code Review

软体工程师开发一个功能后，常常会再被其它工程师数落，不管是能力多强的工程师写的程式，还是会被后面接手的人骂，其中很大的原因就是不同的想法，与各人知识能力不同，我们如何靠 Code Review 来解决这种问题呢。

Code Review 就是请其它工程师大家一起评论自已写的程式，把程式码公开让别人来检查 / 优化 / 补强，评论的内容会因各人专长与想法的不同，而产生很多争议，例如安全性专家会龟毛的要求修补任何有可能的小小漏洞，效能专家会尽可能的想提升程式 Performance。

透过 Code Review 可以让不同专长的工程师，一起评论一段程式码，并提出自已的看法，每个人可以从中学习到各种不同知识，渐渐的拉近每个人的能力与想法，一开始实作 Code Review 会花大量的时间，每个人都会用自已喜欢角度来看程式，当两个人的意见有冲突的时候，就会出现笔战，试图挑战对方的底线，但只要持之以恒，团队成员的默契将越来越好，最后就能把每个人的能力与想法一起提高拉平，

Code Review 最怕是那种不下任何评论，但是心中满满抱怨不配合的人，这种人无法接受其它人的意见，又不愿意跟别人沟通，每次写程式都用自已的习惯，面对别人的评论总是讲一点就修一点，没完没了，不思进步，如果团队内有这种人会严重影响 Code Review 的进行。

良好的 Code Review

要做到良好的 Code Review 并不是这么简单的，大部分的人都是心胸狭窄、度量小，尤其是男性生物，本能就是要竞争，打败身边的所有人，要让工程师接受别人的评论，承认自已写的程式不好是很难的一件事，所以 Code Review 的时候，不要让对方感受到他的程式不好。

• 看到程式有不正确的地方时，不要直接说对方写错了，改用间接 / 询问的方式来提醒比较不伤人，例如 Code Review c 语言，发现对方忘了 initialize memory，不要直接写 "你忘了 initialize memory."，而改用 "我找不到这个变数在哪里 initialize memory? "。
• 不要强迫作者一定要修完所有的 Comment 才 Merge 程式，有些不影响系统的 Comment 可以下一次 PR 再一起修即可，这样也能够加快 Code Review 的过程。
• 给评论时不要攻击对方。
• 公司内可以订定程式准则，减少 Review 的争议。
• 下评论时内容要清楚，明确，不要顺便打几个字，这样会给人不尊重的感觉，而且会造成对方误解你的意思，拉长 Review 过程。
• 因材施教，资深的工程师写 Comment 时，内容必须是对方能力所能了解的，或是提供线上文件当参考，顺便让新人有自我学习的机会。
• 开一个新的 Pull Request 时，要尽可能的把为什么要改这段程式的原因与方法，写在 comments ，让 Review 者可以更快速的了解程式，以及了解你的想法，就算是很基本的知识，建议也要写出来，除非你很确定 Review 者很强，自已看得懂。
• 重覆的问题只要写一次就好了，下评论的时候再注明请对方一并修改所有类似的问题，评论数太多会让其它 Review 者觉得程式的问题很多，观感不好，也会对作者心理有不好的影响。
• 资深工程师要能虚心接受资浅工程师写的评论，用专业的态度来看评论。
• 当 Review 出现两种意见，各有利弊的时候，应使用客观的角度，用理论与数据来决定采用哪个方案，拿不出数据时，我个人建议采用曾经发生过的案例。