系统思维

Source: Hacker News

两种软件开发思路

1. 演进（增量）开发 – 从小开始，随着时间添加功能，让系统有机成长。
2. 前期大规模（工程）设计 – 在编写任何代码之前，编写捕获所有复杂性的完整规范。

简而言之，这就像企业家创建初创公司与我们建造现代摩天大楼的区别：演进 vs. 工程。

Source: …

实际案例

我曾在一家大型企业工作，该企业拥有 > 3,000 台活跃系统，覆盖数十条业务线和所有内部部门。

• 该系统环境已经发展了 ~50 年。
• 它包含了众多技术栈、无数供应商，以及由传统和现代应用拼凑而成的体系。
• 若把它视为一个整体，就像一座 摇摇欲坠的纸牌屋。

如果系统更少、更大怎么办？

• 数据、安保、运营、质量和访问 的不一致性将大幅缩减。
• 现在的“最新、陈旧、运行良好、几乎不可用”系统的混杂将被更统一的平台所取代。
• 整体复杂度可能降至当前水平的 ≈ 10 %，而不仅仅是减半。

由此带来的好处

• 更好的性能和可靠性
• 更强的变更韧性
• 成本更低，所需人员更少
• 消除许多当下存在的“丑陋”问题

核心问题：依赖

如果你拥有数千个独立的块，可以直接“砍掉”每一个。实际上，真正独立的组件寥寥无几，这使得随着系统规模扩大，进化式路径变得风险更大。

为什么前期大设计会停滞

1. 缺乏知识 – 基础（技术栈、框架、库）发展迅速，几乎没有通用的最佳实践。
2. 职业路径短 – 大多数应用程序员的深度经验 ≤ 5 年；拥有“20 年以上”经验的资深工程师很少。
3. 复杂性吓人 – 初学者常觉得自己没有准备好去处理庞大且相互依赖的设计。

个人偏好与现实检视

进化式项目

优点

• 更有趣，会议更少，能够立即动手实践。
• 前期协调需求更少；你可以“直接投入工作”。

缺点

• 随着代码库规模扩大，偏离轨道的风险上升。
• 系统未按预期运行时，后期会出现慌乱。
• 长期不满感，意识到自己是把问题添了进去而不是解决它。

大前期设计

优点

• 起步较慢，但整体开发流程更顺畅。
• 便于有意识地关注细节、复用以及架构的一致性。
• 长期来看能降低压力；你有时间把事情 做好。

缺点

• 感觉上有摩擦：会议多、协调繁重、早期进展缓慢。

注意： 对于大型前期项目会产出错误产品的担忧往往被 夸大。在需求成熟且明确的业务领域，扎实的规格说明实际上可以 降低 风险。

结论

• Evolutionary development 在小型、快速推进的项目中表现良好，尤其是问题空间变化多端时。
• Big‑up‑front engineering 在领域稳定、隐藏依赖成本高且组织能够承担前期协调时表现出色。

选择合适的方法取决于 问题的本质、团队的成熟度以及对长期技术债务的容忍度。

重构原始工作并解决其不足

应该在中间有一条平衡的路径，但在这些十年里我仍未找到其正式版本。

我们可以先从依赖关系入手，然后解释为什么它们可以暂时被忽略。你可以在保持模糊的长期设计思路的同时，演进下一个版本。随着新的、意料之外的依赖出现，你可以相应地重构设计。一次又一次地改变想法，努力让演进中的工作趋向一个稳固的宏大设计。

• 快速开始，放慢脚步，再次加速，如此循环。
• 目标是构建一个单一、完整的系统，最终能够“统治一切”，即使实现它需要一段时间。

迭代规模很重要

每次迭代的规模至关重要：

• 极小的迭代 常常意味着盲目摸索前进。
• 较长的迭代（当你不再盲目摸索时） 更加有效。

迭代不必保持统一，但每完成一次都应该停下来进行评估。

• 编码速度越快，所需的清理工作就越多。
• 推迟清理会使问题呈指数级增长。
• 不受约束地向前推进会把工作环境变成沼泽，最终导致停滞。

这一原则适用于构建任何东西——从软件系统到餐厅烹饪。速度始终是一种权衡。

平衡演进与工程

• 演进 有助于避免在工程上陷入僵局，但工程确保产品能够实现其预期功能。
• 工程进展缓慢；失控的演进更为缓慢。
• 演进是动态且混沌的；你必须不断识别何时走上了错误的道路并回溯，这往往难以承认。

对大多数系统而言：

1. 工程化部分——必须经过精心设计和验证的组件。
2. 演进部分——可以让其有机变化的章节。

演进路径越随机，你需要丢弃并重新做的工作就越多。摇摆不定始终代价高昂。自然通过拥有数百万种物种来应对，但我们通常只有一个开发项目——因此风险更高，过程也不那么便利。