设计是软件的 “骨架”，好的设计能让系统更易扩展、更易维护；反之，糟糕的设计会导致系统后期 “牵一发而动全身”。这一部分的核心是 “如何通过合理的设计，降低系统复杂度”。
- 模块化设计
模块化是将系统拆分为多个独立的 “模块”（如函数、类、组件），每个模块负责一个明确的功能，模块之间通过清晰的接口交互。书中强调模块化的核心原则：
单一职责原则（SRP）：一个模块（或类、函数）只负责一个功能。例如，一个 “用户服务” 类（UserService）应只处理用户的 “注册、登录、查询” 等用户相关逻辑，而不应包含 “订单处理”“支付逻辑” 等无关功能。单一职责能让模块更易理解、更易测试 —— 当需求变更时，只需修改对应模块，无需影响其他部分。
低耦合、高内聚：“耦合” 指模块之间的依赖程度，“内聚” 指模块内部元素的关联程度。好的设计应满足 “低耦合、高内聚”：
低耦合：模块之间尽量减少依赖，例如通过 “接口” 而非 “具体实现类” 进行交互。例如，服务 A 需要调用 “支付功能” 时，不应直接依赖AlipayService（具体实现），而应依赖PaymentService接口，后续若需要切换为微信支付（WechatPayService），只需替换实现类，无需修改服务 A 的代码。
高内聚：模块内部的逻辑应紧密围绕其核心功能，例如 “订单模块” 内部应包含 “创建订单、取消订单、查询订单” 等所有与订单相关的逻辑，避免将这些逻辑分散到多个模块中。 - 数据结构与算法选择
数据结构和算法是代码的 “肌肉”，选择合适的数据结构和算法能显著提升代码的性能和效率。书中并非深入讲解复杂算法，而是强调 “根据场景选择合适的工具”：
理解数据结构的适用场景：例如，数组适合 “随机访问”（通过索引快速获取元素），但插入 / 删除元素效率低；链表适合 “插入 / 删除”（只需修改指针），但随机访问效率低；哈希表适合 “键值对查询”（时间复杂度接近 O (1)），但需要注意哈希冲突的处理。
避免过度优化：书中指出，“过早的优化是万恶之源”。在大多数业务场景中，“清晰的逻辑” 比 “极致的性能” 更重要。只有当代码出现性能瓶颈（如通过监控发现某接口响应时间过长）时，才需要针对性地优化数据结构或算法。例如，在用户数量较少的场景中，用数组存储用户列表完全足够；当用户数量达到百万级时，再考虑用哈希表或数据库索引优化查询。
（三）第 3 部分：代码质量保障 —— 从 “能跑” 到 “可靠”