大型软件系统中的熵

Question

我在一个相当大的软件系统上工作，多年来它积累了大量的熵。重构有很大的空间，但是总是有压力在已经存在的特性上构建下一个特性。这增加了更多的熵，因为实现新特性的设计选择通常是通过首先接受存在的内容并“工作”--一些早期的较弱的设计，否则重构就已经成熟了。

有什么方法可以在不进一步削弱系统结构的情况下管理这种复杂性和构建功能。我知道这是一个非常广泛的问题，方法/解决方案取决于手头的特定软件系统，但我仍然希望有一些通用的方法来管理我正在强调的问题。

Answer 1

您需要应用关注点分离原则，以便将系统划分为仅通过定义良好的接口相互通信的模块。由于许多原因，这大大降低了复杂性：

• 有些人可以在不了解其他部分的情况下完成项目的一部分工作；
• 您可以轻松地通过添加另一个模块来改进系统；
• 松散耦合-模块仅通过接口连接；
• 高内聚力-来自模块的数据几乎用于该模块的所有部分。

Answer 2

你不能这样做，正如你已经认识到的那样，建立在薄弱基础上的每一个新特性都会使这个特性变得更弱，延续这个循环。

您需要做的是花时间重构事物，至少不需要对新功能进行黑客攻击。也许这意味着，在技术债务和/或维护成本方面，管理层会心不在焉。也许这意味着有很高的估计，以确保你有时间做正确的事情。也许这意味着对你的手艺感到自豪，花时间做好它，即使它没有完成‘准时’。

但是你才是编写代码的人--所以你才是要修复它的人。你如何做到这一点会因地制宜。

Answer 3

啊是的这个问题。

你必须做的第一件事是让管理层接受软件需要进化的想法(我的术语)。这里的想法是，而不是一个固定的设计和改变的需求，你必须让他们的想法，修改设计的想法，随着需求的变化。否则，你总是以无法维持的可怕的系统结束。

第二件事(一旦你有了管理人员)是，你必须得到程序员的承诺，把合同和实现分开。然后，您必须愿意编写针对契约的单元测试，而不是针对实现。

现在，如果这是一个大规模的系统(听起来像是一个)，那么下一个阶段实际上就是构建一个新的框架。新代码在新框架上运行，最终旧框架将被淘汰。您应该这样做，使您可以保留旧的合同(与外部应用程序)在新的框架中，尽可能长时间。

从这里开始，解决方案就是我所说的“用链锯重构”，并从旧框架中删除定义良好的功能块，并将其移到新框架中。在一个大规模的系统中，这可能需要数年的时间才能超越一切。

现在，如果您在契约上进行了单元测试，那么您可以在执行过程中重构您自己的实现，而不必担心破坏问题。