在我作为工程师在最初期，一直都是一些更有经验的老师傅 Review 我的代码，提出他们的意见，那时候，我对此也没有自己是否也应该 Review 他人的代码的想法，一方面不了解 Code Review 是一件不比亲自开发更容易的事情，另一方面那时的我忙于 “吸收” ，也无暇顾及。
但是随着时间的增长，我意识到了我对 Code Review 这方面的欠缺，当我不得不开始 Review 同事的代码时，我发现我遇到的最大的问题 是我没有任何想法，或是说即便有想法也会被我自洽的解释所忽略。这让我感觉很奇怪，因为我写自己的代码总是了然于胸，并且往往会在许多地方纠结不已，我不免怀疑我是否这段时间都毫无提升？
为了解决这个问题，我开始在 Review 别人代码的时候只关注需求，按照自己的理解在 Draft 或者大脑中实现一遍 “是我的话，会怎么做”， 然后回头带着自己的 Style 和遇到的问题再正式开始 Review，这个方法很有效，只有一个缺点，就是耗费我个人的成本十分巨大，而如何 解决这个问题就变成了我必须处理的事情。
What's the point
按照我的观察，通常每个人的 Review 侧重都是会有区别的。与我个人而言，我认为优秀的代码的特性应该是 “可读性” 大于 “必要性能”。 因此我会优先 Review 代码的 “可读性”。
可读性其实是一个宽大的概念，其中不止包括了
-
Function 和 Module 的 “有意义的” 命名
-
Function 和 Module 合理的结构
-
在必要的地方是否有合适的注释
-
PR 整体的流程是否符合常规逻辑和直觉
My Solution
-
结合需求和 Diff 最快速的了解这个 Pull Request 的流程而不去管细节实现。
-
思考流程上是否存在问题，如果没有则按照流程 Review 具体实现。
-
先看 Module / Function 的名字，在心中有一个自己的判断，再去对照具体实现和刚才的判断作对比。
-
考虑性能和检查测试的覆盖。
以上几步中其实都有和 Author 思路作对比的过程，因此最重要的一点是，任何我无法理解的地方，我都 会留下 comment ，而不是强行带入 Author ，自己给出自洽的解释，亦或是过分用力的理解这部分的代码。
因为只要你产生了短时间无法理解的疑问，那么这里的代码就一定存在问题，即便这个 Scope 已经没有任何优化的余地了， 你也应该勇敢的提出来，这会让 Author 和其他 Reviewer 注意到并重新考虑，无论结果如何，都是起到了帮助。所以不要忽视 任何的疑问！