在点对点编程中，两个开发人员在一台机器上工作。一个人编写代码，另一个人在工作时提供建议和反馈，并且他们定期交换角色。这种方法是极限编程（XP）方法的一部分。这对于处于职业生涯早期阶段的开发人员来说非常有用，但对于所有开发任务来说并不是非常有效。此外，在解决需要两个人共同思 购买电话号码列表 考的复杂问题时，它很有用，但这通常发生在设计阶段。实际的代码编写可以由单个开发人员管理。
问题是，点对点编程是否消除了代码审查的需要？不！
两个进行点对点编程的开发人员从相同的角度参与编写代码。他们可能会以类似的方式解释需求、思考设计并分析问题。我们总是需要外部视角，需要有人提出问题、指出差距并考虑需求。这就是为什么正式的代码审查至关重要。
代码审查工具
代码审查工具对于管理审查生命周期以及可能出现的评论和问题很有用。有些团队发现它们很有用；其他人则更喜欢使用简单的文档或直接在源代码控制中提出问题。如果工具辅助代码审查对您的团队很有用，请寻找一种可以轻松协作、跟踪更改和共享评论的工具 – 无论是代码审查会议还是离线代码审查。
以下是一些流行的工具：
- SmartBear合作者 （商业的）
- 格里特 （开源）
- Codestriker （开源）
- Atlassian Crucible （商业的）
积极的语气和友好的问题，以及清晰、简洁和果断的任务
确保保持积极的语气并提出友好的问题（而不是攻击 频繁检查可以帮助您识别问题并采取措施解决问题 性和侮辱性的问题和语气）。即使您认为自己知道答案，也要像不确定一样询问（“这个操作有锁定机制吗？我们需要锁定机制吗？”而不是：“我在这里没有看到锁定机制，你犯了一个错误！”）。给予积极的反馈（“大家，方法不错！”）也是很好的（并且受到鼓励！）。
但是，当涉及到代码审查的结果时，它们应 点对点编程是 该清晰、简洁和果断（“需要为更新缓存操作添加阻止机制”）。
代码审查中的注释类型
审查代码时有几种类型的注释，每种类型应区别对待：
- 重命名—— 在审查代码时讨论名称是正常的。众所周知，命名是编码最困难的方面之一（这是有充分理由的；或者不是）。然而，命名对于代码的可读性和管理至关重要。不要犹豫在代码审查期间请求更改名称，即使这需要大量的代码审查并需要额外的审查说明（我们将在第二部分讨论命名注释和最佳实践）。在许多情况下，在 IDE 的帮助下可以立即完成重命名。如果是的话，就让开发人员来处理吧。如果需要更多时间（思考合适的名称或重构 IDE 之外的其他代码部分），请将其标记为注释并让程序员稍后处理。
- 文档 ——与命名一样，在意图不明确的地方添加注释，或尝试改进现有的注释，对于代码的可读性和可维护性至关重要。这应该是代码审查的一部分。再次，对于简短的评论，让开发人员在代码审查期间当场添加它们，否则将此评论标记为待完成的任务。请注意，添加适 阿尔及利亚商业指南 当的注释应该是一种防止代码集成的演示工具，因为推迟或忽略它们可能会导致注释被遗忘。
- 未能遵循代码指南和约定 ——代码指南和约定使我们能够维护大型代码库并理解他人编写的代码。代码审查可以防止非标准或不适当的代码进入您的存储库。
- 错误、错误和潜在错误——不符合要求、缺失或不正确的错误处理、逻辑错误、设计不佳、效率低下和不正确的假设——是代码审查的核心（我们将在本博客的第二部分更深入地讨论这个问题，包括具体的 C++ 元素）。
- 需要澄清——在审查代码时有些问题无法得到清楚的回答（“如果我们到达这个阶段，规范是否允许撤消操作？”）。最终的任务就是调查本身，并且在许多情况下，将记录要采取的行动以及每种可能的应对措施。
- 这是件好事—— 在某些情况下，我们有一个建议，但我们不希望在本次迭代的程序中实现它，但我们希望将其记录为一个本来很好的想法。这可能包括有关效率改进和代码简化的建议，这些建议不是强制性的或太耗时的。我们仍然要记住，提出这些想法有两个原因：（a）如果我们有时间并且以后需要这样做，我们可能想要实施它们，（b）我们希望避免在未来的修订中重新审视这些想法（所以我们现在记录它们）。此类注释可以作为 TODO 注释插入到代码中，并具有自己的到期日期（如果到期日期之后尚未完成，则可以删除 TODO）。