什么是盖尔定律？

适用于软件开发人员的盖尔定律（Gall's Law，也称为加尔定律）

盖尔定律是对复杂系统的性质和演变的观察。这一原则在软件开发和系统架构领域引起了深刻共鸣。约翰-盖尔（John Gall）在其著作《系统论》（Systemantics：系统如何真正工作以及如何失败》一书中提出了这一原则，此后在许多关于系统设计和软件开发的讨论中都引用了这一原则。

"一个复杂而有效的系统，总是从一个简单而有效的系统演化而来。从零开始设计的复杂系统永远无法运行，也无法修修补补使其运行。你必须从一个有效的简单系统重新开始"。- 约翰-盖尔

一个寓言：失败的数字城市
很久很久以前，在一个名为 "数字城市 "的新兴科技城市，市议会决定创建一个全方位的数字平台，整合所有公共服务--交通、公用事业、医疗保健、教育等。他们设想未来的智能城市将从第一天起就实现万物互联。

他们聘请了最好的工程师，并为该项目投入了数百万美元。蓝图错综复杂，相互依存。团队兴奋不已，但又不知所措，因为每个模块都依赖于另一个模块。开发工作进行了两年，成本不断增加，服务的相互关联性导致复杂的错误层出不穷，很明显，项目濒临失败。

最后，市政府不得不放弃该项目。虽然无法实现完整平台的愿景，但他们希望在项目失败后能恢复一些小的功能。不过，即使是这样也很困难，因为几乎没有额外的预算，而且每个组件都高度依赖于其他组件和 "系统"。

如果他们一开始只提供一项服务，例如交通服务，并在整合下一项服务之前使其完美运行，那么他们就可以在连续成功的基础上再接再厉。相反，他们却拥有了一个庞大、昂贵、最终无法运行的系统。

回想起这个故事，教训是显而易见的：从简单做起，使其发挥作用，然后再接再厉。

分解与解读
从简单开始：这种理念认为，我们应该从能够实现主要目标的最简单的系统版本开始。在软件领域，这通常与最小可行产品（MVP）方法一致。借用肯特-贝克（Kent Beck）的名言："让它工作，让它正确，让它快速"。第一步是尽可能让最简单的版本发挥作用。

进化和扩展：一旦有了一个能正常工作的简单系统，就可以将其扩展和演化成一个更复杂的系统。这种逐步增加复杂性的方法更易于管理，开发人员也可以在工作系统的背景下测试和验证每个新功能或组件。肯特-贝克（Kent Beck）的名言 "做对，做快 "就是从这里开始的。在实践中，只有当你有理由相信它还不够快时，你才需要担心如何让它更快。

避免过度工程化：从一开始就设计一个高度复杂的系统，往往会导致不可预见的问题和并发症。这会造成时间和资源的浪费，并可能导致系统无法完全达到预期目标。

在软件开发中的应用
敏捷和迭代开发：敏捷方法强调迭代开发，在短周期内交付小块功能。这种方法与盖尔定律不谋而合，因为它提倡从简单的工作系统开始，并随着时间的推移不断发展。

重构：一旦简单的解决方案就位并开始运行，开发人员就可以重构和改进代码库，确保系统在复杂性不断增加的同时仍具有可维护性。可重复测试是正确重构的先决条件，可确保系统安全发展，而不会有引入回归的风险。

模块化单体：与其直接进入微服务，不如设计一个模块化的单体。这样可以在单个代码库中实现清晰的边界和关注点分离。如果需要，它还能使向微服务的潜在过渡更加顺畅。

微服务架构：将大型、复杂的应用程序分解成更小、更简单的服务（或微服务），可以让每个服务独立发展。这种模块化方法可以带来更强大、可扩展的系统，但代价是复杂性大大增加。

对软件团队的影响
风险管理：通过简单起步和迭代，团队可以降低与软件项目相关的风险。如果某种方法或技术不奏效，在系统还相对简单的情况下，更容易进行调整。

改善协作：注重简单性可以促进团队成员之间更好的沟通。在更简单的系统上更容易讨论、理解和协作。

客户反馈：尽早发布软件的简单工作版本可以从最终用户那里获得宝贵的反馈意见，从而引导系统朝着满足实际需求的方向发展。正如阿尔达利斯喜欢说的那样："作为软件开发人员，我们有两种失败的方式：我们把事情做错了，或者我们把事情做错了"。尽早获得客户反馈有助于确保开发人员不会构建错误的东西，而构建错误的东西往往比构建正确的东西更昂贵。

总结
盖尔定律为软件开发人员和架构师提供了宝贵的见解。通过理解和应用这一原则，团队可以创建更加成功、稳健和可扩展的系统。