等待审核时该怎么办？

在提出问题之前，我必须说明情况。

我在一家公司工作，担任初级软件工程师。当我完成了自己的发展并想要投入时，其中一位年长者总是阻止我。

他总是希望我等待他对其进行审查。可以，因为通常他会发现一些错误并进行一些优化。

但是，我必须在截止日期之前提交我的代码。完成后，我打电话给他，说结束了。他通常迟到。所以我的代码也迟到了。

我的问题是，我该怎么办？我应该等他复习吗？

编辑：除了问题。我很好奇另一个问题。

编码时我想自由。我如何获得对发展自由的信任？

_{一些解释： 我已经和他谈过了。但这没有帮助。我们已经使用了问题跟踪器，但是没有任何审查任务。只有开发和测试任务。}

所以我的代码也迟到了。

不，这不是您的密码，而是您和上级的密码。你们作为一个团队工作，有共同的责任，当你们两个错过最后期限时，这是你们俩的错。因此，请确保按时完成任务的人注意到这一点。如果该人也认为这是一个问题，那么他肯定会与您俩一起交谈-与与您的同事进行一次单独交谈可能会有所帮助。

并进行编辑：

编码时我想自由。我如何获得对发展自由的信任？

审查代码是最重要的质量节省工具之一。即使拥有超过20年的编程经验，也几乎没有双眼就可以编写出色的代码。因此，在一个良好的团队中，每个人的代码都应不断进行审查-您上级的代码以及您的代码。这与对您本人的不信任无关（或者至少不应该如此）。只要您相信没有第二双眼睛的“免费编码”会更好，那么您仍然是初级程序员。

在一个好的团队中，您应该在问题跟踪器中为您分配一排开发任务。

这样，当您等待审阅者时，您可以（应该）处理该队列中的下一个任务。一旦习惯了以这种方式工作，这将为您提供一次机会，使您的更改以“批次”的形式进行审核，从而减少了延迟。

• ^{如果您没有这样的“队列”，请与您的经理讨论，或者与审核者讨论。如果您的团队没有类似此类问题的合理便捷的问题跟踪器，请考虑研究工作委员会或公司内部的工作机会以找到一支更好的团队（您也可以与经理/审阅者讨论此问题，但不要指望它会有所帮助- 缺乏一个好的问题跟踪器通常是团队严重破坏某些东西的症状）。}

编码时我想自由。我如何获得对发展自由的信任？

要找出答案，您首先需要了解代码审查的目的。您提到信任 -这是一个很好的“近似值”，但并不完全准确。

• ^{例如，在我最近的一个项目中，开发工作是由我和我的同事组成的一个小型团队完成的。我们完全相互信任并互相尊重-但是尽管如此，我们还是检查了100％的代码。我们之所以这样做，是因为这使我们能够找到并快速修复一些错误，这也非常重要，因为审阅并不需要太多时间，也不会阻碍我们的工作。}

您会看到，为了防止某些风险而在投入的精力方面考虑代码审查会更加准确。在一个好的团队中，您可以期望获得关于如何“适当平衡”这一点的共同理解。请注意，并没有一种万能的，万能的平衡，它在很大程度上取决于一个项目- 关键任务软件中的错误的风险和影响自然不同于非关键应用程序中的错误。

使用您的示例，只要在您提交代码之前发现可以更好地修复的错误和改进来证明您的审阅者付出的努力是合理的，就可以期望“阻止评论” 。

他们可能希望通过实践和在复习中获得指导，您将能够更好地进行编码，因此他们将发现越来越少的值得在提交之前解决的问题。一旦他们发现您的代码“足够安全”以允许使用不太繁琐的“风险预防措施”，您就可以期望过程会发生变化，例如在提交后进行审核。

根据项目的不同，有时甚至可以认为您的代码足够安全，完全可以跳过评论，而将错误的发现留给了测试人员（但这不一定会发生，请参见上面的示例）。

这里有多个可能的答案，具体取决于您的问题所在。

• 如果您最关心的是“我错过了截止日期”，则不会。你们两个共同错过了最后期限。您能否（充满信心）说：“我会在一个小时内完成，那么我们可以进行代码审查了吗？”？那可能就足够了。您可以在截止日期前一天完成代码吗？那应该是足够的缓冲。您是否正在完成代码，在“请审阅”和截止日期之间留有足够的缓冲空间？我想说，如果是后者，那甚至不是共同的过失。

• 代码应始终进行审查。如果没有（至少）第二只眼睛和另一个人“没关系”，我无法检查任何东西。这适用于我是首席程序员的项目，也适用于通常不参与的项目（但是设法找到了一个会影响到我的错误，需要修复）。但是，审查的严格性很大程度上基于信任。如果我相信要提交代码的人员对代码库了如指掌，我将不会像我不知道该人员对代码库的了解那样严格。

我的问题是，我该怎么办？我应该等他复习吗？

不，你不应该只是闲着。总有事情要做。正如Gnat建议的那样，应该有许多任务。或者，以一种敏捷的开发方式，为当前迭代分配给您的任务列表。如果您闲置，则公司或团队的组织有问题。

另一件事是：您的高级主管真的检查您执行的每段代码吗？如果是，您还可以进行配对编程。

编码时我想自由。我如何获得对发展自由的信任？

有一些法规要求高级人员检查初级人员的工作（我认为医学iso 62304要求这样做）。如果是这样，您将无能为力。

您可以更改的是要求上级不要从字面上检查所有内容。您可以设置代码审查过程，并检查重要事项。

在本地使用git，将更改提交到分支，然后在等待时从任务2开始。然后，当他完成工作时，您可以将他的更改合并到新工作中，而您已经在下一项任务上处于领先地位。

这样做时间足够长，很快，他可以一次坐着查看2项或更多内容。选择线条不太可能重叠的事物以最大程度地减少冲突。

一种解决方案可能是让Pairing Programming早日让高级开发人员参与您的工作。

配对编程上的Wikipedia页面

对您而言，最明显的好处是，审核过程在过程中进行得较早，因此您不必再等待高级开发人员。

不仅如此，您还可以看到高级开发人员在编写代码时的思维过程和技术，并从中学到东西。

您可能有高级开发人员可能不想与您配对的问题。这可能很困难，但是我自己的经验是，高级和初级开发人员都从结对编程中获得了很多经验。

通常还存在这样的担忧：如果让2个开发人员从事同一工作，您的生产力将降低一半。结对编程很难衡量对生产力有什么影响，我听到的最常见的回答是，成对的团队和不结对的团队的生产力大致相同。（如果有人知道对此有任何好的研究，我很想听听）

它本身并不是一个完整的答案，只是上述出色答案的补充...

您是否在签入代码之前先检查自己的代码？我知道这不是最有趣的，但我会尽量让自己自己去做。我从事专业编程已有20年（共34年），但是我通常会发现至少一个错误和/或一件我忘记的事情，或者至少可以做得更好。我同意这样的观点，即应该始终检查您的代码，并且第二眼胜过一对。但是，即使是同一对代码遍历两次也比一次更好。

您是否为代码编写单元测试？除了单元测试之外，我还有一个小的Shell脚本，用于搜索我个人最常犯的错误。其中一些是英语语法和拼写，有些是编译器无法捕获的编码问题。我会在检查大型更改之前运行它，以对下游的每个人表示感谢。

我通常会让人们写他们的代码，以后偶尔会抱怨它，但是我不会检查每一次签入。我曾经与一个非常初级的程序员一起工作，我的代码必须检查并且通常撤消，因为它们犯了很多错误。结局不好。您所在的行业通常正确完成工作比按时完成更为重要。如果您从错误中学习，您将走得更远。

如果您可以最大程度地减少审阅者需要对代码进行的更改的数量，则可以最大程度地提高他们相信您编写并非总是需要仔细审阅的代码的机会。如果您希望不受审查，请对自己的输出质量承担最大责任。

这些建议中的一些或全部建议可以在等待其他人查看您的代码时完成。

我认为执行手动代码审查是...很好...大约80年代。好吧，也许是90年代。

在这个持续集成和在线代码审查系统的现代时代，您确实不想仅因为担心“它可能破坏源代码控制”而阻止任何代码提交。

来吧，人们 这就是变更集（或变更列表）的用途。您让程序员喂饱了源代码控制系统的饥饿之花。然后，您的持续集成服务器将启动一连串的目标构建（好吧，希望只是每天的构建，但是我们当中有些人会被带走）。如果发生任何故障，您可以将代码猴子奖杯（通常是从幸运符谷物盒中找到的塑料玩具）放在犯罪者的桌子上，然后回滚损坏的零钱清单。好吧，某些持续集成系统会自动向团队/部门/组织中的每个人发送电子邮件/ IM /桌面通知，通知其构建已被破坏，同时还有一个漂亮的超链接，可显示在文件或测试中完全破坏了构建的每个人。现在是不幸的程序员

随着此过程的进行，代码审查系统将启动（再次由签入触发）。通知合格的团队成员列表已提交给源代码管理的变更列表，在审查系统中开始审查，每个人都开始对变更列表中的变更进行注释。希望每个人都会说“ LGTM”。如果程序员很聪明，他会记得祈祷/贿赂/隐藏。如果存在严重问题，审阅者可以创建缺陷（可以将其挂接到错误跟踪系统中），甚至要求撤消变更列表。是的，撤消更改不仅伤害自我，而且伤害心灵，这是事实。对于初级开发人员来说，重新集成被拒绝的变更列表是一个不错的选择。

如果您的开发环境缺少配置项或代码检查系统，则应认真调查这些情况。几个链接可能会帮助您：

Atlassian坩埚
JetBrains TeamCity
重新启动
巡航控制系统

如果要获得CI服务器，还应该认真考虑单元测试框架。如果您是C＃开发人员，请研究类似NUnit的入门。

您可以提前告诉他代码准备就绪的时间，而不是告诉代码完成的时间。您应该能够确定大约。提前一周。这使他有时间准备和计划审核，以使其适合您的两个计划。