Answers:
看看facebook如何使用自己的名为phabricator的应用程序做到这一点：http ://phabricator.org/
他们基本上基于每个问题进行提交，并且对于每个问题，都会显示代码，该代码将由某人进行审核。除非审阅者认为可以，否则代码不会进入主存储库。
我想它使它更有趣。
另外，也许应该将代码分配给两个人：一个由谁来执行，而一个由谁来对其进行审核。
尽管您的队友可能不相信此评论。
就个人而言，在没有审阅者的情况下，我将单元测试用于较低级别的功能，而将“看门人测试”用于所有其他功能：看门人测试采用这种方式，因为即使是看门人也应该能够理解您的代码。
我通常删除一些较小的部分，例如块/功能范围括号，可见性标记，有时甚至是类型，并向要求代码的人员，经理，领域专家，队友展示：“这是您想要的吗？”
此外，亲自去那里，直到完成审核后再离开也有帮助。
或者，如果您对团队不满意，或者他们对您不满意，您就会知道，“如果您可以更换公司，请更换公司” ...
在以前的几位雇主中，我们轮换了每天接受“代码审查”的人员。通常，有3个人共享一个CR日，每个CR必须由两名审阅者签署。这样可以确保在您工作的那一天，无论其他项目如何，都知道CR是您的期望。因此，每五天左右，该轮到您了，您可以相应地调整开发任务。
目前，我们有一个团队负责人对其团队的代码进行粗略的CR。根据CR的完成情况，可以根据应用程序的哪个区域进行更新，然后将其提交给Global Review Team，在这里，我们检查对应用程序具有全球影响的事物，而不是与单个功能有关。当需要进行大量审核时，我们通常将其分解为几个人，因此没有人需要处理大量文件中的更改。
也就是说，我们只会审查已提交给当前Dev分支/变体的代码。在将代码提升到下一个（例如Alpha）环境之前，必须先通过代码审查，全局审查，数据库审查和UI审查（根据需要）。
最后，我们同意SLA关于如何快速处理评论。几乎没有什么东西排在48小时以上，大多数评论都在不到24小时内完成。
我工作的公司要求所有代码在提交之前都要经过其他开发人员的审查。我团队的成员经常感到沮丧。
除非您为生产发布候选代码编写关键任务软件或关键补丁，否则没有令人信服的理由严格遵守特定类型的代码审查。
走在你的鞋，我想第一点是管理后提交代码审查，同样被认为是可敬的预提交的。这些术语可在网上搜索-如果需要，请在此处找到备份的参考。一个人不一定需要预先提交评论才能获得100％的评论代码。
基于以上内容，我接下来建议他们放弃微观管理的态度，让开发人员尝试对他们而言更方便的方法。提交前或提交后的评论最好留给程序员选择。如果公司比程序员更了解，他们为什么不自己编写代码？
您有许多问题要解决-必须赢得人心，并且必须确保有时间进行代码审查。
第二部分可能是最简单的-您同意（集体并且必须包括管理人员），开发人员每天早晨要做的第一件事是他们的代码审查-这是简单，可理解，有效的方法，并且为您提供了打败他人的好方法如果他们不遵守。更好的是，您没有打扰任何事情，不是在要求他们停止处理他们的代码，也不是在要求人们将某些内容压缩到他们的工作清单中……
第一部分是真正的问题-审核过程中的参与者必须将其视为具有价值，否则，他们在编写代码或修复错误（其中包括错误）时将永远不会进行代码审核（认为没有价值）。当然更重要...？）。
如果您可以将两者放在一起-首先确保每个人都相信（或理解）代码审查中的价值-基本上，这应该意味着更少的错误，这意味着更多的新代码通常更有趣-然后其次是事情，以便在时间表中有明确的空间来进行代码审查，然后希望会发生好事...它将成为文化的一部分。
一旦成为文化的一部分，就不再需要说“每天第一件事”了-但是说了一下，我认为它很适合某个人可能希望开发人员参与的模式。
考虑使用诸如Review Board之类的工具。这是非常有帮助的，特别是对于长评论。
您可以上传差异文件，然后等待评论者完成评论。如果您有公开的评论使您无法继续工作，则可以在日常会议中进行报告（您的团队希望检入新功能，以便尽快对其进行测试，不是吗？）。