为什么要不断重构

始终保持高质量的代码库

对于软件开发人员来说，维护良好的代码库是他们自己的回报，例如个人的Monalisa或禅宗花园。 工作很愉快，很容易上手并易于理解，拥有这种独角兽的团队通常可能会更有生产力。

使每个人都熟悉代码

软件永远不会"完成"，因此重要的是要保持最新的"最新"形式以有效地使用它。 如果团队中的每个人都在代码库中四处寻找改进的机会，那么很可能有一个以上的人看到了它的晦涩之处，并且可以在该部分发生问题时提供帮助。 这对于已经建立了很长时间并且看到多个团队成员来去去去的大型代码库尤其重要。 重构和随时待命是我可以想到的两个最强大的工具，可以在所有团队成员中传播有关代码各个方面的广泛知识。

建立下一代架构

每个人都希望微服务对吗？ 如果您背负着泥泞不堪的巨石，那么您很可能迫不及待想要将其分解。 但是如何安全地做到这一点？ 大型，毛茸茸的野兽带有触角，您甚至可能都不知道。 谁知道分解模块会做什么？ 实际的划分很简单，这是我们必须要警惕的无法预测的结果，我们不希望最终出现分散的泥泞球！

有一种确定的方法可以设置它-开始重构此旧代码库。 您将学到一些您不知道的代码，以前会出现混乱的边界，各个部分之间的依存关系将变得更加清晰，错误将被发现和消除，性能将得到改善。 您将比往前更深入地了解去往何处。 谁知道呢，也许到此为止，您将不希望使用微服务，因为您将拥有一个很棒的超高效整体。

最重要的是，企业将继续保持这一切！

即使我们正在使用新代码，连续重构也显示出代码中正在出现的边界和行为，而这种洞察力使更大的体系结构更改成功的可能性更大，因为我们并不需要" this-sucks-lets- 重写一切"的心态，但源于解决实际业务问题的代码库中出现的实际迹象。 经验丰富的开发人员通常可以确定这些模式，并组建团队进行有力的更改（例如，将该模块拆分为单独的服务，让断路器放入中央客户端库中）。 当团队中的每个人都在进行重构时，越来越多的人开始获得感知即将到来的变化的第六种感觉。

如何持续重构

有许多方法可以做到这一点，并在互联网上提供大量建议。 我想集中在两个方面，一是技术方面，一是组织方面。

编写测试

经常重复的建议经常被忽略的辅助手段是-编写测试。 重构并不存在某种技术真空中，而是一种实现组织目标的手段。 我对此有不同的看法，但对我来说，目标是提高运输速度。 我们今天所做的应该使未来的更改更快/更容易/更安全。 现在，如果我们同意今天的重构可以促进未来的变化，那么拥有可测试的代码就可以促进重构。 我们不必只考虑更改代码，也可以考虑添加测试。 我们可能不进行重构，但是由于进行了额外的测试，因此其他任何人明天都可以安全地进行重构。

写作测试就是重构

如何抽出时间

"我们永远不会有时间"。 我同意，这是可悲但真实的。 获得排他的重构时间需要很多信任，尤其是在那些实际上没有破坏（但可以改进）的代码部分。

我更喜欢广泛使用的"缓冲您的估计"方法。 要求额外的一天来完成任务。 无论如何，重构您要修改的内容都比较容易，利益相关者抱怨一两天的估算值的可能性较小，而且我们将能够不断地减少成本。 这比分别为"仅技术"更改分配时间要容易得多。

这样做还限制了我们将花费多少时间进行重构-它将使情况变得更好，但仅在资金来源的给定业务功能范围内。 在这种情况下，我们沸腾海洋的可能性要小得多，因为有一个更大的目标要实现-您仅重构当前正在使用的内容。

通过连续重构节省一天的时间
您之前是否遇到过这种情况？

1. · 开发团队不断缩短功能交付的截止日期
2. · 它通过发送负债累累的代码来回应
3. · 这种技术债务永远都无法偿还，因为永远没有时间清理
4. · 转到1几次
5. · 直到真正开始阻止新的变化或破坏生产中的技术债务，情况才会恶化
6. · 开发人员团队需要进行重大的重新设计，因为当前系统已无法节省成本
7. · 这将花费很多时间，但是业务团队将最终获得与魔术无异的技术保证
8. · 通过搁置其他所有内容来执行重新架构
9. · 它花费的时间比想象的要长得多，而产生的效果却差得多
10. · 转到1几次
11. · 业务团队对开发团队失去了全部信心，并返回使用excel / Company关闭

不幸的是，上述事件序列太普遍了。 尽管有很多原因和许多相应的措施可以防止这种情况，但我想看看开发团队可以做什么。 对我来说最大的问题是反复进行大的重新架构。 像初创公司一样，大型重新设计大多会失败。 他们无法控制范围，无法兑现承诺，无法提升组织的能力，甚至往往根本无法完善。 一个真正敏捷的组织如果发现自己需要如此大的一次性更改，应该感到惊讶-无论是逐步发现和实施解决方案时发生了什么！

但是，开发团队可以采取一些措施来防止这种情况的发生，那就是采用一种持续重构的文化。 除了冲刺，混乱或日常站立之外，连续重构还可以通过改善开发人员的工作方式（即代码库）使开发团队变得敏捷。

马丁·福勒（Martin Fowler）写了一本很棒的书，写了许多有关重构的文章（包括关于词源的有趣的注释），所以我想我们都知道它是什么。 让我们跳入为何我建议"连续"重构的原因。

结论

在我看来，期望团队"显然"会进行连续重构是不公平的。 这并不明显，面对交付功能的压力，它很少成为优先事项。 它是一种文化，与所有文化一样，应该明确地谈论，讨论和鼓励。 如果我们能以使事情每天都变得更好的方式来解释我们的工作，那么收益的累积就会非常快。