先画架构再写代码，我们瀑布项目存活率更高

一、核心结论：架构先行不是过时，是保命符

过去五年，我带过七个从零启动的中大型项目。坦白说，前三个项目我都在跟风”敏捷”，需求还没理清楚就让团队动手写代码，结果三个项目里有两个延期超过三个月，一个直接烂尾。后四个项目，我换了一种方式：在写第一行代码之前，先花两周到一个月的时间把架构画清楚、评审透、冻结住。结果这四个项目全部按期交付，其中两个还提前完成。这就是我想跟你聊的核心结论：先画架构再写代码，不是瀑布模型的原罪，恰恰是瀑布项目存活率更高的关键变量。

很多人一听到”瀑布”两个字就摇头，觉得这是三十年前的古董方法论。但我想请你注意一个被反复忽略的事实：那些活下来的、持续迭代了五年以上的企业级系统，绝大多数在启动阶段都做过扎实的架构设计。无论它们后来用什么名义包装，”敏捷试点”也好、”快速原型”也罢，骨子里都有一份在编码之前就画好的架构蓝图。而那些死掉的项目，往往不是死于瀑布流程本身，而是死于”跳过架构设计直接堆代码”这个致命动作。

我给出的”存活率更高”不是一个主观感受，而是可以被拆解为几个可观测的工程指标：返工成本占比、集成阶段的缺陷密度、需求变更的波及范围、新成员上手的周期。这些指标在架构先行的项目中全面优于边写边画的项目，而且差距通常不是10%或者20%，而是翻倍甚至翻几倍。接下来我会一件事一件事拆开讲。

二、真实场景：那些”敏捷”项目是怎么死掉的

1. 一个典型的失败现场

2021年秋天，我接手了一个已经跑了一年半的电商中台项目。团队二十多人，用的是Scrum，每两周一个迭代，站会、回顾、评审一个不落，看起来特别正规。但实际情况是：系统已经迭代了三十多个版本，每一次加新功能都要改三四个模块，每次改完都要花一周修关联bug。订单模块改了影响库存，库存改了影响促销，促销改了影响支付，整个系统像一个用胶带缠起来的纸房子，外表看着还行，一推就散。

我让团队把现有架构画出来给我看。结果他们花了整整三天才拼出一张勉强能看的系统拓扑图，而且画完之后三个老员工对”订单状态机到底有几个状态”这件事争论了四十分钟。这说明什么？不是说他们没有架构，而是架构只存在于少数几个人的脑子里，而且每个人的版本都不一样。这种状态我称之为”隐性架构失焦”，每个人都以为自己知道系统长什么样，但实际上没有一张图、一份文档、一个共识锚点能让大家对齐。

2. 架构失焦的五个典型症状

基于我见过的十几个失败项目，架构失焦通常表现为以下五个症状。如果你所在的项目中了三个以上，我强烈建议你先停下来画架构，不要再往下写代码：

• 症状一：模块边界模糊。开发A说”这个逻辑应该放订单模块”，开发B说”不对，应该放用户模块”，最后谁先拿到需求谁就随便放。
• 症状二：接口变更无感知。一个人改了接口字段，下游五个调用方没人通知，测试环境跑不通才发现。
• 症状三：新人上手周期超过两周。新加入的开发需要老员工反复口头解释”这个系统大概是怎么回事”，因为没有架构文档可读。
• 症状四：技术选型随人走。张三喜欢Redis就加缓存，李四喜欢Kafka就上消息队列，没人评估这些组件在整个架构中的位置和必要性。
• 症状五：重构永远排不上优先级。所有人都知道代码烂，但没有人能说清楚”烂在哪里”和”理想的架构应该是什么样”，所以重构永远停留在吐槽阶段。

3. 架构先行项目的样子

对比一下，2022年我做的一个金融结算系统，启动阶段就完全不同。团队只有八个人，但我们在写第一行代码之前做了三件事：

1. 画了三张架构图：系统上下文图（明确系统和外部实体的边界）、容器图（明确内部各服务的职责和通信方式）、组件图（每个服务内部的模块划分）。
2. 定了接口契约：六个核心服务之间的接口在编码前就用Proto文件定义好，所有开发对着接口文档写代码，而不是对着别人的代码猜接口。
3. 开了一次架构评审会：把产品、测试、运维都叫上，对着架构图逐层过，产品确认了业务流程的映射关系，测试确认了集成测试的边界，运维确认了部署拓扑。

这三件事一共花了十一个工作日。但后面六个月的编码周期里，我们没有出现过一次因为模块边界不清导致的返工，没有出现过一次接口字段对不上的集成事故。唯一一次比较大的改动是监管规则变化导致结算逻辑调整，但因为架构图清楚标明了结算模块的边界和依赖关系，改动只影响了一个模块，三天就搞定了。

三、常见误区：你以为你在画架构，其实你在画鬼符

1. 误区一：画架构等于画UML类图

这是我在面试和带团队时最常遇到的误解。很多人一听到”画架构”，第一反应就是打开Visio或者Draw.io开始拖类图、时序图。这本质上是把”架构设计”窄化为”UML制图”。实际上，架构的核心不是图本身，而是一系列经过权衡的决策：哪些模块应该存在？它们之间怎么通信？数据怎么流动？非功能需求（性能、安全、可扩展性）怎么满足？一张图只是这些决策的可视化呈现，而不是决策本身。

我见过最离谱的情况是，一个团队花了三周画了一套完整的UML图，类图、时序图、状态图、部署图一应俱全，但开始写代码后发现，他们根本没讨论过”为什么订单服务要拆成三个子模块”和”缓存层到底放在哪一层”。图是画了，决策没做，等于白画。

正确的做法是：先做决策，再画图；图是决策的记录，不是决策的替代品。我的习惯是先列一张”架构决策清单”，把关键的技术选型和架构约束用文字写清楚，然后针对每个决策讨论至少两个备选方案，最后用图把选定方案的逻辑关系画出来。这样画出来的图才有根，而不是凭空想象的”理想架构”。

2. 误区二：架构必须一次性设计完美

这个误区尤其容易出现在从敏捷转回瀑布的团队身上。大家觉得”既然要用瀑布，那架构就必须在编码前做到尽善尽美，后面不能改”。这是对瀑布模型最大的误解之一。瀑布模型的核心不是”不能改”，而是”变更成本随阶段递增”，在架构阶段改一个模块划分只需要改图，在编码阶段改需要动代码，在测试阶段改需要重新验证，在生产阶段改需要承担线上风险。

因此，架构先行的目标不是追求完美，而是把”最容易改的阶段”充分利用起来。我通常会在架构设计阶段预留一个”已知未知”清单，标注出那些我们目前信息不足、后续可能需要调整的决策点。这些决策点我会设计为可替换的，比如用一个抽象层隔离可能变化的第三方服务，或者用配置驱动的方式处理不确定的业务规则。架构完美的幻觉只会让你在后期变更时措手不及。

3. 误区三：敏捷不需要画架构

这是另一个极端。有些团队标榜敏捷，觉得”拥抱变化”就等于”不需要提前设计”。结果就是：每个迭代都在重构，迭代速度越来越慢，最后整个系统变成一坨谁也不敢动的代码。敏捷宣言说的是”响应变化高于遵循计划”，不是”不要计划”。实际上，Martin Fowler 提出的”演进式架构”恰恰强调：你需要一个足够好的初始架构作为演进的基础，否则每次变化都会让系统朝着更混乱的方向退化。

我见过最成功的敏捷团队，其实都有一个”隐秘的瀑布阶段”，他们会花一到两周时间做”迭代零”，在这个阶段做好架构骨架、技术选型和基础设施搭建。然后才进入正式迭代。这个”迭代零”本质上就是微缩版的架构先行。只是他们不叫它瀑布，叫它”预备迭代”。

4. 误区四：小项目不需要架构

这个误区的迷惑性最强。”我们就三五个接口，直接写就行了，画什么架构图？”这话我在不同场合听过不下二十次。问题在于：今天的小项目，可能是明天的核心系统。那些后来变成庞然大物的系统，启动时大多只有几个接口。如果你不在它还是小项目的时候建立架构约束，等它膨胀到几十个模块的时候，重构成本已经高到你无法承受。

我的判断标准很简单：只要这个项目预计存活超过六个月，或者会有超过三个开发经手，就值得画架构。哪怕只画一张系统上下文图加一张模块职责表，也比什么都不画强。对于真正的小项目（比如一个内部工具、一个临时脚本），花半小时画张草图也不算过分，未来接手的人会感谢你的。

四、专业判断：为什么架构先行能系统性提升存活率

1. 缺陷发现时间前移是最核心的经济学逻辑

软件工程领域有一个被反复验证的规律：缺陷发现得越晚，修复成本就越高，而且是指数级增长。在架构设计阶段发现并修正一个模块划分错误，成本是改一张图加上重新讨论二十分钟。在编码阶段发现同样的错误，成本是改动多个模块的代码。在集成测试阶段发现，成本是重新安排测试资源和回归验证。在生产环境发现，成本可能包括线上故障、用户赔付和品牌损失。

我做过一个粗略的估算，基于我们团队的实际项目数据：

架构先行的本质就是把缺陷发现和修正的时间窗口尽量前移。在写代码之前把模块边界、接口契约、数据流向这些容易出问题的地方先想清楚，相当于在成本最低的阶段消灭了未来可能造成巨大损失的隐患。这不是什么高深的理论，就是最朴素的风险管理逻辑。

2. 认知对齐是降低沟通成本的杠杆解

你有没有经历过这种情况：开需求评审会的时候，产品经理讲了一遍需求，你觉得你听懂了，他也觉得他讲清楚了，结果代码写出来之后产品经理说”这不是我想要的”。这个问题的根因不是需求文档写得不够细，而是双方对”系统是什么”没有一个共同的视觉参照物。

架构图在这里发挥了一个独特的作用：它是一种跨角色的通用语言。产品经理看着系统上下文图，能确认业务流程和外部系统的映射关系对不对。开发看着组件图，能确认自己负责的模块边界清不清晰。测试看着部署图，能确认集成测试的范围和mock策略。运维看着基础设施图，能确认监控和容灾方案是否覆盖到位。一张好的架构图可以让五六个不同角色在半小时内对齐认知，而纯靠文档和口述，同样的对齐可能需要两三周，而且对齐的质量更差。

我在PingCode的Wiki模块里维护了所有项目的架构文档，每次架构评审后就把更新后的架构图放上去，标注版本号和变更说明。我发现一个规律：架构图更新越频繁的项目，跨团队沟通的摩擦越小。因为所有人都在看同一张图，讨论问题时有一个共同的”锚点”。而架构图长期不更新的项目，沟通成本会逐渐升高，因为每个人脑子里的系统画像已经分叉了，只是大家都没意识到而已。

3. 技术债务的可视化让”还债”从吐槽变成计划

技术债务这个词被用得太泛了。很多团队把”代码写得烂”统称为技术债务，但这种模糊的标签对解决问题毫无帮助。真正可管理的技术债务，必须和架构决策挂钩。具体来说，每引入一笔技术债务，都应该能在架构图上标注出来：哪个模块的哪个决策是妥协的？这个妥协的影响范围有多大？什么条件下应该偿还？

我的做法是在架构图旁边维护一个”技术债务登记表”，每个条目包含四条信息：债务来源（哪次架构决策的妥协）、影响范围（哪些模块或接口受影响）、偿还条件（触发偿还的业务或技术条件）、当前状态。这样每次迭代规划的时候，技术债务不再是抽象的”代码有点烂”，而是具体的”订单模块和支付模块之间的同步调用需要改为异步，当前QPS还没到阈值，预计Q3需要动手”。这种颗粒度的债务管理，只有在架构先行、架构图持续维护的前提下才能做到。

五、案例与数据观察：从中大型企业的实践看架构先行的实际效果

1. PingCode服务的企业客户中的观察

PingCode主要服务中大型企业及100人以上的研发组织。在过去几年里，我有机会接触到不少使用PingCode进行项目管理的团队，其中相当一部分团队在实践瀑布模式或混合模式。我发现一个有意思的现象：那些在PingCode中把需求管理、迭代规划和Wiki文档（尤其是架构文档）用得比较重的团队，项目交付质量普遍高于只用任务看板的团队。

具体来说，PingCode的Wiki模块支持团队在项目启动阶段建立架构文档库，包括系统架构图、接口规范、技术选型说明等。而Project模块则支持将这些架构决策转化为具体的开发任务和迭代计划。架构文档和开发任务之间有清晰的追溯关系，每个开发任务都可以追溯到它所属的模块和它依赖的接口。这种追溯能力在项目中期和后期尤其有价值：当需求变更发生时，团队可以快速判断变更的影响范围，因为架构图清楚地标明了模块之间的依赖关系。

一个典型的场景是：某金融科技公司使用PingCode管理一个涉及六个子系统的核心交易平台项目。他们在项目启动阶段花了三周时间，在Wiki中建立了完整的架构文档体系，包括系统上下文图、服务间通信矩阵、数据流向图、以及关键接口的Proto定义。这些文档不是一次性写完就扔掉的，而是作为”活文档”在整个开发周期中持续维护。项目负责人告诉我，这个项目在六个月的开发周期中经历了四次比较大的需求变更，但因为架构文档清晰，每次变更的影响评估都控制在半天以内，变更实施也基本没有引发连锁问题。对比他们之前的一个项目，类似规模但没有做架构先行，一次需求变更的影响评估通常需要两到三天，而且经常遗漏影响点，导致上线后出问题。

2. 不同行业的架构先行实践差异

架构先行不是一个放之四海而皆准的固定模板，不同行业和项目类型对架构先行的侧重点差异很大。根据我自己的项目经验和行业观察，大致可以归纳为以下几类：

注意，这些时间投入不是让你画三周的图什么都不干。架构设计阶段本身也包含了技术预研、原型验证和关键风险的提前排除。比如金融项目中的事务边界设计，可能需要先写几个关键场景的伪代码来验证分布式事务方案是否可行。这部分工作本身就是开发工作的一部分，只是它发生在正式编码之前。

3. 一个反例：当架构先行变成了”过度设计”

我也必须诚实地说，架构先行不是没有失败案例。我见过一个团队，在项目启动后花了整整六周时间画架构，画了三十多张UML图，每一张都精雕细琢，评审了四次还没结束。最后业务方等不及了，直接砍掉了这个项目，换了一个团队从零开始用”边写边画”的方式三个月上线了MVP。

这个案例暴露的问题不是”架构先行不对”，而是”架构设计脱离了时间盒约束”。架构先行的正确姿势是在有限时间内做出足够好的决策，而不是无限追求完美。我给团队定的规则是：架构设计阶段不允许超过项目总周期的15%。如果一个项目计划六个月，架构设计不能超过四周；如果一个项目只有两个月，架构设计不能超过一周。时间到了就冻结，剩下的改进通过后续的架构迭代来完成。这个规则听起来武断，但它在实践中非常有效，它强制团队在有限时间内聚焦最重要的决策，而不是在细枝末节上反复纠结。

六、行动建议：如何正确地在瀑布项目中实践架构先行

1. 设定”架构冻结节点”

这是我在第四个瀑布项目中学到的最重要的一课。架构设计不能无限期进行下去，必须有一个明确的”冻结”时间点。在这个时间点之后，任何架构变更都必须经过一个轻量级的变更评估流程，而不是随意修改。

具体做法分为三步：

1. 设定冻结日期。在项目启动会上就明确宣布：架构设计阶段截止到X月X日，之后架构进入冻结状态。这个日期不是随便定的，而是基于项目整体周期反推的，通常是项目总周期的10%-15%。
2. 冻结前完成架构评审。在冻结日期之前，必须完成至少一次全团队架构评审，评审内容包含：系统上下文图、模块职责定义、接口契约（至少核心接口）、关键非功能需求的实现策略。评审通过后，架构文档打上版本号，进入基线。
3. 冻结后变更走轻量流程。冻结不等于不能改。但如果需要改，必须在PingCode的Wiki中更新架构文档，标注变更原因和影响范围，并在下一次站会上同步给全团队。这个流程不是为了卡变更，而是为了确保变更被记录和被感知。

我在两个项目中严格执行了这个机制。结果是：两个项目的架构变更次数在冻结后确实减少了大约70%，但真正需要改的变更并没有被压制，它们只是变得更审慎、更有记录。而那些”我觉得换个方式更好”式的随意修改，在”需要更新文档和通知全团队”的门槛面前自然消失了。

2. 建立架构与代码的双向验证机制

架构图画得再好，如果代码不按图写，就等于白画。架构设计必须有一个从图到代码、再从代码回到图的闭环验证机制。

我推荐的做法是引入”架构合规检查”。具体来说：

• 正向验证（图→代码）：在代码审查环节，审查人必须对照架构图确认：新增的类/模块是否在架构图中有对应的位置？模块之间的调用关系是否符合架构图定义的依赖方向？有没有出现架构图明确禁止的跨层调用？
• 反向验证（代码→图）：每个迭代结束后，由架构师或Tech Lead对照代码仓库的实际结构，检查架构图是否需要更新。如果代码中出现了架构图没有体现的新模块或新依赖，要么更新架构图，要么把代码改回去。
• 自动化检查：对于Java项目，可以用ArchUnit编写架构测试用例，自动检查包依赖关系、分层约束、命名规范等。这些测试集成到CI流水线中，每次提交都会自动验证。

这套机制我在三个项目中推行过，坦白说前两个项目推行得比较艰难，开发觉得被”管”了，觉得架构约束影响了开发效率。但第三个项目推行得很顺利，因为我调整了策略：我把架构合规检查从”审查”改成了”帮助”，架构师不是在挑刺，而是在帮开发确认”你写的代码在大图里是对的”。一字之差，接受度天差地别。

3. 用PingCode打通架构文档到开发任务的信息流

架构文档的最大敌人不是”没人写”，而是”写了没人看”。如果架构文档和日常开发任务之间没有连接，文档就会变成一潭死水，逐渐腐烂。

PingCode的Wiki和Project模块之间的关联能力在这里很有价值。我的做法是：

• 在Wiki中维护架构文档，每一张架构图都关联到对应的需求（Epic/Feature）。
• 在Project中创建开发任务时，任务描述中直接引用Wiki中的架构图链接和对应的架构决策编号。
• 架构变更时，通过PingCode的通知机制自动告知所有相关任务的负责人。

这样，架构文档不再是孤立的参考资料，而是开发任务的上游输入。开发在看任务的时候，顺手就能看到相关的架构决策背景，理解”为什么这个模块要这么设计”。这种信息流的打通让架构文档从”一次性的交付物”变成了”持续产生价值的活文档”。

4. 架构评审的”三问三不审”原则

架构评审是架构先行中最容易被形式化的环节。很多团队的架构评审变成了”架构师在上面讲一个小时，下面的人刷手机，讲完问一句’大家有没有问题’，没人说话就通过”。这种评审纯属浪费时间。

我总结了一套”三问三不审”原则，把架构评审从过场变成了真正有价值的讨论：

三问（评审必须回答的三个问题）：

1. 模块边界问清楚：每个模块的职责是什么？它不知道也不应该知道什么？边界模糊的地方在哪里？
2. 变更影响问清楚：如果A模块改了一个接口，哪些模块会受影响？如果B服务挂了，哪些功能会降级？
3. 非功能需求问清楚：性能瓶颈可能在哪里？安全敏感数据流经哪些模块？扩展点预留了哪些？

三不审（评审不需要纠结的三个问题）：

1. 不审代码级细节：评审关注的是模块和接口层面的决策，不讨论具体类名、方法签名等编码细节。
2. 不审未确定的需求：如果某些需求还没定，就标注为”待定”并说明影响范围，不要花时间假设各种可能性。
3. 不审个人偏好：技术选型如果两个方案在工程上没有显著差异，就由架构师拍板，不要陷入”我喜欢A框架你喜欢B框架”的争论。

用这套原则，我通常能在一个小时内完成一次高质量的架构评审。评审结束后产出一份”评审结论记录”：哪些决策通过了，哪些需要修改，哪些标注为待定，以及下次评审的时间。这份记录直接放在PingCode Wiki中，作为后续开发的依据。

七、不同情况下的取舍：架构先行不是万能药

1. 需求高度不确定时：架构骨架+演进式补充

这是架构先行面临的最大挑战。如果需求本身还在剧烈变化，花三周画架构是不是浪费时间？我的回答是：在这种情况下，你需要的是”架构骨架”而不是”架构全貌”。

架构骨架的意思是：只确定那些无论需求怎么变都不会轻易改变的基础决策，比如系统的分层策略、核心域和非核心域的划分、关键的技术选型（语言、框架、数据库类型）、以及最核心的几个模块之间的通信方式。至于业务逻辑层面的模块划分，可以随着需求明确逐步细化。

我在一个SaaS产品孵化项目中使用过这个策略。项目启动时商业模式还在验证阶段，需求每周都在变。但我们还是花了一周时间确定了架构骨架：前后端分离、微服务粒度控制在8-12个服务、消息队列用于异步解耦、数据存储采用关系型+文档型混合方案。这些决策在后续的十几次需求变更中都没有被动摇，因为它们定义的是系统的”物理形态”而不是”业务形态”。架构骨架的价值在于：它给变化划了一个安全的边界，在骨架之内，你可以自由调整；超出骨架的调整，需要上升到架构层面重新评估。

2. 小团队vs大团队：架构文档的颗粒度要适配

一个3-5人的小团队和一个30人以上的大团队，对架构文档的需求完全不同。小团队最大的优势是沟通成本低，架构认知可以通过口头交流传递。大团队如果没有书面架构文档，认知失焦几乎是必然的。

我的经验法则：

• 5人以下团队：一张系统上下文图+一张模块职责表就够了。架构评审可以简化为在白板上画图加讨论。关键是保证至少有一个地方记录了”我们达成了什么共识”。
• 5-15人团队：至少需要系统上下文图、容器图、以及核心接口的契约定义。架构文档必须放在Wiki中并定期更新。架构评审需要正式排期，但可以控制在45分钟内。
• 15人以上团队：完整的架构文档体系（三层架构图+接口规范+技术选型说明+非功能需求方案），必须走正式的架构评审和冻结流程。还需要指定至少一名架构负责人持续维护文档。

一条铁律：团队规模每翻一倍，架构文档的完整度要提高一个等级。这不是为了追求文档的厚度，而是因为沟通路径数量随团队规模呈指数增长，没有书面锚点的话，信息衰减会严重到无法接受的程度。

3. 新项目vs遗留系统改造：先画”现状架构”再画”目标架构”

架构先行的讨论大多默认是”从零开始的新项目”。但现实中，大多数开发工作是在遗留系统上进行的。对于遗留系统改造，架构先行的含义变了：不是先画一个理想的架构然后按图施工，而是先搞清楚现在的架构是什么，再决定改什么。

具体做法分两步：

1. 逆向绘制现状架构。通过代码分析、运行时追踪、以及和老员工的访谈，把当前的系统架构还原出来。这个过程通常会有”惊喜”，你会发现一些没人知道的模块依赖、一些早已废弃但还在运行的服务、以及一些”临时方案”变成了永久方案的连接。
2. 在现状架构上标注改造点和目标状态。不是推倒重来，而是在现状图上标出：哪些模块保持不变、哪些需要重构、哪些需要移除、哪些需要新增。目标架构图是现状架构图的”diff版本”。

我在一个遗留支付系统改造项目中使用过这个方法。光逆向绘制现状架构就花了两周，但这两周是值得的，我们发现了七个”幽灵依赖”（代码依赖了但没人知道的模块），以及三个本应独立但实际耦合在一起的服务。如果没有这个逆向过程，直接基于理想架构动手改造，改造范围一定会严重低估，工期一定会严重超期。

4. 什么时候架构先行会变成负担

我必须诚实地列出架构先行不适合的情况，以免读者机械套用：

• 项目周期极短（少于一个月）：如果整个项目从启动到交付只有三四周，花一周画架构显然不划算。这时候应该依靠团队已有的架构共识和技术规范来快速推进。
• 纯探索性原型：目标是验证一个技术可行性或者做A/B测试，代码可能用完就扔。这种情况不需要架构先行，快速写出来、快速验证、快速决定继续还是放弃。
• 团队完全没有架构能力：如果团队里没有任何人有过架构设计经验，强行要求架构先行只会产出形式化的文档，起不到真正的指导作用。这时候的正确做法是先引入一个有经验的架构师或者安排架构培训。
• 技术栈高度标准化：有些组织的技术栈已经高度标准化（比如统一使用某套微服务框架、统一的CI/CD流水线、统一的部署拓扑），新项目只是在标准模板上填充业务逻辑。这种情况下架构设计的工作量很小，不需要专门的架构先行阶段。

判断是否需要架构先行，核心看一个指标：这个项目有多少”首次决策”。如果大部分技术决策已经有现成的标准和先例可循，架构设计可以轻量化。如果项目涉及大量首次决策，新的业务领域、新的技术组件、新的集成场景，架构先行就是必要的。

八、总结与下一步行动

回到文章标题：先画架构再写代码，我们瀑布项目存活率更高。这不是一句口号，而是可以被拆解为具体的工程实践和可观测指标的事实。

核心逻辑非常简单：

1. 缺陷发现时间前移，在架构阶段修正一个错误，成本只是在生产环境修正的百分之一。
2. 认知对齐杠杆放大，一张架构图可以让整个团队在同一个锚点上讨论问题，而不是各自基于不同的脑内模型。
3. 技术债务可管理，有了架构基线，技术债务才能被登记、追踪和有计划地偿还。
4. 变更影响可控，架构图标明了模块依赖，需求变更时可以快速评估波及范围。

如果你现在正在启动一个新项目，或者正在一个混乱的存量项目中挣扎，我建议你做三件事：

第一件事：不管项目已经进行到什么阶段，花半天时间画一张系统上下文图。标清楚这个系统和哪些外部实体有交互、核心的数据流是什么、系统的主要职责是什么。这张图不需要很精美，手绘在白板上拍照也行。关键是让团队有第一张共同的”认知锚点”。

第二件事：下一次站会上，做一个小实验。让每个人在白纸上画出他们心目中的系统模块划分，然后摊开对比。如果五个开发画出五种不同的划分方式，你就知道自己离架构失焦有多近了。这个实验只需要十分钟，但它的诊断价值远超十分钟。

第三件事：如果你决定在下一个项目中实践架构先行，记住那个15%的时间盒规则。架构设计不要超过项目总周期的15%。到了时间就冻结，剩下的改进通过后续迭代来完成。完美是好的敌人，够好是完美的朋友。

瀑布模型本身不是问题，跳过架构设计才是问题。架构先行不是过时的方法论，而是被大量失败项目反向验证的生存法则。你不需要完全放弃敏捷，也不需要变成一个瀑布原教旨主义者。你只需要在写代码之前，确保自己脑子里有一张足够好的图，并且确保团队的其他人看到的也是同一张图。这件事做对了，项目的存活率就已经赢了一大半。