夜雨聆风软件开发走到今天，累积了不下几十种方法论、框架与实践范式。它们不是彼此替代的时尚，而是不同问题在不同时期的解答。理解它们，关键在于看清每一种方法论面对的是什么问题、给出了什么约束、又在什么前提下失效。以下十种，覆盖了从需求到研发、架构、从交付到运维的完整链条。
全景：反馈循环的不断缩小
经典瀑布模型
1970 年 Winston Royce 在 IEEE WESCON 上发表了一篇管理大型软件系统的论文，后来被反复引用为瀑布模型的出处。但 Royce 的原文其实描述的是一个有大量反馈回路的迭代过程——他明确指出单次顺序执行是有风险的，并建议“先做两次”。后人从他论文的第二张图里截出了那个著名的需求→设计→实现→测试→维护的单向箭头，而忽略了那张图之后的全部讨论。
经典瀑布模型将软件生命周期切分为需求分析、系统设计、编码实现、测试验证和运行维护五个阶段，每个阶段的输出是下一阶段的输入，阶段之间设置评审门禁。它的核心假设是需求在项目初期可以被完整捕获且不会发生重大变更。
这个假设在物理工程和嵌入式系统中曾经成立——当你在制造一座桥梁或一颗卫星的飞控软件时，中途变更的代价确实大到不可接受。但在商业软件领域，需求的不确定性才是常态，瀑布模型的结构性缺陷——反馈太晚、集成太迟、风险后置——导致大量项目在交付时才发现产品与用户的真实需求早已偏离。尽管如此，瀑布模型的阶段划分和门禁思想仍然是所有现代方法论的基础词汇，只是被拆散后嵌入到更短的反馈循环中去了。
敏捷开发
2001 年 2 月，17 位软件从业者在犹他州 Snowbird 度假村聚了三天，写出了只有 68 个英文单词的敏捷宣言。这四句话——个体与互动高于流程与工具、可工作的软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划——构成了此后二十多年软件工程领域最深远的一次范式转换。
敏捷不是一套流程，而是一组价值观和原则。Scrum 把开发切分为固定长度的 Sprint，通过每日站会、Sprint 评审和回顾建立节奏；极限编程掏出结对编程、持续集成、测试先行等具体工程实践；看板则用可视化的工作流和 WIP 限制来暴露瓶颈。它们的共同点是短反馈循环——两周甚至更短——让团队在每一次迭代结束时都有一份可演示的软件增量供利益相关者审视。
敏捷的前提是团队具备拆解需求、独立交付增量的能力。当一个组织将 Scrum 的仪式照搬过来却保留了瀑布式的审批链和年度预算周期时，得到的只是披着敏捷外衣的水涨船高——进度更快暴露问题，但组织无力响应暴露出来的问题。敏捷的真正门槛不在开发团队，而在整个组织的决策速度。
精益软件开发
2003 年，Mary 和 Tom Poppendieck 将丰田生产系统的七项精益原则移植到软件领域。这不是借一套新流程来替代敏捷，而是追问一个更根本的问题：从用户需求被识别到代码在生产环境运行，这段端到端的价值流里，每一步究竟有没有创造价值？
精益七原则的每一条都指向浪费的消除：消除浪费——未被使用的代码、等待、缺陷、任务切换；内建质量——不在最后阶段检验，而在每一步保证；创建知识——不只是写代码，而是让团队对系统的理解持续沉淀；延迟承诺——在最后责任时刻之前保留选项；快速交付——压缩批次大小，让价值更快流动；尊重人——赋予一线团队决策权；整体优化——度量的是端到端的交付能力，而不是某一环节的局部效率。
精益和敏捷经常被混用，但它们的视角不同：敏捷关注的是“怎么更快地响应变化”，精益关注的是“流里面哪些环节根本没有创造价值”。精益的一条核心洞察是：团队的大部分等待时间不是技术问题，而是批处理决策、审批队列和组织边界造成的。一张价值流图通常能揭示一个令人不适的事实——从想法到上线，实际编码和测试的时间往往不到总周期的 15%。
领域驱动设计
2003 年 Eric Evans 出版了《领域驱动设计》——一本在出版后几年内销量平淡、却在十年后成为经典的书。DDD 的核心主张很简单：软件的复杂性来自于你要建模的那个业务领域本身，而不是技术实现。如果你没有深刻理解业务，再好的架构也只是一个精致的错误。
DDD 提供了两套工具。战略设计层面：限界上下文将一个大系统拆分为多个具有明确边界的子模型，每个上下文内部拥有统一的语言（通用语言）和独立的模型完整性——这直接回应了微服务架构中最难回答的问题：服务边界到底应该画在哪里？战术设计层面：实体、值对象、聚合、领域服务、资源库、工厂——这些模式为限界上下文内部的建模提供了经过验证的构件。
DDD 的一条关键规则是：每个限界上下文内部的通用语言必须由领域专家和开发团队共同演进。团队用业务语言写代码——方法名、类名、变量名都精确映射到业务概念——而不是在业务语言和技术语言之间来回翻译。当一段代码中的命名和领域专家的用词出现分歧时，那就是技术债开始积累的信号。
云原生
云原生计算基金会给出的定义是：云原生技术使组织能够在公有云、私有云、混合云等现代动态环境中构建和运行可扩展应用，代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。
拆开来看，每一层都在解决一个具体问题。容器提供了一致的运行环境和部署单元——“在我机器上能跑”从此失效。Kubernetes 通过声明式 API 管理容器调度，你描述期望的终态而非执行步骤，控制循环持续将实际状态向期望状态调和。服务网格将通信、重试、限流、可观测性从应用代码中剥离到 Sidecar 代理。不可变基础设施意味着服务器不再被修补，而是被替换——这消除了配置漂移，也倒逼部署流程的完全自动化。
CNCF 在 2025 年 9 月发布了云原生成熟度模型 4.0 版，将评估维度从最初的技术层面扩展到人员、流程、政策、技术和业务成果五个方面，并首次纳入了 AI 和 FinOps citation。云原生已经不是要不要上的问题，而是上到什么程度、哪个环节先上的选择。
TDD / BDD
测试驱动开发是 Kent Beck 在极限编程中提炼出的一项具体实践，遵循一个严格的微循环：先写一个失败的测试，用最少的代码让它通过，然后重构。红—绿—重构的节奏迫使写代码的人在动手之前先回答“这段代码被调用的契约是什么”。测试不是验证手段，而是设计手段——它规定了接口的形状和行为边界。
TDD 的三个定律被浓缩为：不允许编写任何生产代码，除非是为了让一个失败的单元测试通过；不允许编写超出让测试通过所需的更多单元测试；不允许编写超出让测试通过所需的更多生产代码。听起来极端，但在严格执行的团队里，它产生的副作用是一套自动化的回归测试套件和天然符合开闭原则的模块边界。
行为驱动开发是 Dan North 在 TDD 基础上的一次语用转向。他把“测试”这个词替换为“行为规格”，把编写测试的人从开发人员扩展到业务分析师和 QA。BDD 使用 Given-When-Then 结构描述场景，语言足够贴近自然语言，又保持足够的结构化来驱动自动化。BDD 解决的问题不是技术正确性，而是对需求理解的共同确认——所有人对“什么是完成”使用同一份可执行的规格。
TOGAF
TOGAF 是 The Open Group 维护的企业架构框架，最新版本为 TOGAF 10。它的核心是架构开发方法——一个从预备阶段开始，经过架构愿景、业务架构、信息系统架构、技术架构，到机会与解决方案、迁移规划、实施治理和架构变更管理的完整循环。这十个阶段构成了一个可裁剪的元流程，组织可以在其中填入自己实际的架构工作。
TOGAF 的最强资产是它提供了一套共享的词汇和结构，让 CIO、架构师和项目经理能够围绕同一张图讨论企业 IT 的现状和演进方向。内容框架定义了架构构建块的分类方式；企业连续体提供了一个从基础架构到组织特定架构的分类谱系；ADM 指南和技术则为不同场景（安全架构、面向服务架构、敏捷方法）提供了裁剪建议。
TOGAF 常被批评为过于重量级，但这一批评混淆了框架和裁减后实例的关系。TOGAF 明确不要求执行所有阶段，也明确不生产与敏捷相悖的重型文档。真正的问题在于许多组织的架构实践是“为了交付架构文档而做架构”——这不是 TOGAF 的问题，而是任何一种方法论被照搬时都会遇到的通病。
DevOps 与 CI/CD
2009 年 Patrick Debois 在比利时根特组织了第一届 DevOpsDays，这个词从此进入行业词典。DevOps 的出发点是一个观察：开发和运维的目标天然冲突——开发被考核的是交付速度，运维被考核的是系统稳定性，而变更正是稳定性的最大敌人。当这两个团队各自优化自己的 KPI 时，整个组织的交付能力在夹缝中被牺牲。
DevOps 不是把 Dev 和 Ops 合并成一个岗位，而是消除这两个职能之间一切不必要的等待、审批和转交。持续集成让每个开发者的每次提交都触发自动构建和单元测试，持续交付让每一次通过测试的变更都自动推进到类生产环境中验证，持续部署更进一步——通过所有验证的变更自动上线。60% 的组织已经将 CI/CD 应用于大多数或所有应用程序，GitLab、Jenkins 和 GitHub Actions 是使用最广泛的管道管理工具。
Gene Kim 在《凤凰项目》中提炼了 DevOps 三原则：流动——从左到右加速从开发到运维到客户的价值流；反馈——从右到左加速从运维到开发的反馈信号；持续学习与实验——在失败中系统性地积累组织知识。这三条原则的价值在于它们把 DevOps 从工具清单上升为一个持续改进框架。
Google SRE
站点可靠性工程是 Google 在 2003 年前后以内部项目形式启动、2016 年通过同名书籍公开发表的一套运维方法论。SRE 的核心创新不在技术工具，而在一个管理机制：错误预算。
错误预算 = 1 - 服务等级目标。如果一个服务的可用性 SLO 是 99.99%，那么每个月允许的不可用时间约为 4.38 分钟——这就是该服务的错误预算。只要本月预算尚未耗尽，产品团队可以按自己的节奏发布新功能。一旦预算耗尽，所有非紧急变更冻结，直到服务恢复在 SLO 之内或下个周期重置。
这个机制的妙处在于它把运维和产品之间永无止境的拉锯翻转为一场基于数据的共同决策。Google 的经验表明，变更是一大半事故的根源——大约 70% 的宕机事件由变更引起 citation。错误预算让产品团队自己衡量：这次发布的风险值不值得消耗仅剩的预算？当答案是“不值得”时，决定来自数据而非意见。SRE 还规定了运维工作量的 50% 上限——一个 SRE 团队分配给日常运维的时间不能超过一半，其余必须投入到自动化、容量规划等工程工作中。一旦超过上限，运维负载必须被分流回产品团队。这条规则确保了 SRE 不会退化为一个高级运维岗。
混沌工程
2011 年 Netflix 在从自建数据中心向 AWS 迁移的过程中，面临一个前所未有的问题：云上任何一个实例都可能随时消失，无法预测，无法阻止 citation。传统的做法是祈祷这不会发生。Netflix 选择反其道而行——他们写了一个叫 Chaos Monkey 的脚本，在工作时间随机终止生产环境的 EC2 实例，然后在旁边等着看系统会不会死。
这听起来疯狂，但逻辑是坚实的：如果你知道故障会随时发生（因为在云上这是确定的），那么唯一的理性选择就是主动触发故障，在可控的条件下观察系统反应，然后加固薄弱环节。Chaos Monkey 成功后，Netflix 扩展出一整套 Simian Army——Latency Monkey 注入网络延迟，Doctor Monkey 检查实例健康状态并踢出不健康的节点，Janitor Monkey 清理未使用的资源。
混沌工程被定义为“在分布式系统上进行实验的学科，以建立对系统承受生产环境中湍流条件的能力的信心”。它不是随机制造混乱——每一次实验都遵循一个严格的流程：首先定义稳态假设（什么指标正常才算系统健康），然后设计一个最小爆炸半径的实验变量（关掉一个节点、延迟一个数据库连接、填满一个磁盘分区），在受控条件下注入故障，观察稳态是否保持，最后根据结果决定是否扩大爆炸半径或修复发现的问题。
混沌工程与测试有本质区别：测试验证的是已知条件——你知道系统应该怎么表现，你在验证它是否如此表现；混沌实验探索的是未知——你不知道系统在特定故障条件下会怎样，你做实验来发现。在一个你无法完全理解所有组件交互的分布式系统中，混沌工程是唯一能将“我们认为系统很有韧性”变成“我们验证过系统确实有韧性”的方法。
这十种方法论排在一起，呈现出的是一个不断缩小的反馈循环：瀑布以年为单位，敏捷以周为单位，精益度量的是分钟级的流动效率，TDD 以秒级红绿循环约束设计，DevOps 将部署变成一次提交后的自动事件，混沌工程则在生产环境中实时验证整个系统的稳态。它们不是竞争关系——每一个都在前一个的遗留问题上找到了新的杠杆点。选方法论之前，先看清自己真正面对的矛盾是什么：是需求不明确，是流不畅通，是运维和开发在互相指责，还是系统太复杂以致于没人真正知道它在极端情况下的行为。答案不在方法论清单里，在诚实面对现状的那一刻。
