等待需求时对草率代码进行低影响的重构和代码清理

我继承了一个草率的产品的现有代码库。基本设计严重不足，不幸的是，如果没有完整的重构，我将无能为力（高耦合，低内聚，猖ramp的代码重复，没有技术设计文档，集成测试而不是单元测试）。该产品具有悠久的历史，对关键的“现金牛”客户敞口高，对风险的承受力最小，将使希腊人脸红的技术债务，非常庞大的代码库和复杂性，以及之前团队疲于奔命的错误解决方法我。

老团队跳船到另一个部门，以便他们有机会毁掉另一个项目。我很少遇到技术上无能力的项目失败，而不是项目管理失败，但这确实是其中一种。

就目前而言，我自己一个人，但我有很多时间，决定权和未来方向的自由，并且有能力从头开始建立团队来帮助我。

我的问题是，当您在功能需求收集阶段有一些空闲时间时，就对这样的项目的低影响重构收集意见。有成千上万的编译器警告，几乎所有警告都未使用的导入，未读的局部变量，没有类型检查和不安全的强制转换。代码格式是如此的难以理解和草率，以至于编码人员患有帕金森氏病，无法控制在任何给定行上按下空格键的次数。通常会打开其他数据库和文件资源，并且永远不会安全关闭它们。无意义的方法参数，执行相同操作的重复方法等。

在等待下一个功能的要求时，我一直在清理低冲击力，低风险的物品，并想知道自己是在浪费时间还是在做正确的事情。如果新功能意味着删除我之前花费时间的代码怎么办？我将开始一种敏捷方法，并且我知道这在敏捷开发过程中不断重构是可以接受和正常的。

您能想到我要添加的任何正面或负面影响吗？

首先，我想指出，单元测试不能代替集成测试。两者需要并存。非常感谢您进行了集成测试，否则，您的一小笔重构就很可能使低容忍度的摇钱树对您产生冲击。

我将开始处理编译器警告以及未使用的变量和导入。首先获得干净的版本。然后开始编写单元测试以记录当前的行为，然后开始实际的重构。

我看不到任何负面影响。您将对代码库有很多深入的了解，这将有助于进行更大的重构。与重构相比，重构几乎总是更可取，因为在重构过程中您仍然可以使用产品，而在重写过程中却没有。最后，产品销售必须支付您的薪水。

需求开始出现后，我将使用所谓的“聚焦”方法。进行通常的敏捷操作（优先级设置，然后切掉一块小板进行迭代，然后进行迭代），并留出大量时间进行代码改进。然后重构您在哪里工作。随着时间的流逝，这将涵盖代码库的广泛领域，而您又不必冒险进入难以向管理层证明为什么要对代码的那部分进行工作的领域。

编写单元测试可能会更有价值地利用您的时间：它将使您对代码库的当前工作有一些见解，并且如果您决定从现有内容开始而不是从头开始重写所有内容，那么您将拥有坚实的基础在不承担太大风险的情况下进行更改。可能的是，在编写单元测试时，您也将对代码库进行更改，以使其处于可测试的状态。这些都是好事，因为可单元测试通常也意味着模块化，封装化并且基本上独立于外部状态。而且，最重要的是，编写良好的单元测试是宝贵的技术文档。有了单元测试，您将能够判断当前代码库可以做什么和不能做什么，而不是进行大胆的猜测或重写以防万一。

混合答案-我的想法是混合测试和清理-也许50/50？如果您在工作区域中采用TDD方式-设置测试，则需要知道单元测试和集成测试是否符合要求，然后开始修复。在时间允许的情况下继续前进。

这可能意味着您不会取得太大的进步，但这意味着至少在某些方面您将拥有一个非常稳定的代码库，并且您将拥有一个良好的入门库。

我最初的直觉是“清理损坏的代码真的很痛吗？” （又称编译器错误），但后来我想起了在某些真正奇怪的情况下解决问题实际上破坏了功能的时间，因为它没有在内存中死掉，而是将内存留在了不好的地方-本质上来说，不好的休息掩盖了更严重的错误。从字面上看，这可能是潘多拉盒子带来的不愉快惊喜。

考虑到您在等待更多需求时正在执行此操作，我认为您可以诊断出混乱的任何事情都会大大增加您的长期理智。