演进式设计：拥抱变化
一、过度设计与欠设计的平衡
过度设计：为「可能的需求」提前做大量抽象与扩展，结果需求没来、复杂度先来了，维护成本高。欠设计：只顾眼前、没有预留扩展或替换空间，一旦要改就伤筋动骨。理想状态是：满足当前需求、结构清晰、在关键变化点上留出扩展或替换的余地，而不是「什么都可能」或「什么都不留」。
二、用演进能力替代一次性完美设计
不追求「第一次就做对」，而追求能随需求与认知演进：关键边界清晰、接口稳定、内部可替换。这样当需求变化时，可以在有限范围内改（换实现、加策略、调配置），而不是推倒重来。演进能力体现在：扩展点（在哪里加新行为）、插件化（新能力以插件形式接入）、配置化（行为由配置驱动、少改代码）。
三、扩展点、插件化与配置化
让系统「能演进」的常见手段：扩展点（在固定位置预留接口，新逻辑通过实现接口接入）、插件化（功能以插件形式加载，可插拔、可替换）、配置化（策略、开关、参数从配置读，改配置不改代码）。三者可组合：核心稳定，扩展靠插件与配置。
在关键位置定义接口或回调，新行为实现同一接口即可接入。例如：策略模式、事件钩子、SPI。避免在核心逻辑里写死分支。
功能模块以插件形式存在，按需加载、可替换。例如：IDE 插件、支付渠道插件、规则引擎规则包。核心只依赖抽象，不依赖具体实现。
行为由配置驱动：开关、阈值、路由规则、数据源。改配置即可调行为，少发版、少改代码。注意配置的版本与灰度。
四、软件中：重构、抽象时机与技术债管理
在代码层面，演进依赖三件事：重构（在不改变行为的前提下改善结构，小步持续）、抽象时机（等出现两次以上相似需求再抽象，避免「猜一次就抽象」）、技术债管理（把已知的债列出来，排期还或接受，不任其堆积）。
小步、可测地改善结构，不改变对外行为。持续做比「攒一大波再改」安全；配合测试与 CI 保证不破坏功能。
Rule of Three：第一次直接实现，第二次重复时考虑抽象，第三次再抽象。避免为「可能的需求」提前抽象。
显式记录已知债（性能、可读性、测试覆盖等），评估还债成本与优先级，每迭代留一定比例还债或明确接受。
技术债不还会复利：代码越乱越不敢动，最后只能重写。定期还一点、或在新需求里「顺带」把相关债还掉，比一次性大还更可持续。
五、组织中：流程与结构的迭代
演进式设计不限于代码：组织与流程也要能迭代。评审流程、发布流程、分工与边界，都可以按反馈调整：先跑起来，再根据问题做小步改进，而不是一开始就设计「完美流程」。结构也是：团队边界、职责划分可以随业务阶段调整，用「可调整」替代「一次定死」。
组织与流程的迭代思路
- 流程：先有最小可行流程（如评审、发布检查清单），再根据故障与反馈加项或减项。
- 分工：边界与职责随业务阶段调整，避免「永远不变」的架构图。
- 度量：用可观测的指标（交付周期、故障率、满意度）驱动改进，而不是凭感觉。
要点： 在过度设计与欠设计之间找甜点：满足当前、结构清晰、关键处留扩展。用扩展点、插件化、配置化提升演进能力；用重构、适时抽象、技术债管理让代码可持续演进；组织与流程也小步迭代，拥抱变化。
反例：一次性追求完美架构，结果需求变了全白做。
某项目一开始就设计「万能中台」：十几层抽象、几十个扩展点，以为能覆盖未来三年所有场景。做了大半年才勉强跑通一两条业务线，结果业务方向调整，原先假设的「多租户、多业态」没来，来的却是「快速试错、小步上线」。现有架构太重，改一个小需求都要动好几层，团队怨声载道，最后只能局部绕开架构「打补丁」。若当初先做「满足当前两条线、边界清晰、关键处留 1～2 个扩展点」，再随需求迭代，就不会陷入「为幻想中的需求买单」的泥潭。过度设计 + 需求不确定 = 浪费；演进能力比一次性完美更靠谱。
小结： 演进式设计是在过度设计与欠设计之间找平衡，用演进能力替代一次性完美。手段包括扩展点、插件化、配置化；在软件里靠重构、抽象时机、技术债管理持续演进；在组织里流程与结构也可迭代。目标不是「第一次就做对」，而是「能随变化持续改进」。
六、小结
演进式设计拥抱变化：在过度设计与欠设计之间找甜点，用扩展点、插件化、配置化提升演进能力；在软件里用重构、抽象时机、技术债管理持续改进；在组织里流程与结构也可迭代。下一章讲文档、图示与表达：如何用文档与图表有效沟通架构。