Answers:
理想情况下，在敏捷的世界中，两者:)
测试驱动开发是一种鼓励在编写实际代码之前开发单元测试的方法-这样，您可以捕获代码中的规范并编写通过测试的测试。此后，确保所有各种不同组件都装配在一起的自动化集成测试是一件好事，可以进一步确保您的应用程序的功能符合预期。
至于代码审查，结对编程是一种有用的方式，可以让您在实际编写代码时让另一个人忽略代码。但是，这不一定是实用的方法。在我目前的公司中，它的工作方式是在开发人员的个人计算机上对代码进行测试之后，再将其部署到共享开发服务器之前，对代码进行审查。
进行代码审查是为了“擦亮”已经起作用的东西，以确保代码具有所需的质量水平并符合公司定义的代码准则。
在将来的常规优化活动中，代码重构也可能会发生，您可以在其中重构和改进旧代码。
如果您在签入之前先进行代码审查，则代码审查将介于两个测试阶段：您是开发人员首先对您的代码进行测试，同行进行代码审查，然后将其签入，然后以后专门的测试人员将进行更彻底的个人测试和集成测试。
首先测试。最后测试。测试，测试，测试。
代码审查是不错的选择。但是困难-如果涉及到个性或意见不同，这可能是一个痛苦的过程。
测试非常清楚：要么有效，要么无效。所以测试，测试，测试！并进行代码审查（如果可能）。
在我的上一份工作中，我们在产品生命周期的不同阶段进行了三种不同类型的代码审查。我们将第一种称为“健全性审查”，它发生在开发人员甚至没有进行单元测试之前-实际上，“健全性审查”是在功能完成之前就完成的。这个想法是让一对团队成员坐下来，在开发过程中随意浏览一些随机的代码部分，以确保开发顺利进行，并且我们不会以庞大的开发人员而告终一旦准备好合并功能，TDWTF便会进入。这主要是针对需要额外指导的人员（初级开发人员，新聘人员以及被分配从事与其他团队成员较不熟悉的工作的人员）完成的，通常是举行了简短的会议，只讨论了严重的问题。
接下来，我们进行了单元审查。这些通常由三个开发人员完成，并且将在测试单元/功能并准备好合并到主树中时完成。这是最严格的评论，将涉及很多细节。我们有3个开发人员，因为我们有代码的原始作者，树维护者必须在合并代码之前退出代码，以及选择了第三个开发者作为原始开发者的备份（这个想法是，一旦完成一段代码，就应该将全部知识转移给另一位团队成员，因此团队中至少有2个人完全熟悉代码库的任何部分）。
最后，我们进行了项目审查。它涵盖了整个团队，大约需要一周的时间，并且是在质量检查和产品发布之后完成的，目标是让每个人都参与其中，并在上一个发行周期中遍历整个代码库的所有更改，在此每个人都可以讨论架构变更，陷阱，并决定在我们开始开发下一版本的项目之前需要重构和修复的内容。
首先，为要开发的代码编写自动化测试。复查测试，以确保所有已知需求均得到测试。编写代码。根据需要进行多次检查。
如果需要任何手动测试，那么在进行任何手动测试之前，请务必先检查代码。否则，代码审查中建议的设计改进将被拒绝，因为必须重新运行手动测试。
首先是鸡蛋还是鸡肉？
这取决于。
如果您是新手，不确定要做什么，那么一定要请同伴给您一些帮助。这是非正式但非常认真且有价值的代码审查。
通常，尽管我建议您先做自己的工作，但要确保已熨平代码，并在正确的位置（即棘手的位，而不是明显的位）进行了很好的注释，但至少基本上可以正常工作（您有在最低限度的一般情况和某些极限情况或例外情况下进行了测试）。然后，将其带给您的同伴。
过早地审查代码可能会浪费您同行的时间。太晚进行审查可能会浪费您的时间。您需要找到合适的平衡点以实现最高效率。因此，首先进行一些测试，然后进行审查，然后再进行更多测试。根据复杂性和迭代情况，您可能会针对不同的目的和重点进行多次代码审查。
不确定性越高，您的评论就越多（当您处于早期学习阶段时，这是正常的）。越确定，您的评论也就越多（永远不要太确定自己，这总是不好，这意味着您通常不太像一个团队合作者，并且可能使其他人陷入困境，您需要确保您的代码可以被理解并被其他人使用）。只有在您处于中间时，评论才能间隔开一些。
只有我的两分钱。