文章讨论了软件开发中构建复杂系统的两种主要思路：一种是逐步演进式开发，从小规模开始不断添加；另一种是预先制定完整规范，一次性构建。作者以创业公司和大厦建设为例对比这两种方式，并分享了自己在大型企业观察到的由3000多个系统组成的庞杂技术架构，这些系统经过50年演化形成，包含多种技术栈和供应商。

系统思维：软件开发中的两种方法论

在大型复杂软件开发中，存在两种主要思想流派：

1. 渐进式演进：

   • 从简单开始，逐步增加复杂度。
   • 类似创业公司的灵活迭代方式。
   • 优势：启动快，短期效率高，适合依赖关系较少的场景。
   • 劣势：长期可能导致系统碎片化，依赖问题积压，后期修复成本高昂。

2. 预先全面设计：

   • 提前制定完整规范，一次性解决所有复杂度。
   • 类似现代摩天大楼的工程化建造。
   • 优势：系统更稳定、一致，长期维护成本低。
   • 劣势：初期进度慢，需团队高度协作。

现实案例与问题

作者曾观察到一家大型企业拥有3000多个独立系统，历经50年演变，导致数据、安全、运维等方面严重不一致。若能整合为少数核心系统，复杂度可能降至十分之一，同时提升可靠性和可维护性。

核心挑战：依赖关系

• 演进式开发：暂时忽略依赖，后期再处理，但可能引发“技术债”螺旋。
• 预先设计：需提前理清所有依赖，对团队协作要求高，但能避免后期混乱。

实践中的障碍

• 技术快速变化：缺乏稳定最佳实践，经验不足的开发者（多数仅5年以下经验）难以驾驭大规模设计。
• 人性偏好：演进式开发更“有趣”，会议少、自由度高；而大设计常伴随冗长讨论，易因团队经验不足陷入低效。

平衡之道

作者提出折中思路：
- 以长期大设计为目标，允许短期迭代演进。
- 动态调整迭代周期，定期复盘清理技术债。
- 根据系统模块特性，混合使用两种方法（核心部分工程化，外围灵活演进）。

最终观点

• 演进避免工程僵化，但可能导致失控；工程化确保系统可靠性，但需忍受初期缓慢。
• 理想路径是承认两者的互补性，而非非此即彼。

（注：原文中的博客导航、时间线等非核心内容已省略，聚焦于方法论讨论。）

评论内容总结

支持渐进式开发（Evolution）的观点

1. 需求随时间变化：系统需求会随时间漂移，预先设计难以应对变化。

   • "A major factor supporting evolution over big up-front design is the drift in system requirements over time."（评论1）
   • "A complex system that works is invariably found to have evolved from a simple system that worked."（评论2，引用Gall定律）

2. 软件的可塑性：软件像黏土一样可塑，无法像建筑一样固定设计。

   • "Software cannot be built like skyscrapers because... it can be shaped to something else."（评论3）
   • "making changes is often cheaper... we might not know beforehand everything that is needed."（评论15）

3. 实践验证：复杂系统通常是从简单系统逐步演进而成。

   • "Show me an example of a large complex software system built from spec rather than evolved."（评论6）
   • "There is no other way. You try things and then compress later."（评论13）

支持预先设计（Engineering）的观点

1. 规范的价值：好的规范能提高效率，尤其在AI辅助下。

   • "Specifications could be versioned... easier to read, reason about, and iterate on."（评论5）
   • "A good plan helps you prevent changing specs and prepares you for hiccups."（评论17）

2. 工程方法的优势：适用于需求明确且稳定的场景。

   • "Engineering is the superior approach... whose end result was complete."（评论4）
   • "the plan is cheaper than the build... helps you determine how off the rails you’ve gone."（评论17）

中间立场

1. 平衡与情境依赖：应根据需求变化的可预测性选择方法。

   • "The balanced path depends on how much of the requirements... are going to change."（评论7）
   • "This is not a binary question... a spectrum between two extremes."（评论9）

2. 混合策略：结合规范与迭代，如“绞杀者模式”。

   • "Strangler fig pattern is probably the pragmatic approach... deliver something that works and adds value."（评论11）

其他观点

• 规范与代码的反馈差异：规范无法像代码一样即时反馈问题。
  • "the spec doesn’t talk back the way actual working code does."（评论8）
• 标题误导：内容与“系统思考”无关（评论10）。
• 现实关联性：质疑讨论是否脱离实际（评论12）。

关键引用保留

• 支持渐进：
  "A complex system designed from scratch never works."（评论2）
  "Evolution seems to be even more chaotic."（评论4）
• 支持规范：
  "Specifications... the most compact definition of your software."（评论5）
  "good prep makes for smoother processes."（评论17）
• 中间立场：
  "The nature’s answer is, consolidate and compact."（评论7）
  "The hard part is knowing what code needs to be written."（评论11）