你如何计划每月重构的日子，以消除你的团队中的技术债务？

Question

我的团队在技术债务方面并没有做太多的工作，我们的代码基础包括大量的TODO代码、未使用的代码、“可以得到更好的”代码、@忽略unitests等等。

我要开始处理这些问题了，当我们在生产产品上工作，还有很多其他事情要做的时候，我在想这个策略：

1. 一名工程师将被指派每周0.5至1倍的时间来处理技术债务，他只会在这一天/半天维护代码。由于团队中有超过4x的开发人员(6x开发人员)，每个开发人员每月可以使用一次(甚至更多)。
2. 我们将使用SonarLint (https://www.sonarlint.org/)、CheckStyle和IntelliJ等应用程序(插件)来检查我们的代码库。
3. 每个工程师必须填写一张“技术-债务-战斗”的清单，因为我们将一个模块一个模块地工作：“删除未使用的代码”复选框，“完成1x todo”复选框，....etc。
4. 摘要将在每一天之后填写(用几个词，比如提交摘要)，以便另一个工程师在接下来的一周内能够完成他的工作。
5. 每月一次-两次，我们将回顾工作/谈论这个过程，并设定结束的时间(半年的过程？)

由于这可能是单调/有时无聊/不愉快的工作，我发现使用核对表和‘强迫’团队是一个好主意。我自己也很乐意看一张清单，看看需要做些什么。尤其是这是一个月一次的工作。

你觉得这个计划怎么样？你将如何“攻击”这一技术性债务问题？

此外，我计划阅读更多关于Martin重构笔记的文章。

欢迎任何其他建议！谢谢!

Answer 1

我不会具体地开始重构你没有处理的随机事物，除非它们是非常糟糕的。忽略测试可能是这样的情况，如果这意味着他们正在测试的功能被破坏了。

相反，每当您需要触摸代码时，我都会将代码保持在比您发现的更好的状态。这很容易卖给公司的业务部门，尽管实现特性一开始可能需要更长的时间。它还大大减少了在重构过程中引入新bug的“oopsies”，而不是完全深入到您所接触的功能中。

当然，如果代码未使用，只需将其扔掉即可。你对此有版本控制。

另外，我建议不要在代码中使用TODO，除非您计划在您正在工作的分支中这样做。要么立即进行，要么使用问题跟踪器或其他类似的方法来进行剩余的更改。

这也触及了这样一个事实，即你不应该经常在质量问题上妥协。偶尔也会有一些有效的业务场景，但最终您作为开发人员负责编写好的代码。业务方面推动事情做得更快，这实际上总是存在的，但如果这意味着您经常编写质量差和/或未经测试的代码，这是您自己的责任。

Answer 2

重构工作应该作为常规问题来定义、规划和处理，而不是被视为技术部门的一个大块头，预计会随着时间的推移而消失，因为已经为其预留了一些时间片段。认真对待它，明确你的问题是什么，并把它当作工作。这是工作。

Answer 3

在我减少技术债务的经验中，您需要确保您有良好的代码覆盖率。一次做这件事很难(也很无聊)，即使你留出时间来做这件事。通常，工程师会得到一个任务来解决一个问题或实现一个新的特性。

修复问题

1. 编写在当前(buggy)场景下通过的测试。
2. 编写失败的测试，即它将在修复错误之后通过。
3. 做最少的工作，使测试1失败和测试2通过。没有必要在这里做任何花哨的事情，我们只是想要通过正确的测试。
4. 删除现在应该失败的第一个测试。
5. 现在重构代码是安全的，因为有一些测试支持业务逻辑。坚实的原则在这里是有帮助的。
6. 现在你也可以重构测试了。

实现新代码

1. 在某些情况下，工程师首先需要围绕受新特性影响的代码编写传递测试。
2. 为新特性编写失败的测试，该测试将在实现新功能之后通过。
3. 做最少的工作，让测试通过。
4. 现在重构代码。坚实的原则在这里是有帮助的。
5. 现在也重构测试。

当它第一次实现时，代码看起来会很完美。以后(也许再过几个月)它就不会那么漂亮了。如果已经有合适的测试，那么重构代码以适应新的代码环境是简单而安全的。这是控制技术债务的重要一步。

Martin的重构笔记是一个很好的起点。