安排定期清理代码是个好主意吗？[关闭]

我正在管理一个小的开发人员团队。我们经常决定要花一两天的时间来清理代码。

安排定期的时间（例如每2个月1周）来清理我们的代码库是个好主意吗？

没有。

在处理它时对其进行修复：

• 如果您等待重构工作量，就会忘记很多事情，而不得不花时间再次熟悉它。
• 您将不会得到“镀金”代码，该代码由于需求发生变化而永远不会被使用

我个人的观点：90％的项目都是绝对需要的。

特别是对于那些受销售驱动的项目，通常会大力推动每个版本中都包含新功能，并且您不可避免地最终不得不妥协更好的直觉，并在此四处引入一些弊端。

最终，通过这些小小的折衷，您已经累积了足够的“技术债务”，您最终不得不花大量时间来解决代码库中的缺陷，而无法充分利用它的全部潜力。

通常，以这种方式生成两种类型的问题：

• 小型变量很容易修复，但可能是系统性的，例如参数命名不正确，错误处理不完整等。它们通常不会对它们所在的代码块产生什么影响。处理这些问题的最佳方法是代码审查，并在编写/修改代码时对其进行检查。正如其他人所指出的那样，无需预留一个特殊的重构周期来修复这些错误。
• 较大的问题可能是由于规格不完整或早期的设计决策不当，或者两个开发人员/团队针对同一问题创建了两种不同的解决方案。这些通常很难修复，需要齐心协力进行修复。结果，它们通常被推迟，直到成为永久的麻烦为止。这类问题需要花费一定的时间来解决。

我通常会尝试每3到4个周期为纯重构/错误修复周期保留时间。我总是要求开发人员在对代码库感到沮丧时告诉我。并非每个开发人员都需要进行清理工作-您通常（但并非总是）使团队有些混乱，因此在任何给定时间只有一个团队在进行清理。

在签入（Subversion）或与主开发分支（Git）合并之前，我让我的开发人员整理代码。

我让他们执行以下操作：

• 删除不相关的评论
• 确保适当地命名其方法，参数和变量
• 确保它们的类有结构，并且将项目封装为应有的样子
• 重构以提高可读性并减少任何代码异味

对于较大的项目，在从开发分支合并到主分支之前，将对代码进行正式审查。

我认为“投入时间”将意味着它可能会被推迟或由于涉及的工作量而推迟。通过让开发人员在每个签入中进行操作（相当于JIRA中的变更请求/问题），则可管理性大大提高。

我认为不是。如果您在遇到技术债务与解决技术债务之间花费了太多时间，那么您将失去问题根源。需要花费更长的时间来修复，而且往往更糟。最重要的是，人们离开了破碎的窗户，因为它不是“清理一周”。

就个人而言，如果我知道我们之前在冲刺中创建了一些冲刺，那么我会为每个冲刺进行技术债务清理谈判。它使债务保持在人们的脑海中。它限制了使用问题代码的代码数量，因此重构更加容易。它可以防止技术债务堆积。而且它可以帮助开发人员避免将某物拍打在一起，因为我只是要让他们在下一个冲刺时做（所以最好一开始就做）。

我肯定会说，但附带条件：应该经常进行，最好每周进行一次。我相信，定期进行定期代码审查，再加上实际对代码审查产生的项目采取行动，将会很快获得回报。查看pswg的答案

每2个月1周绝对不够频繁。这可以与其他大多数回答“否”的人说。这些答案中的大多数的要点是，如果等待时间太长，您将不再与代码保持联系，并且通常需要更长的时间来修复/清理/重构。

尚不清楚您是否需要偶尔进行一次额外的代码清理练习。从这个意义上讲，是的。无论我们遵循什么实践，总会发生一些退化。

首先，您不应以此为借口不做正确的事情[应用SOLID原则，相关的单元测试，检查等]。

我认为当前两个流行的“否”，“是”答案是同一真相的两个方面。记住，OP是在谈论他所管理的团队，而不仅仅是他个人。我们不能认为该小组中的所有开发人员都具有足够的纪律性，可以编写干净，易于阅读的代码。还有外部压力和敏捷风格方法论的问题。同样，即使人们尽了最大的努力，他们在风格上的差异也意味着他们可能会编写分开时被认为是干净的代码，而与其他人一起考虑时则是不干净的代码（更不用说笨拙的界面了）。

另一方面，在我看来，“在解决它的同时修复它”是一个理想的追求。您可以通过以下方式使代码更加“固定”：

• 仔细的对等CR
• 编写单元测试以及代码本身
• 采用编码准则
• 使用自动格式化程序和lint（但使用YMMV）
• 等等

现在，如果OP的团队采用了上述方法，并且如果他鼓励下属（例如在代码审查期间和定期的代码清理会话期间）尝试预见陷阱并提前避免丑陋，那么随着时间的推移，他/他们将希望减少清理时间。（然后，他们可以将这段时间投入到文档，更深入的重构以及他们所编写和合并的内容的知识共享中。）

我认为安排常规时间非常好，无论是常规瀑布式项目中的任务，还是敏捷项目中的故事。设定时间可能不如将其用于计划中那样有价值。这使您可以将其作为计划的一部分完成，而不必取消清理日，因为您在项目上落后了。

在管理了一个拥有大量代码债务的项目之后，定期进行这些工作对于使工作顺利进行至关重要。我们有些东西很大，有些东西很小。

经过几个月的工作，我们的运营团队领导告诉了我一切运行得如何顺利。

每个项目看起来似乎并不多，但就像所有债务一样，它会广告化。

理想的答案是“否”，因为您采取了必要的步骤来避免使它成为必需（由于前面已经提到的几个原因，请进行清理）。

这最终可能是目标，但您可能拥有一支远未付诸实践的团队。

经理必须承担一些责任这并不总是开发人员的错。经理可以说一件事，但是他们开始推动项目完成并提出促进不良做法的建议。他们可能从字面上说：“我们稍后再清理”，或者如果可行，那就足够了。

您可能必须先指定一个特定的时间来证明这一点很重要。一旦知道您的团队有能力清理他们的代码（不是给定的），就可以尝试更频繁地合并它。

最终，您不必设置时间。

就个人而言，我努力解决一个新问题并使它工作，同时努力使事情保持整洁。我在这方面做得更好，但经常会故意休息一下并清理一下。对我来说这是一种不同的心态。最终，扎实的习惯成为习惯。

不，您应该在编码时执行此操作。如果使用的是TDD，这称为重构。当您等待一两个月来修复和清理代码时，问题在于您可能会更改代码的行为，因为您不会记住每段代码。

我建议进行重构，该重构基于首先对必要的代码进行编码以使某项工作正常进行，并在工作完成后立即对其进行重新设计，优化并使其美观。