即使工作顺利，与上级和老板一起审查课程是否很好？

在我公司中，在交付任何项目之前，老板要求我的前辈审查由我或其他团队成员编写的程序，有时老板也会坐在一起与我们一起审查。

我认为这是获取知识的一种好方法，但是有时候程序运行良好时，经过审查它们就无法正常工作，因此我需要再次查看我的程序。

他们说，评审有助于优化程序和查询的执行，但是相对于程序的实际功能，我们能否更喜欢优化？

“做得好”确实是一个很好的指标，但是如果您是团队中唯一能够解密所写内容并加以维护的人，那么该代码对于公司的中长期而言几乎是一文不值。

一个好的代码至少是：

• 按预期工作
• 可读/清晰
• 易于维护
• 易于扩展以适应未来的变化
• 安全
• 没有不必要的依赖
• 正确处理非名义案件
• 等等

（其中一些要求实际上是重叠的，但最好单独考虑...）

代码审查的目的超出了“工作”部分的范围，可以通过自动测试来完成。

我个人知道，将某些工作拆散并不得不从头开始进行重建很烦人。但是，通常这是由于高级/技术负责人的沟通不畅造成的。因此，如果您认为您下次必须重写得太多，请在写一行之前，先去审阅一下审稿人，然后尝试获取尽可能多的关于他的期望的详细信息。如果代码审阅者团队在每个开发人员都可以参考的正式文档中总结他们的期望，那也可能很棒。

从更积极的方面来说，会议也可能是分享优秀实践/设计的机会。

我将您的问题解释为“我的功能代码是否可以在审查中被破坏到甚至无法编译？” 。

是的，它可以。一般来说，审查期间，你看如何你的代码做它做什么。当您要提交代码时，表示您已经完成了程序的特定部分。

您说它有效。然后进行测试以验证这一点。通过测试的模块并不意味着不应再次触摸该模块。

出现功能的模块仍然可能是一场灾难，等待着您的等待，无论是在运行时还是在您或其他人必须对其进行维护的几个月内。通过在评论中更改您的代码并指出问题出在哪里，您的评论者正在（希望）尝试实际教您一些知识。

同行评议无疑是一种很好的学习方式。某人可能会看到不同的东西，他们对您有不同的经验，应该能够做出改进。这不应该是贬低的，我希望任何开发人员都能够评论和建设性地批评任何人的代码！

在我看来，其中一些“改进”实际上正在做出重大更改，因为（正如您所期望的）审阅的开发人员在软件方面的经验少于作者。

这种趋势是它的自我反馈，也许您的代码难以遵循或维护？您的评论有价值吗？绝对！我可以看到令人沮丧的是，有一个正常工作的代码随后被同行打破了，您不应该灰心-您应该努力保护自己的代码不受这些更改的影响。

然后，问题就变成了如何保护程序的功能，以便您可以在完成审阅后知道该功能仍在工作。我的建议是确保您拥有不错的单元测试范围。这样，无论您/您的审阅者/您的继任者何时更改代码，他们都可以确信所做的更改是安全的。

ETA：我刚刚发现了您的评论中的一个，我敢肯定，这毋庸置疑，但是代码审查应该在测试团队开始之前进行。否则，他们不会测试最终产品。