当其他人构建了一个过于复杂的解决方案时，您在代码审查中怎么说？[关闭]

前几天，我审查了团队中某人写的代码。该解决方案不能完全发挥功能，而且设计过于复杂-意味着存储了不必要的信息，构建了不必要的功能，并且基本上，该代码具有很多不必要的复杂性，例如镀金，并且它试图解决不存在的问题。

在这种情况下，我问“为什么要这样做？”

答案是另一个人喜欢那样做。

然后，我问这些功能中的任何一项是否属于项目规范，或者它们是否对最终用户有用，或者是否有任何额外的数据会呈现给最终用户。

答案是不。

因此，我建议他删除所有不必要的复杂性。我通常得到的答案是“已经完成了”。

我的观点是，它没有完成，有错误，没有满足用户的要求，并且维护成本会比我建议的简单方法高。

一个等效的场景是：
同事花费了8个小时的手工重构代码，而这本可以在10秒内在Resharper中自动完成。自然，我不信任手工重构，因为它质量可疑且未经充分测试。
同样，我得到的答复是“已经完成了”。

对这种态度有什么适当的回应？

心态/态度

• 以身作则
• 私下告诫（一对一，代码审查之外）
• 鼓励团队成员保持简单的心态

团队管理

• 在工作项目的规范上花费更多时间（例如体系结构，算法概述，UI线框等）
• 鼓励团队成员澄清工作项目的范围
• 鼓励团队成员讨论实施工作项的方法
• 在开始之前，对每个工作项目进行合理的估算，并尽最大努力满足这些要求
• 监视团队成员的“改进”。
  • 在被警告或被告知正确的做事方法之后，请查看团队成员是否有所改善。

技能等级

• 安排一些时间进行配对编程课程或一对一培训课程，以充分利用开发人员工具（重构，代码审查）

项目（风险）管理

• 异步地更频繁地执行代码审查（注）
  • 关于“异步”的注释
    • 提交代码审查者后，应立即收到通知/邀请以审查变更
    • 在与开发人员举行任何会议之前，代码审查者应有机会审查代码。
    • 如果需要开发人员澄清，请在IM /电子邮件上非正式地进行澄清，不要发表负面意见

当其他人构建了一个过于复杂的解决方案时，您在代码审查中怎么说？

您说：“您构建了一个过于复杂的解决方案。”

因此，我建议他删除所有不必要的复杂性。我通常得到的答案是“已经完成了”。

如果更改任何内容为时已晚，为什么要进行代码审查？

“已经完成”不是令人满意的答案。完成意味着经过测试并且可以正常工作。每一个没有做任何有用事情的额外代码都应以正确的方式维护（删除）。

再次将任务分配给他，要求重构和优化他的解决方案。如果他不这样做，请给他分配一对程序员，并希望他能从同事那里学到一些东西。

因此，我建议他删除所有不必要的复杂性。我通常得到的答案是“已经完成了”。

这是不可接受的答案：

• 如果更改真的为时已晚，那么代码审查将浪费大量时间，并且管理层需要知道这一点。

• 如果这确实是说“我不想更改”的一种方式，那么您需要采取这样的立场，即代码库的额外复杂性是很糟糕的，因为以后会出现问题/成本。减少将来出现问题的可能性是您首先进行代码审查的真正原因。

还有...

...该解决方案未完全正常运行...

这很可能是不必要的复杂性的直接结果。程序员变得如此复杂，以至于他不再完全理解它，并且/或者他浪费了时间来实现他的复杂性而不是功能点。值得向程序员指出，消除复杂性实际上可以使他更快地进入工作程序。

现在，这听起来好像您没有能力（或信心）“强加”。但是即使如此，还是值得对此稍作改动（不对其进行个性化设置），以期使有问题的编码器在下一次做得更好。

对这种态度有什么适当的回应？

最终，要引起管理层的注意……除非您有能力自行修复。（当然，这不会使您受欢迎。）

你是对的，他们是错的：

• 破坏了YAGNI原则
• 违反了KISS原则
• 代码是否经过全面测试？如果否，则说明未完成

对这种态度有什么适当的回应？

进行正确的代码审查。如果他们拒绝无故实施建议的更改，请停止浪费您的时间来审查代码。您也可以将问题上报给他们的老板。

我们的团队采取的一种措施是采用小得多的变更集，从而在这种情况下大大改善了这种情况，这是该小组采取的一项措施。

与尝试进行一天或一天​​以上的任务而不是进行（大型）代码审查相比，我们尝试进行更多次的签入（每天多达10次）。当然，这也有一些缺点，例如，审阅者需要非常敏感，这会降低其自身的输出（由于频繁的中断）。

优点是，在以错误的方式完成大量工作之前，可以早日发现并解决问题。

您应该关注问题的根本原因：

1. 程序员的教育重点是提高程序员的复杂性。学校对此进行了测试。因此，许多程序员会认为，如果实施简单的解决方案，他们将无法正确完成工作。
2. 如果程序员遵循他上大学时做过的数百遍相同的模式，那就是程序员的思维方式- 复杂性越高，挑战就越大，从而越好。
3. 因此，要解决此问题，与程序员教育中通常需要的相比，您需要严格区分公司相对于复杂性的要求。好的计划是这样的规则，例如“最高的复杂性级别应该只保留给旨在提高您的技能的任务，而不应该在生产代码中使用”。
4. 对于许多程序员而言，不允许他们在重要的生产代码环境中执行最疯狂的设计，将使他们感到惊讶。只需为程序员预留时间来进行实验性设计，然后将所有复杂性保留在栅栏的那一边。

（在代码审查中，现在更改为时已晚）

编写代码后，我不知道任何有效的方法。

在编写代码之前，人们可以讨论其他方法。关键是要相互交流思想，因此希望能选择一个合理的思想。

与承包商合作的另一种方法是固定价格合同。解决方案越简单，程序员保留的资金就越多。

你无法解决这个世界。

您甚至无法修复项目上的所有代码。您可能无法修复项目的开发实践，至少在这个月还没有。

可悲的是，您在代码审查中遇到的事情太普遍了。我曾在几个组织工作过，经常发现自己正在审阅可能在十个代码中编写的100行代码，并且得到的答案与您相同：“它已经编写并经过测试”或“我们正在寻找错误，而不是重新设计。”

这是事实，您的一些同事不能像您一样编程。他们中有些人可能对此很不好。不用担心 补习不好的几门课不会拖垮这个项目。相反，请专注于他们会影响他人的工作部分。单元测试是否足够（如果有）？接口可用吗？有文件记录吗？

如果错误代码的接口还可以，请不必担心，直到必须维护它，然后再重写它。 如果有人抱怨，那就称它为重构。如果他们仍然抱怨，请在更复杂的组织中寻找职位。

项目中应该有一个标准策略来控制可交付使用的质量检查程序和所使用的工具。

人们应该知道他们应该做什么以及该项目中接受了哪些工具。

如果您尚未执行此操作，请整理思路并执行。

代码审查应具有标准项目的检查表。如果您得到“已经完成”但还没有，那么就我个人而言，我不想作为项目经理或高级开发人员来负责此开发人员的工作。不能容忍这种态度。我能理解关于如何做某事甚至每一件事的争论，但是一旦解决方案被接受，就不应容忍撒谎，而应明确说明这一点。

您的商店需要执行一些设计方法。

• 需要明确定义需求。
• 您需要开发支持需求的用例。
• 您需要指定实现用例所需的功能。
• 您需要指定任何非功能性要求（响应时间，可用性等）
• 您需要一个RTM（需求能力矩阵）来将每个系统功能映射回用例和实际需求。
• 删除任何不支持实际需求的功能。
• 最后，在代码审查中标记不直接实现或不支持已定义功能的任何代码。

可能不是因为它太复杂，因为那会使大多数人事后感到难过。我假设发生这种情况时，已经编写了很多代码，而没有一言以蔽之。（为什么会这样呢？因为该人具有足够的权限，所以实际上不必审查其代码？）

否则，我想使代码审查不那么正式，而是更加频繁。在编写大型模块之前，您可能应该快速讨论采用哪种方法。

说“这太复杂”会让您无所适从。

不幸的是，但是代码审查在很多情况下对未来的影响要大于现在。特别是在企业/公司环境中，已交付的代码始终比未交付的代码更有价值。

当然，这取决于代码审查的完成时间。如果这是开发过程的一部分，那么您现在可以获得一些好处。但是，如果将CR视为事后审查，则最好指出将来可以做的更好的事情。就您的情况（正如其他人所说的），总体上指出YAGNI和KISS，以及可能适用这些原则的某些特定领域。

过于复杂意味着什么？您做出模棱两可的陈述，然后您将得到模棱两可/不令人满意的答案。一个人过于复杂的事情对另一个人来说是完美的。

复习的目的是指出特定的问题和错误，而不是说您不喜欢它，这就是“过于复杂”陈述的含义。

如果您发现问题（过于复杂），请说一些更具体的内容，例如：

• 将零件X更改为Y不会简化代码或使其更易于理解吗？
• 我不明白您在X部分中在做什么，我想您正在尝试的就是这。提出一种更清洁的方法。
• 您是如何测试的？你测试了吗？如果过于复杂，通常会导致凝视。然后，当他们不知道如何测试原始代码时，要求进行测试将使他们经常自我简化代码。
• 这里似乎有一个错误，将代码更改为此可以解决问题。

任何人都可以指出问题，尤其是模棱两可的问题。有一个较小的子集可以提供解决方案。您的评论评论应尽可能具体。说某件事过于复杂并不意味着什么，它甚至可能导致其他人认为您因无法理解代码而无能。请记住，大多数开发人员都不了解好设计与坏设计之间的区别。

有时，作为一个团队，专注于某些“敏捷”原则是值得的-他们可以帮助似乎有些偏离路线的团队或个人。

专注并不一定意味着您的团队需要进行大量的重新设计，但您都应该坐下来讨论作为团队最重要的实践。我建议至少讨论这些（可能还有更多）：

• 做最简单的事情可能可行吗？
• 您将不需要它（您正在解决规范中未包含的问题）
• 在编码之前编写测试（帮助您集中代码）
• 不要重复自己

偶尔（每周？）对有效的方法，无效的方法和仍然需要的方法进行审查可能真的很有帮助……如果没有别的，为什么不每周花一个小时讨论团队的价值观和实践？

如果您有一位技术娴熟的经理，请升级。这听起来像是一个需要打破的习惯。

如果代码不是按照规范构建的，那么根据定义，它应该无法通过代码审查。我不明白“好吧，我们做了无人问津的事情，而且没有用，所以我们将它留在那儿，而不是做别人要求做的事情”的概念。

对于任何开发人员来说，这都是一个坏习惯。如果他/她正在按照设计规范进行工作，那么在没有充分理由的情况下不匹配它是不可以。

一句话：敏捷

它当然不能解决所有问题。但是，通过控制迭代（例如1-2周），限制进行中的工作并利用sprint计划/审查，您应该避免出现类似瀑布的错误。您需要更好地了解实际完成的过程-完成过程。

对于基于项目的常规开发，我建议采用Scrum方法。对于连续的开发/集成环境，尤其是如果您有许多开发人员在从事相同或相关项目，请考虑合并看板元素。另一种有效的方法是利用结对编程，这是Extreme编程的已定义实践。

您的情况并非唯一。即使是小型团队，流程也可以帮助您避免目前所处的情况。有了适当的可见性和适当整理的积压后，这些问题便成为了冲刺计划的决策-避免了管理技术债务的麻烦。

过去我曾说过：“此代码很复杂，我对它要执行的操作不自信，有可能简化它还是将其写得更清楚？”

在删除/回滚他们的代码后，您要进行编码：“糟糕，您的代码已经消失了。请重写它。因为您已经编写了一次，因此只需不到20分钟的时间即可提供规范所要求的代码。

“我的下一次审核是在20分钟内。

“美好的一天。”

不接受任何论点！

恕我直言

克里斯