如何更好的Code Review
原文，向原作者表示感谢。不过不知道作者是不是在国内学过作文，让我想起了小学时老师教的作文要多引用名人名言哈哈。
几年前当我还是个菜鸟的时候，我过得十分潇洒。
写代码——交给别人review——改代码，绳命是多磨美好！工作内容就是仔细阅读我收到的评论、建议，学着成为一个更优秀的开发者。如今我成长为了一名高级开发人员，给别人做code review成为了我的职责之一，这时我意识到我的经验还不足以完成这种职责转变。
每次给别人做code review时我都感觉到害怕，感觉自己像是一个骗子，很多问题都困扰着我：
我该给这行代码提建议吗？
应该有更好的办法写这段代码，我应该告诉他吗？
他会怎么想？他的经验比我丰富。
改了这一行代码会不会使程序崩溃？
这时我的导师给了我建议。
好的code review聚焦于获得额外的产出，而非仅仅是找到bug。别把review当做是审讯，而当做是一种提高代码质量、发现其他方案、增加学习能力以及加强友谊的办法。
作为reviewer，你对代码的反馈是将渴望贡献的开发者组建成社区的一种主要方法。通过培养一个活跃的社区，你将提升产品、团队、和人生的质量。
这里有一些做好code review的建议。
设置目标以及测量指标
Scott M. Graffiu说过：
如果你不收集任何指标，你是在瞎搞。如果你收集的指标过多，则会干扰你的视野。(If you don’t collect any metrics, you’re flying blind. If you collect and focus on too many, they may be obstructing your field of view)
取得平衡的关键在于你如何收集指标，太多的指标是在浪费时间，没有指标则是在一艘没有舵的船上航行。当开始之前，你的团队应该决定如何衡量code review的效果并列举一些具体的目标。一般来说，好的代码应该：
首先是完成功能——像预期那样工作。
其次是整洁可维护——可读性很重要。
最后是优化——像在生产环境那样运行。
定义的指标应该在review前后进行测量和追踪，比如“减少客服15%的工作量”，或者“减少开发期间50%的错误率”。
记住，目标应该是你提高代码质量的测量图。“修bug”并不是一个具体的目标，不会产生任何价值。正如Albert Einstein说的:
只有测量才能带来管控。(What gets measured will only get managed.)
对事不对人
Frank A. Clark说:
批评就像是雨，应该温和的促使人成长而不是摧毁他。(Criticism, like rain, should be gentle enough to nourish a man’s growth without destroying his roots)
为啥有时候code review会跑偏变成批评大会？
这种情况往往发生于我们停止讨论这个主意的优劣而开始讨论想出这个主意的人的时候。我们总是很容易的说出:“某某，你个傻B，为啥不用并发”，但我们需要的是更优雅、中立、成熟的说：“我很好奇这段代码，如果使用并发实现会怎样？”
这2种说法区别是很明显的，第一种你是在羞辱他并且激怒他进行反击。第二种你仅仅是在说代码，没有评论或者指责，只是朴素的讨论。
记住，谦虚和礼貌的和人交流是十分有意义的，确保你们聚焦于主意的优劣而非消耗在其他无关问题上。
保持专业，别情绪化。
不懂就问
Kubra Sait说：
提问是改变的第一步。(Asking questions is the first way to begin change)
如果你对项目没有足够的熟悉，你不可能做好code review，奏是这么简单。
不管别人怎么样，你需要去观察你能想得到的任何相关的事。这要求你看的更深，问各种问题，确保你理解每一步。
你就好像一个医生，要问各种问题——患者的习惯、吃了什么东西，压力如何，吃过什么药等等，这样才能提高疗效。人体是一个十分复杂的系统，除非医生十分执着，否则他不会找到引发问题的根本原因。
code review和上面原理类似，Nigel Munoz建议reviewer思考“这个改变将导致大或小什么样的情况”。大的包括发现任何重复的代码，非模块化，或者没遵守约定俗成的一些惯例——以及分析对代码架构的修改。
不要填鸭式教育
Maimonides说过:
授人以鱼不如授人以渔。(Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime)
当你做code review时你在扮演的是一名指导者，好的指导者从来不进行填鸭式教育。
你要做的是引导他们解决问题并且激励他们。相像自己是寻宝游戏中的NPC，你给玩家指出线索，指明正确的路线，而最终由他们自己去解决问题。这样做有很多优点：
- code review成为学习和分享的机会。
- 开发人员对代码有完整的所有权而不是依赖你帮他们解决问题。（Roy注：说白了就是控制自己改别人代码的冲动。）
- 你将创造和培养下一任高级开发人员。
一旦团队采纳了这种学习态度，你很快就会发现团队的智力资本在不断上升。这也健康的使用了开发人员的自我驱动力。“自我成就感”天然的促使开发人员写出更整洁的代码，因为这给他们展示自己能力的机会。
控制时长
Garry Kasparov说过:
能努力工作几天还保持专注是一种天赋，能长久学习后还不断吸收新知识也是一种天赋。(The ability to work hard for days on end without losing focus is a talent. The ability to keep absorbing new information after many hours of study is a talent)
别把code review当做苦差事，如果你发现自己吸收知识的能力每时每刻都在下降，那么你需要停下来活动一下清空脑子。做review时不要超过60分钟，超过这个时间效率和关注细节的能力都会下降，最好是在短时间内进行review。
不要一次性review很多行代码，你不太可能会发现缺陷，保持每次review的代码在400行以内，设定一个行数限制和设置时间限制一样重要。这确保你在review时保持最佳状态。
经常做code review不仅仅能提高代码质量，还让你有时间去想每个问题的最佳解决方案去替换脑子中最先想到的方案。
最后，让code review变成一件积极的事，事实上bug在进入生产环境之前就被发现总比造成客户抱怨好得多。谁如何导致了bug并不重要，重要的是你和团队在创造更优秀产品中的作用。
培养这种积极的想法，使code review成为一种集体协作行为，这有助于团队感激(而不是害怕)code review。
正如Hellen Keller所说:
人多力量大。(Alone we can do so little; together we can do so much)
