003-系统构建方法
自顶向下、自底向上与分而治之的组合使用。
软件工程中的自顶向下、自底向上和分而治之，是三种经典的问题分析与系统构建方法。
一、自顶向下：先看整体，再拆细节
自顶向下的核心思路是：先明确系统整体要做什么，再逐层拆分成子系统、模块、类、函数，最后落实到具体代码实现。
比如要开发一个在线购物系统，采用自顶向下的方法时，通常会先问：
这个系统的总体目标是什么？ 它需要支持哪些核心业务？ 整体架构应该如何划分？
然后再逐步拆解：
在线购物系统 → 用户模块、商品模块、购物车模块、订单模块、支付模块、物流模块 → 订单模块 → 创建订单、取消订单、查询订单、订单状态流转 → 创建订单函数 → 参数校验、库存检查、价格计算、订单保存、消息通知
这种方法的优势是全局结构清晰。系统从一开始就有比较明确的架构边界，模块之间的关系也更容易统一规划。对于需求比较明确、规模较大的系统，例如银行核心系统、企业 ERP 系统、政务平台、基础设施平台等，自顶向下非常常见。
它的缺点是，如果一开始对需求理解不准确，高层设计可能会出现偏差，后续细节实现时就会频繁返工。因此，自顶向下适合需求相对清楚、业务边界比较稳定的场景。
二、自底向上：先做组件，再组系统
自底向上的核心思路是：先从基础能力、底层组件、工具模块开始建设，再逐步组合成更大的功能和完整系统。
比如还是开发在线购物系统，采用自底向上的方法时，可能会先实现：
日志组件 配置管理组件 数据库访问组件 缓存组件 权限校验组件 消息队列封装 通用异常处理模块 支付 SDK 封装
当这些基础组件逐渐稳定后，再用它们组合出商品服务、订单服务、支付服务等业务模块，最终形成完整系统。
这种方法的优势是复用性强、基础能力扎实。团队可以不断沉淀通用模块，后续开发新功能时就不需要重复造轮子。对于已有技术平台、组件库、框架体系的团队来说，自底向上很自然。
它也适合需求还在演化的项目。因为业务目标可能一开始并不完全清楚，但团队可以先建设确定性较高的底层能力，等需求逐渐明确后再组合成业务系统。
它的风险是，如果只关注底层组件而缺乏整体目标，可能会出现“组件很多，但系统拼不起来”的问题。也就是说，自底向上容易造成局部能力很强，但整体架构不够统一。
三、分而治之：把复杂问题拆成小问题
分而治之的核心思想是：面对复杂问题时，不直接一次性解决整体，而是把它拆成若干相对独立、规模更小的问题，分别解决后再组合起来。
它更像是一种通用的问题处理原则，不只是软件工程中的系统构建方法，也广泛存在于算法设计、项目管理、组织协作中。
比如开发一个推荐系统，可以把问题拆成：
数据采集 用户画像 商品画像 召回算法 排序算法 特征工程 模型训练 在线推理 效果评估
每个部分都可以由不同团队或不同模块独立推进，最后再集成为完整的推荐系统。
分而治之的优点是降低复杂度。一个大问题往往难以直接理解和实现，但拆成多个小问题后，每个小问题的目标更清晰、测试更容易、维护成本也更低。
不过，分而治之的关键在于“如何拆”。如果拆分边界不合理，就会导致模块之间耦合严重、接口混乱、集成困难。好的拆分应该尽量做到高内聚、低耦合：每个模块内部职责集中，模块之间通过清晰接口协作。
四、三者之间的关系
这三种方法并不是完全独立的。
自顶向下强调从整体到局部，通常会用到分而治之。因为从系统目标拆到模块、从模块拆到函数，本质上就是在分解问题。
自底向上强调从局部到整体，也可以结合分而治之。先分别解决多个基础能力或局部问题，再逐步组合成更复杂的系统。
分而治之则更像是底层思想，它既可以服务于自顶向下，也可以服务于自底向上。
可以简单理解为：
自顶向下回答的是：从哪里开始设计？ 自底向上回答的是：从哪里开始实现？ 分而治之回答的是：如何降低复杂度？
五、举一个综合例子
假设要开发一个企业内部审批系统。
采用自顶向下时，团队会先定义系统整体架构：
审批系统 → 表单管理 → 流程管理 → 权限管理 → 通知管理 → 审批记录 → 数据报表
然后继续拆解流程管理：
流程定义 流程发起 节点审批 流程转交 流程撤回 流程归档
采用自底向上时，团队可能会先建设一些基础能力：
用户身份认证 角色权限模型 表单渲染引擎 消息通知组件 流程状态机 审计日志组件 数据库访问层
这些组件稳定后，再组合成完整的审批业务。
而分而治之贯穿整个过程：无论是把审批系统拆成表单、流程、权限、通知，还是把流程引擎拆成状态流转、节点规则、审批人计算、超时处理，都是在通过拆分降低复杂度。
六、实际项目中如何选择
如果项目目标清晰、业务边界稳定、系统规模较大，可以优先采用自顶向下，先做好架构设计和模块划分。
如果团队已有大量基础组件，或者项目需求还在逐步演化，可以更多采用自底向上，先沉淀稳定的底层能力，再支撑业务扩展。
如果问题本身很复杂，无论采用哪种方向，都应该使用分而治之，把复杂系统拆成更容易理解、开发、测试和维护的部分。
在真实软件工程中，最常见的做法是： 先用自顶向下明确系统目标和架构边界； 再用分而治之拆分模块和任务； 同时用自底向上建设可复用组件和基础能力； 最后通过迭代开发不断调整设计。
所以，这三种方法不是“选一个、排斥另外两个”，而是从不同角度帮助我们管理复杂度、组织代码和构建系统。