那些不记得过去的人注定要重蹈覆辙

— 乔治·桑塔亚纳

不良编程实践的正当理由通常源于通过个人经验来合理化自己的行为。在最初的架构决策和实施很久之后,问题开始显现出来。由于难以修改系统的实现和体系结构,任务通常应该很小,但最终会成为大任务。

花费巨大的代价,课程经常被重新发明或根本没有引导。这通常会在个人和团队中造成认知失调的情况:他们认为自己是有能力或优秀的开发人员,但他们并没有吸取过去的教训。

在过去的几十年里,在应用程序耦合方面已经吸取了一些教训,但很少有人比那些学习静态方法](https://martinfowler.com/bliki/StaticSubstitution.html)的[更懒散地违反了。那些不负责这些课程的人基本上使用静态方法作为类命名空间函数,可以在任何地方在整个应用程序中使用。

在某些方面,以这种方式编程可能更容易,因为它通常本质上是程序性的,并且类似于在一个人的编程生涯早期学习的东西(功能)。因此,它们的使用通常需要较低水平的技能。但是,它们紧密耦合应用程序并使其几乎完全不可测试,因为依赖项没有显式声明,并且可以在任何地方在任何地方使用。

因此,如果您想用可维护性来降低构建应用程序所需的技能,那么它可能是您的选择。但是,这样做会增加大量技术债务。 “走得快只有走好”,这是一个众所周知的原则。因此,您应该仅使用静态来声明真正的全局常量(请注意,不是全局变量)并协助创建对象。其他任何事情通常都是自找麻烦。

然而,耦合的教训不仅在实现混凝土时经常被遗忘,而且在构建应用程序和系统时也会在概念上被遗忘。早在九十年代初,四人帮 (GoF) 就撰写了权威书籍Design Patterns。他们在其中声明_“紧密耦合导致单片系统”_。关于人性,尤其是开发人员,我们了解的一件事是,他们往往是时尚主义者:他们追逐任何看起来最酷或最闪亮的东西。事实上,这发生在面向服务的架构(SOA)出现时。团队不加选择地重新构建他们的应用程序,以便他们的边界被网络分隔,表面上是为了避免单一架构。然而,他们没有考虑真正使某些单体应用程序无法维护的原因——紧密耦合。

许多人没有看到的是,真正的问题是缺乏层次或真正的边界。 GoF 之后的 20 年,Robert C. Martin 在他的书Clean Architecture中指出,“微服务仍然可以通过共享资源 [或] 通过它们共享的数据耦合 [彼此]。 "此外,Martin 表示,这种架构决策应该尽可能地延迟,因为微服务本身并没有定义架构。微服务不能解决耦合问题——好的面向对象设计可以。

微服务只是众多解耦策略之一(以及面向对象的技术、包等),尽管它是最难和最明确的边界。 Martin Fowler 在他的著作 企业应用程序架构模式 中劝告他的读者 “尽可能限制您的分布边界,因为它们很昂贵”。微服务是一种架构决策,Martin 认为应该尽可能地延迟,并且仅在您彻底质疑这种方式的解耦时才使用。否则,“简单地分离应用程序行为的服务只不过是昂贵的函数调用”(Martin)。

最后,另一个无视经验、愚蠢的过度依赖和无视耦合危险的案例是对框架的迷恋。框架通常用作定义应用程序的高级架构。根据Martin 最近的一些著作,框架的高级目录结构和架构不能传达应用程序的意图,他认为应用程序的架构应该以用例为中心。

架构不是(或不应该)与框架有关。架构不应由框架提供。框架是要使用的工具,而不是要遵循的架构。如果您的架构基于框架,那么它不能基于您的用例。

虽然不通过其高级目录结构传达应用程序的意图本身可能不是完全错误的,但错误在于与框架的实用程序和结构类的紧密耦合。这样做会降低您的应用程序的可测试性、可移植性和灵活性。然而,这种思路并不新鲜。它主要是对现有原则的重新散列。在 Martin 撰写关于应用程序架构的性质及其与框架的关系(或缺乏关系)的论文之前的二十多年,四人组建议他们的读者警惕与框架的耦合。

应用程序依赖于框架,因此它们对框架接口的变化特别敏感。因此,应用程序应该只松散耦合到框架。

迟早,旧的一切都会再次成为新的。然而,是旧的是新的还是我们忘记了过去的教训?

要构建出色的应用程序和团队,您不仅需要研究过去,还需要应用从此类研究中学到的原则。如果您考虑忽略过去的教训,尤其是那些经过深思熟虑的面向对象的架构原则和行业最佳实践,您最好问问自己为什么并默认假设您错了。