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

#1 楼

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

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

作为审阅者，指出未达到目标的工作是您的工作，这是作者的工作确保他的工作确实达到目标。这样，告诉您如何进行更正不是您的工作。

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

#2 楼

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

#3 楼

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


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

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

#4 楼

在代码审阅中，审阅者是否应始终提出解决问题的方法？


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


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


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


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


何时才是最有效的解决方法？通信。我们是猴子而不是英语专业的代码。有时，显示代码糟糕的最好方法是...并非最佳...是向他们展示更少的代码...更多选择...哦，天知道你的意思了。

#5 楼

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

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

#6 楼

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

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

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

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

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

#7 楼

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

#8 楼

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


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

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

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

#9 楼

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

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

唯一的替代问题是，如果原始开发人员无法想到一种实现符合规则的功能的方法。假设您有性能要求，但是经过多次优化尝试后，该功能花费的时间超过了阈值。

！如果您的规则是主观的，则“名称必须由我批准！”然后，是的，您刚刚任命了自己的命名者，应该期望可以接受的名称列表的请求。

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

#10 楼

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

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

#11 楼

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

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

面对面，带宽要高得多，而且它具有防止敌对情绪的情感通道。

如果您实际上和那个人聊天，它会更快，并且您可能会结交新朋友，并且发现你们俩都更喜欢您的工作。