我目前正在审查刚刚加入我的团队的一些初级开发人员的代码，我想知道应该如何提供此审查的结果：
我应该自己修复代码吗？
我是否应该向他们提供有关审核过程的反馈，并让他们根据我的指示进行修复？如果是这样，我该如何提供反馈，是否填写某些模板文档并将其发送给他们，或者有一些软件可以帮助我在代码文件中标记出有问题的地方，以便以后进行检查？（我正在使用Visual Studio）。
在我完成对代码的审查并完成修复之后，过去的一段时间已经过去，我过去审查过的代码的某些部分也发生了变化，如何进行重新审查？我应该重新检查所有代码吗？还是只检查已更改的零件？如果是这样，我如何跟踪已更改的部分，从而避免重复检查代码？
Answers:
简短答案
我应该自己修复代码吗？
没有。
我是否应该向他们提供有关审核过程的反馈，并让他们根据我的指示进行修复？
是。根据您的建议，而不是指示。说明听起来过于权威。
如果是这样，我该如何提供反馈，是否填写某些模板文档并将其发送给他们，或者有一些软件可以帮助我在代码文件中标记出有问题的地方，以便以后进行检查？（我正在使用Visual Studio）。
使用工具提供反馈。您可以使用Visual Studio。
长答案
我曾经使用过Visual Studio，但是我经常不得不问其他开发人员，“嘿，您可以将您的作品发送给我，以便我进行审查吗？” 我不喜欢这样，而且效果也不太好。现在，我使用“ 审阅助手”，因为我可以通过查看签入开始审阅。我不需要依靠其他开发人员将工作寄给我进行审查。它还可以帮助我将项目标记为缺陷，或者仅标记要由作者查看的项目。这对我们的团队有效，因为一旦我们开始审阅，它就会留在审阅板上，不会丢失翻译内容。它与Visual Studio集成在一起。正如我所提到的，Visual Studio也有其本机检查过程，但我发现它有局限性，并且过程是不自然的。因此，我使用Review Assistant。
该工具还有助于来回过程，讨论等。
该过程或多或少如下：
我查看了一些内容，然后将其发送给作者（在您的情况下为初级开发人员）。他们进行更改，然后将其发送回去。我查看这些变化并提供反馈。如果我对更改感到满意，请关闭评论。否则，它会来回移动。有时如果来回太多，我会走到他们的办公桌旁并使用白板-这确实加快了这一过程。
代码审查是一个敏感领域，因此在选择措词时要格外小心。我从不告诉任何人
措辞选择不当
我检查了您的代码，有些项目需要更改。
我这样说：
更好的措辞选择
我查看了您的代码，需要帮助。您能否查看我发送给您的物品，看看您是否可以澄清我的一些问题？
这使作者认为：
这些简单的单词选择极大地帮助了我。
我从未低估初级开发人员。我曾与一些高级开发人员（超过10年的经验）一起工作过，那里的代码比初中的合作学生还差。因此，仅仅因为他们是高年级还是初中生就没有那么重要了。他们的工作真正胜过多年的经验。
通常，为了鼓励初级开发人员并使他们参与评论，我会给他们发送一些评论给我：他们可以弄清楚的东西，他们会发现有挑战性的东西，但并不能完全超越他们。我可以这样说：
您能帮我复习一下代码吗，因为我无法弄清楚。
这再次极大地帮助了我。这很有帮助，因为它清楚地表明，我不是唯一一个进行评论的人，但他们也进行评论，并且也是过程的一部分。它表明整个想法是产生良好的，干净的代码，并在需要时寻求帮助。审核过程是一种文化，因此我们确实需要为此而努力。
现在，有些人可能会担心，如果他们这样做，则初级开发人员将失去尊重，因为他们只是做了您做不到的事情。但这远非事实：寻求帮助表明谦卑。另外，在很多情况下你都可以发光。最后，如果这是您的恐惧，那么您就有自尊心的问题。最后，也许我真的不知道：我的意思是，其中一些开发人员脑海里浮现出新的算法，因为他们是一个月前才进行研究的。
无论如何，回到初级和评论。当他们弄清楚并向我发送回复时，您应该看到他们脸上的表情。然后我可能会告诉他们：“好，让我进行更改，如果您对此感到满意，请关闭此问题。”
他们有能力查看我的工作并说：“是的，您所做的更改很好。我已解决了问题。”
我从来没有亲自修改过代码，因为：
但是我会在意见中提出想法和代码段，以帮助作者。请注意，有时我的评论只是在问作者我不理解他们的代码。他们的代码可能没有错。他们可能需要更改变量名称，添加注释等。因此，在这种情况下，我什至不知道要更改什么；只有他们会。
如果您继续进行审核，那么您迟早会对团队中每个开发人员的知识水平有个很好的了解。知道这一点非常有用，您需要利用它并释放它。方法如下：如果我查看一些代码并看到明显的需要改进的地方，并且我知道其他开发人员也可能会抓住它们，那么我将让他们对其进行检查。诸如“嘿，我看到一些可以改进的地方。您可以更详细地检查一下，并将您的评论发送给作者吗？” 这也很有效，因为现在我还有2个其他的开发人员正在互相合作。
如果我正在审查某些工作，并且发现整个团队都可以从中受益，那么我将创建一个假设的情景并在会议上解释该问题。我将首先说明情况，并询问每个人是否可以找到问题或看到问题，让他们参与进来。让所有人提出问题。然后最后提出一种更好的方法。如果其他人有更好的方法，我要感谢他们，并在团队面前承认他们的方法更好。这表明我不是“我的路还是高速公路”类型的人格。而且，我从不打开某人的工作并开始在会议上指出问题，无论我认为我是多么友好和无害，作者都不会对此表示赞赏。
当我进行审阅时，我不仅在寻找优质的代码，而且还在寻找代码的功能。如果业务要求是：如果员工已经在公司工作了10年以上，请给他们增加5％的薪水。否则为2.5％。我检查的第一件事是它是否确实正在这样做。然后，我检查它是否以干净，一致和高性能的方式执行此操作。
如果我进行了审核，请确保进行跟进，否则没人会认真对待这些审核。
几年前，我曾经与某人一起工作，该人会进行审核并抄送开发经理和质量检查经理，但两位经理都来自商业背景或几乎没有开发经验。他这样做只是给他们留下了深刻的印象。没有人喜欢它，那是当我告诉自己我永远不会犯那个错误。
他过去要做的另一件事是选择编程风格，并确信他的风格是最好的（“我的功夫比猴子风格更好……”）。这对我来说是另一堂课：解决问题总是有不止一种方法。
回答您的一些编号问题
1-我应该自己修复代码吗？
不，请查看我上面所述的原因。
2-我应该给他们有关审核过程的反馈意见，并让他们根据我的指示进行修复吗？
是的，请尝试使用友好的句子和语气，但需要引起注意。尽可能清楚。说明代码的问题是什么，如何改进它。不要简单地要求更改它。但是提供原因。
我如何给出反馈，我是否填写某些模板文档并将其发送给他们，或者有一些软件可以帮助我在代码文件中标记出有问题的地方，以便以后进行检查？（我正在使用Visual Studio）。
就像我说的，您可以使用我使用的工具或其他工具。不要使用电子邮件或Word文档，因为它们会丢失并且很难跟踪。
完成对代码的审阅并完成修复后，有时已经过去，并且我过去审阅的部分代码已更改，我该如何进行重新审阅过程？我应该重新检查所有代码吗？
通常，我要做的是检查增量（仅更改）。但是您需要牢记总体情况，以确保没有任何损坏，并且它遵循体系结构。
最后的想法
我个人认为“代码审查”一词是一个糟糕的选择，并且不知道它是如何开始的。他们本可以选择一个更好，更权威的词。
making sense architecturally，我的意思是确保数据访问层代码位于数据访问层之内，UI验证位于UI等中。换句话说，确保所关注的问题不会渗入其他区域。有一些工具可以帮助保持体系结构。实际上VS现在开箱即用。我们也使用它。
在很大程度上取决于您如何理解公司的代码审查。在有些公司中，代码审查是一个高度正规的过程，很少发生，但是意义重大。在另一些情况下，代码审查是每个任务的必需部分，它是已实现的，是一件非常平凡而又快捷的事情，几乎没有形式主义。就我个人而言，我选择后一种方法，但是无论是否可以使用，它都可能由您决定。
我写了一篇博客文章，标题“代码审查值得您花时间吗？总结我的团队使用的过程。与您的问题相关的要点是：
至于复审-修复-检查-修复周期，您选择的内容应取决于开发人员的成熟度和发现的问题的严重性。一旦团队使代码审查成为日常工作，您就可以期望进行微不足道的更改（例如重命名类），而无需重新检查它们。如果团队尚未通过代码审查出售，或者人员真的没有经验，那么您可能想检查一下这些东西。另一方面，如果您的评论发现了一个复杂的并发问题，即使初级开发人员在向他们指出后也可能无法完全理解，您最好检查一下修复程序，不要在确定确实得到纠正之前就给予更改批准。
工具可以帮助您解决此问题，因为如果处理拉取请求，则可以轻松设置软件，直到获得预定数量的开发人员的批准才允许合并更改。通常，您可以查看更改的各个提交中的更改，这使您可以轻松地仅查看自上一轮注释以来添加的更改。
我投票赞成第二种选择。大三学生自己进行更改时，可能会有更好的“曲折曲线”。
另外：不要成为唯一审查代码的人。
让您团队中的一些有经验的成员也查看代码并安排定期的审核会议 ，在此会议上，审阅者向作者介绍他们的发现（在会议之前完成！）。这将提高初级人员和经验团队成员的积极性。