<p><img src="https://simg.open-open.com/show/e1f10a6fff262804490e737332a15151.jpg"></p>    <p>Code review，中文译为「代码审查」，是指对代码进行系统性的审查，通常是和其他开发者来共同进行。这里作者就讲了在 Asana 中他们是怎么来做代码审查的。</p>    <h2>1.先确定 code review 的目标优先级</h2>    <p>在 code review 之前先和你的团队成员明确 code review 中事项的优先级。</p>    <p>作者认为 code review 应该做的事：</p>    <ul>     <li>熟悉同事在编程时的思考方式，这样其余同事以后如果有需要就可以更轻松、快速的更改代码。</li>     <li>向同事介绍修改了哪些文件，增加了什么样的功能，这样在问题出现时，可以保证至少有两个人可以帮助诊断、解决问题。</li>    </ul>    <p>不建议在 code review 中做的事：</p>    <ul>     <li>找 bug。自动化测试、运行程序要比几个人坐着看代码有效率多了。</li>     <li>检查代码规范。现在的 IDE 和编辑器都有自动规范代码的工具，为什么还要在这方面浪费人力呢？</li>    </ul>    <h2>2.把程序跑起来</h2>    <p>读其实是一种很不自然的和代码交互的方式。仅仅靠读代码来找 bug 效率实在不能算高，要知道计算机能比你的大脑更好地运行代码。</p>    <p>把程序运行起来，亲自试一试，或许你会有一些和他们测试时不同的操作，发现一些他们遗漏的问题。</p>    <p>并且现在的 IDE 中断点调试，都能够很详细的显示运行时的程序数据，这能帮助你更容易的理解这段代码是如何运行的。</p>    <h2>3.明确方法的调用层次</h2>    <p>作者发现很多人谈起 code review 的第一印象就是一堆人坐在一个电脑面前一行一行的看代码。但这么做其实效率是很低的，除非你的经验非常丰富，否则真的不建议就靠一双眼睛和你的大脑来做 code review。用工具明确方法的调用层次，能帮助你更有效的梳理代码逻辑。</p>    <h2>4.尽可能及时的进行 code review</h2>    <p>当你收到别人的 code review 邀请时，尽量第一时间就开始。因为这时作者的记忆是最清晰的，并且通常会对你的及时反馈心怀感激，这种正面情绪对于 code review 是非常有帮助的。</p>    <p>如果你觉得自己在面对 code review 时有困难的话，作者在这里推荐了两个方法：</p>    <ul>     <li>事先设置一个时限，比如半小时。也就是在你的第一次 review 中，先花半个小时理解变动的代码，写下自己的问题。如果在这个时间范围内，你不能确定代码变动是否没有问题，把你的想法和问题先发给作者，之后再确定一个时间进一步的 review。</li>     <li>在你的机器上保留两个独立的仓库。一个用于你自己的修改，另一个用于 review。这样你和作者之间的修改就能够保持彼此独立。</li>    </ul>    <h2>5.在你读代码之前，先想想自己会怎么做</h2>    <p>先读一下功能说明，思考下如果是自己来可能会怎么做，之后再查看作者实际做出的修改。如果有和你想得不一样的地方，就可以和作者进行交流，讨论清楚为什么。这样做能使得你们两个都得到成长，还能提高 code review 的效率。</p>    <h2>6.在实际的开发环境中 review</h2>    <p>现在的 code review 早就不是光用眼睛看啦，各种强大的 IDE 完全可以成为我们的一大助力。善用 IDE 的力量。</p>    <h2>7.不要吝啬你的赞扬，除非你能证明那里确实有一个 bug</h2>    <p>每个人的内心深处都是期待被别人称赞的，因此在 code review 开始的时候不要老是揪着变量命名、代码重复之类的问题。先集中注意力在真正重要的地方，给作者一个舒服、放松的心态（通常刚开始 code review 的时候作者是会很紧张的）。这样他们也就会乐于接受你对于代码风格等方面的建议了。: )</p>    <p> </p>    <p> </p>    <p>来自：https://zhuanlan.zhihu.com/p/24562689</p>    <p> </p>