在代码审查中，审查者是否应始终提出解决方案？[关闭]

在检查代码时，我通常会尝试就如何解决问题提出具体建议。但是由于人们可以花费有限的时间进行审阅，因此这种方法并不总是能很好地工作。在这些情况下，如果开发人员自己提出解决方案，我会发现效率更高。

今天，我回顾了一些代码，发现一个类显然设计得不好。它具有许多仅分配给某些对象的可选属性，而对其他对象则留空。解决此问题的标准方法是拆分类并使用继承。但是，在这种特定情况下，这种解决方案似乎使事情变得过于复杂。我本人并未参与此软件的开发，也不熟悉所有模块。因此，我没有足够的知识来做出特定的决定。

我多次经历的另一个典型案例是，我发现一个明显毫无意义甚至误导的函数，类或变量名，但我自己却无法提出好名。

因此，通常来说，作为审阅者，可以说“此代码存在缺陷是因为...，是否有所不同”，还是您必须提出一种特定的解决方案？

作为审阅者，您的工作是检查一段代码（或文档）是否满足审阅之前已商定的某些目标。

这些目标中的某些通常会涉及对目标是否已实现的判断。例如，代码必须可维护的目标通常需要一个判断调用。

作为审阅者，您的工作是指出尚未达到目标的地方，而作者的工作是确保其工作确实达到目标。这样，告诉您如何进行校正不是您的工作。

另一方面，仅仅告诉作者“这是有缺陷的。解决它”通常不会导致团队中的积极气氛。对于积极的气氛，至少要指出为什么您的眼睛有瑕疵，如果有的话，可以提供更好的选择。
除此之外，如果您正在审查看起来“错误”的内容，但实际上没有更好的选择，那么您也可以按照“此代码/设计不太适合我，但我没有明确的选择。我们可以讨论这个吗？” 然后尝试使事情变得更好。

这里有一些很好的答案，但是我认为缺少一个重要的观点。您正在查看的代码，该人的经验如何以及他或她如何处理此类建议都将带来很大的不同。如果您非常了解您的队友，并且希望看到 “此代码有缺陷，因为...，请以不同的方式进行操作”之类的注释足以使他或她提出更好的解决方案，那么这样的注释就可以了。但是肯定有一些人对此作出的评论还不够，需要准确地告诉他们如何改进其代码。因此，恕我直言，这是一个只能针对个别情况做出的判决电话。

因此，通常来说，作为审阅者，可以说“此代码有缺陷，是否有所不同”，还是必须提出一个特定的解决方案？

两者都不是理想的IMO。最好的办法是与作者交谈并共同解决问题。

代码审查不必是异步的。如果您停止将它们视为官僚主义的过程，而花一点时间进行实时沟通，那么许多问题将释放出来。

在代码审查中，审查者是否应始终提出解决方案？

不。如果您不是审查者，那么您就是下一位编码者。

在代码审阅中，审阅者应永远不提出问题解决方案吗？

不。您的工作是传达当前的问题。如果提出解决方案可以解决问题，请解决。只是不要期望我遵循您的解决方案。您在这里要做的唯一一件事就是指出。您不必决定执行方式。

审稿人何时应提出问题解决方案？

这是最有效的沟通方式。我们是猴子，不是英语专业。有时，显示代码糟糕的最好方法是...并非最优...是向他们展示更少的代码...更多选择...哦，天知道你的意思了。

主要问题是，如果人们知道如何更好地编写代码，通常他们一开始就会这样做。评论是否足够具体，很大程度上取决于作者的经验。经验丰富的程序员可能会接受“此类课程太复杂”之类的批评，然后回到制图板上并提出更好的建议，因为他们因头痛而休假，或者因为匆匆。

通常，尽管如此，您至少必须确定并发症的来源。“这一课太复杂了，因为它违反了各地的得墨meter耳定律。” “此类混合了表示层和持久层的职责。” 学习识别这些原因并简洁地解释它们是成为更好的审阅者的一部分。您很少需要深入了解解决方案。

不良程序员有两种类型：一种不遵循标准惯例，另一种“仅”遵循标准惯例。

当我的工作联系/向他人提供反馈的信息有限时，我不会说：“这是一个糟糕的设计。” 但是类似“您可以向我解释这个课程吗？”之类的东西 您可能会发现这是一个很好的解决方案，开发人员竭尽所能，甚至意识到这是一个糟糕的解决方案，但这已经足够了。

根据响应，您将对如何处理每种情况和每个人有一个更好的主意。他们可以迅速发现问题并自行发现解决方法。他们可能会寻求帮助，或者会尝试自行解决。

在我们的业务中有建议的做法，但几乎都有例外。如果您了解该项目以及团队是如何进行的，那么可以以此为背景来确定代码审查的目的以及如何着手解决问题。

我意识到，这比起明确的解决方案，更多的是解决问题的方法。变化将无法涵盖所有​​情况。

当我查看代码时，如果我可以毫不费力地解决问题，则仅会提供解决方案。我确实尝试具体说明我认为问题出在哪里，并尽可能参考现有文档。期望审稿人为发现的每个问题提供解决方案会产生不正当的动机-这会阻止审稿人指出问题。

由于许多原因，我的观点是倾向于在大多数情况下不提供代码：

• 如果仅靠解释还不够，他们总是可以索要您所想的样本。
• 您并没有在浪费时间来尝试熟悉一些您很久没有接触过的代码，只是对其进行了少量修改，而其他人则只是花时间在做这些事情。
• 如果他们已经熟悉了这段代码，而您却不熟悉，那么仅给出反馈可能会导致比编写的代码更好的代码。给某人一个现成的解决方案通常会导致他们只使用它，而没有考虑进一步改进它。
• 始终提供解决方案迫在眉睫。您正在与某人合作，希望是因为他们足够优秀，可以被录用。如果您设法了解为什么某事是一个坏主意，他们为什么不通过听取反馈并自己做来学习呢？
• 总是提供解决方案是很奇怪的。想象一下，您正在他们的办公桌上进行配对编程：他们刚刚完成了几行您认为不好的代码。您只是告诉他们发现的内容以及原因，还是抓住他们的键盘并立即显示您的版本？这就是总是为您提供解决方案的感觉。
• 您总是可以说出自己要做什么，而无需花费时间来实际编写它。在描述问题中的第一个问题时，您就是这样做的。
• 不要分发食物，教如何钓鱼;）

当然，在某些情况下，您正在考虑某些特定的替代方法，值得附加。但这在我的经历中确实很少见。（很多评论，大型项目）如果有需要，原始作者可以随时要求您提供样本。

即使这样，由于第三个原因，在给出示例时，也许值得一说，例如，“使用它x.foo()将使此过程更简单”，而不是完整的解决方案-让作者自己编写。这也节省了您的时间。

我认为代码审查的关键是在审查之前就规则达成一致。

如果您有一套清晰的规则，则无需提供解决方案。您只是在检查是否已遵守规则。

唯一的替代者问题是原始开发者是否无法想到一种实现符合规则的功能的方法。假设您有性能要求，但是经过几次优化尝试后，该功能所需的时间比您的阈值长。

然而！如果您的规则是主观的，则“名称必须由我批准！” 那么，是的，您刚刚任命了自己的首席域名持有人，应该期望获得可接受的姓名列表。

您的继承（可选参数）示例也许更好，因为我已经看到了代码审查规则，该规则禁止使用长方法和“太多”函数参数。但是通常可以通过拆分来简单地解决这些问题。这是“此解决方案似乎使事情变得过于复杂”的部分，在此部分中，您的客观性受到侵犯，并且可能需要论证或替代解决方案。

如果可以快速简便地输入潜在的解决方案，我会尝试将其纳入同行评议意见中。如果不是，我至少会列出我的担忧以及为什么我觉得该特定项目有问题。对于变量/函数名称，如果您想不到更好的选择，我通常会承认我没有更好的主意，并以开放式问题的形式结束注释，以防万一有人可以。这样，如果没有人提出更好的选择，则不会真正阻止审核。

对于您在问题中给出的示例，该类的设计不佳。我会留下一些评论，虽然看起来似乎有些过分，但是继承可能是解决代码试图解决的问题并将其留在那的最佳方法。我会尝试用某种方式来表述，以表明它不是止步不前，并且由开发人员决定是否修复。我还要承认您对代码的这一部分不是特别熟悉，并邀请更多有知识的开发人员和/或审阅者阐明这样做的原因。

去和您正在检查代码的人交谈。友好地告诉他们，您发现它很难理解，然后与他们讨论如何使它更清晰。

书面交流导致大量时间浪费，以及怨恨和误解。

面对面地，带宽要高得多，并且有一条情感上的旁通渠道可以防止敌对行动。

如果您实际上与男生交谈，这会更快，并且您可能会结识新朋友，并且发现自己都更喜欢自己的工作。