- 评审与自杀相比有一个优势：自杀是你拿自己出气，评审是你拿别人出气。
- “代码审查”是我们大多数人提高自己的最佳方式。
- 代码审查所带来的责任，会使你的编码质量提高。
- 审查将会把源代码放在显微镜下，这并不是为了取笑或者惹恼作者，而是为了提高团队制作的软件的质量。
我们可以采取以下方式来避免代码审查： - 配对编程。这样你的代码在编写的过程中就得到了有效的审查。
- 开发源码。这样允许任何人查看、判断代码的质量和修正问题。有人称之为“终极代码审查”，但是不是所有的代码都会被人看到，只有那些真正受欢迎的开源项目才会拥有被积极的维护的代码库。
- 单元测试。这是一种自动执行的方法，用于证明某个更改是否破坏了代码输出的正确性，但是这种方法无法提高我们代码的整体质量。
- 不进行审查。如果采取这种方式，一般情况下，只能祈祷好运了。
代码审查可以是如下方式的： - 个人的。作者仔细并系统的审查他或她自己的工作，以确保其工作的质量优良。
- 一对一的。让另一位程序员演练你的代码，这和配对编程有异曲同工之妙。
- 正式的。让其他程序员参与进来，可以带来新的知识、更多的经验和对这项任务更多的关注，而且也转变了进行审查的视角。
- 代码审查是检测和消除难以发现的bug、提高代码质量、增强集体的代码责任感和传播知识的一种非常出色的工具。
- 当我们编写一个系统时，我们需要问一问是否要审查代码，以及如果要进行你给审查，那么要审查的到底是哪段代码。
- 有一些明显的缺陷是你很快就能发现，还有一些更细微的问题，只有在被没有任何先入之见的新的眼睛过目之后才能被发现。
- 不对代码进行审查，会极大的增加缺陷溜进你的软件产品的机会，这样就会给你带来窘迫、许多代价巨大的重复劳动和现场升级。
- 良好编写的代码可以分解为一些独立的部分，这些部分可以分别进行审查。
- 你必须选择那些最能从审查中获益的代码，也就是哪些最有可能编写的很糟糕的代码，或者是哪些对于系统正常发挥作用最重要的代码。
- 最常见的审查方式是正式的代码审查会议，这种会议将有一个固定的议程表，以及一个预先确定的结束点。
- 许多人都对代码审查避之唯恐不及，因为他们害怕暴露自己的不足。
- 审查你的代码是学习新技术的一个很好的方式，你必须足够谦虚，承认自己并不完美，并且愿意接受别人的批评。你的编码风格会随着你从对你的工作进行修改中学习而逐步得到提高。
- 那些不害怕他们的代码中有bug并且不害怕别人找出这些bug的程序员，会创作出更好、更安全并且更正确的软件。
- 当审查你的代码时，尽量不要浪费别人的时间，在将你的代码拿出来接受评审之前，自己先做一次模拟评审。
- 在对别人的代码进行审查时，不要对作者进行人身攻击！提意见的手段和技巧都非常重要，对代码提意见，而不是对编码人员提意见。
- 代码审查是一个协作的过程，每位评审人员都是平等的，职位的高低并不重要，并且所有的意见都应该得到考虑。
- 代码评审的成功，在很大程度上取决于采取积极态度的作者和审查人员，审查的目的是通过集体协作来改善代码，而不是职责某人或证明实现策略的正确性。
- 如果你不知道优秀的代码是什么样的，那么你就不能对其他人的工作作出正确的评价。
经过审查代码，应该具有以下特质： - 没有bug。（这个似乎不太现实，评审只能尽量减少bug，而不能消灭全部bug）。
- 正确。代码必须符合所有相关的标准和需求。确保所有的变量都有合适的数据类型、注释都很准确。
- 完整。代码必须实现了整个功能规范。
- 结构良好。设计必须可靠，代码易于理解，没有重复代码。
- 可预知。不应该存在任何不必要的复杂性和无法预料到的意外。
- 健壮。代码应该是防御性的。
- 数据检查。
- 可维护。
- 在审查代码之外，对于开发过程中产生的各种文档，也是需要审查的。
- 代码审查可以扩散知识并传授编码能力。
- 优秀的程序员更在乎的是编写出优秀的代码，而不是他或她自己的自尊心。
- 优秀的程序员：1. 渴望代码审查，并对他们的代码质量充满信心；2. 接受别人的意见并从中学习；3. 可以合理并准确的对别人的代码发表意见。
- 糟糕的程序员：1. 害怕代码审查，并惧怕别人的意见；2. 不能良好的接受批评意见，他们会过分的保护自己，而且很容易被激怒；3. 利用审查来现实他们对能力稍逊的程序员的优越感，他们的意见非常刻薄，而且没有任何建设性。