Design

副标题 / 摘要 大量 if 判断会让代码难以维护。本文通过职责拆分与多态消除条件分支。 目标读者 需要重构遗留代码的工程师 关注可维护性的团队 学习设计原则的开发者 背景 / 动机 if 分支常常是“规则塞在一起”的信号。 当规则变化时，分支会持续膨胀。 核心概念 职责拆分：让对象承担自己的规则 多态：用对象替代条件判断 空对象：避免 null 判断 实践指南 / 步骤 识别 if 判断的业务规则 为规则创建对象或策略 用空对象替代 null 分支 把规则拆成可测试单元 可运行示例 class Foo: def do(self, file): return f"process {file}" class NullFoo(Foo): def do(self, file): return "" def get_foo(repo, key): return repo.get(key, NullFoo()) if __name__ == "__main__": repo = {"a.xml": Foo()} foo = get_foo(repo, "a.xml") print(foo.do("a.xml")) 解释与原理 把“有/无对象”的判断交给对象本身（Null Object）， 可减少 if 分支并提升可读性。 ...

副标题 / 摘要 设计关注局部方案与细节，架构关注系统整体与演进方向。本文给出清晰的区分框架。 目标读者 需要做系统规划的工程师 参与架构评审的团队 对概念区分有疑问的开发者 背景 / 动机 设计与架构常被混用，导致职责不清或评审混乱。 明确边界有助于协作与决策。 核心概念 设计：局部实现与细节 架构：系统边界与演进路径 抽象层级：架构更高、设计更低 实践指南 / 步骤 先定义系统边界与约束（架构） 再落地模块与实现细节（设计） 用评审分别检查“方向”和“细节” 保持架构稳定、设计可演进 可运行示例 # 简化“架构 vs 设计”的层级示意 architecture = {"services": ["user", "order"], "db": "postgres"} design = {"order": {"schema": "orders(id, user_id)"}} print(architecture) print(design) 解释与原理 架构关心“系统如何划分与协作”，设计关心“模块怎么实现”。 架构为设计提供约束，设计为架构实现落地。 常见问题与注意事项 架构是不是设计的一部分？ 可以理解为高层设计。 架构是否必须固定？ 核心边界应稳定，细节可演进。 什么时候需要架构师？ 系统规模变大、跨团队协作时。 最佳实践与建议 把架构决策记录成 ADR 设计文档聚焦可实现细节 区分“方向评审”和“实现评审” 小结 / 结论 设计与架构的差别在于范围与抽象层级。 清晰边界能让团队协作更高效。 参考与延伸阅读 Software Architecture in Practice Architecture Decision Records 元信息 阅读时长：6~8 分钟 标签：设计、架构 SEO 关键词：设计 vs 架构 元描述：解释设计与架构的区别与关系。 行动号召（CTA） 尝试把一个项目的决策分成“架构层”和“设计层”分别记录。

副标题 / 摘要 数据抽象的价值在于“更换实现不影响调用方”。本文展示违反抽象的例子与修复方案。 目标读者 关注代码可维护性的工程师 设计模块边界的团队 学习设计原则的开发者 背景 / 动机 当内部实现细节泄露到外部，任何变更都会引发连锁修改。 抽象被破坏会迅速放大维护成本。 核心概念 数据抽象：隐藏实现细节 封装：限制外部依赖 稳定接口：对外提供不变契约 实践指南 / 步骤 识别对内部结构的直接依赖 将访问收敛到接口方法 在接口层处理结构变化 为接口建立测试保护 可运行示例 # 反例：外部直接依赖内部结构 class UserStore: def __init__(self): self._users = [] # 内部结构 store = UserStore() # 外部直接访问内部结构 store._users.append({"name": "Alice"}) # 改为接口封装 class SafeUserStore: def __init__(self): self._users = [] def add(self, name): self._users.append({"name": name}) if __name__ == "__main__": s = SafeUserStore() s.add("Bob") print(s._users) 解释与原理 外部直接访问内部数据结构会强绑定实现细节。 一旦内部结构调整，外部调用必须同步修改。 常见问题与注意事项 私有成员就不会被访问吗？ 语言限制不同，需要靠规范与评审保护。 ...

副标题 / 摘要 设计不仅仅是视觉，功能性与美学需要平衡。本文从工程与产品角度给出取舍框架。 目标读者 产品与设计相关工程师 关注用户体验的团队 想理解设计取舍的人 背景 / 动机 很多产品在追求美观时忽略了核心功能体验。 理解三者关系能减少不必要的返工。 核心概念 设计：解决问题的整体方案 美学：视觉与感受层面 功能性：任务完成与效率 实践指南 / 步骤 先定义用户核心任务 用功能性指标验证设计 在保证可用性的前提下优化美学 用数据评估改版效果 可运行示例 # 简化权重评估 def score(functionality, aesthetics): return functionality * 0.7 + aesthetics * 0.3 if __name__ == "__main__": print(score(9, 6)) 解释与原理 设计是系统层面的解决方案，美学只是其中一部分。 功能性优先能确保产品价值落地。 常见问题与注意事项 美学是否可量化？ 可以用用户偏好与转化率间接衡量。 功能性与美学冲突时？ 优先保证功能性。 如何避免“设计驱动”误区？ 用可用性测试和数据验证。 最佳实践与建议 设计评审先看功能可用性 统一设计系统减少视觉波动 让数据驱动设计迭代 小结 / 结论 设计、美学与功能性必须共同服务于用户价值。 先可用，再美观，是更稳健的路径。 参考与延伸阅读 The Design of Everyday Things Nielsen Norman Group 元信息 阅读时长：6~8 分钟 标签：设计、功能性 SEO 关键词：设计与美学, 功能性 元描述：讨论设计、美学与功能性的关系与取舍。 行动号召（CTA） 挑一个产品页面，列出功能性优先级与可用性指标。

副标题 / 摘要 美学能提升体验，但过度追求视觉可能牺牲可用性。本文讨论如何在美学与功能之间平衡。 目标读者 产品与设计相关工程师 关注用户体验的团队 想理解设计权衡的人 背景 / 动机 所有设计都包含美学元素，但美学不是万能。 当视觉优先于可用性时，体验反而下降。 核心概念 美学：视觉与感受的表达 可用性：完成任务的效率 一致性：视觉系统的统一 实践指南 / 步骤 先定义核心任务流程 在任务完成前提下优化美学 使用一致的设计语言 通过可用性测试验证效果 可运行示例 # 简化“权衡”示意 def design_score(usable, aesthetic): return usable * 0.7 + aesthetic * 0.3 if __name__ == "__main__": print(design_score(9, 6)) 解释与原理 美学提升第一印象与信任感，但不能代替可用性。 最佳体验是“先可用、再美观”。 常见问题与注意事项 美学是否越强越好？ 不一定，过度设计会分散注意力。 美学与可用性冲突时怎么办？ 优先保障核心任务可完成。 如何验证美学效果？ 通过用户测试与转化指标。 最佳实践与建议 用设计系统保证一致性 以任务完成率衡量设计质量 视觉增强要可退化 小结 / 结论 美学是朋友，但必须服务于可用性。 优先解决功能，再优化视觉。 参考与延伸阅读 Don Norman: The Design of Everyday Things Nielsen Usability Heuristics 元信息 阅读时长：6~8 分钟 标签：美学、设计 SEO 关键词：美学设计, 可用性 元描述：讨论设计中的美学元素与取舍。 行动号召（CTA） 挑一个界面设计，列出“美学”与“可用性”各自的改进点。

副标题 / 摘要 “发送要保守，接收要开放”强调协议实现要严格输出、宽容输入。本文解释其工程价值与风险控制。 目标读者 设计协议或接口的开发者 需要提升系统兼容性的工程师 关注系统稳定性的技术负责人 背景 / 动机 系统之间的协作经常出现版本差异或边界数据。 健壮性原则旨在提高兼容性与稳定性，但也容易掩盖错误。 核心概念 保守发送：严格遵循协议输出 开放接收：尽量容忍输入差异 容错边界：兼容但不放弃校验 实践指南 / 步骤 输出严格遵守协议（字段、格式、范围） 输入做宽容解析（大小写、空白、可选字段） 对异常输入记录告警 明确“可容忍范围”的边界 可运行示例 # 允许输入有空白/大小写差异，但输出严格规范 def parse_level(value: str) -> str: v = value.strip().lower() if v in ("info", "warn", "error"): return v return "info" # 容错默认值 def emit_level(level: str) -> str: # 发送时严格规范 return level.lower() if __name__ == "__main__": print(parse_level(" WARN ")) print(emit_level("WARN")) 解释与原理 开放接收降低了“因为小差异导致系统失败”的概率。 保守发送则保证你不会向外部传播错误数据。 常见问题与注意事项 会不会掩盖错误？ 会，因此需要告警与监控。 开放接收是否意味着接受所有输入？ 不，仍需严格校验关键字段。 何时不应开放接收？ 安全敏感或金融类场景要更严格。 ...

副标题 / 摘要 内聚关注“模块内部是否紧密相关”，耦合关注“模块之间是否依赖过多”。本文给出区别与改进方法。 目标读者 需要评估设计质量的工程师 负责重构与模块划分的开发者 做架构与代码评审的团队 背景 / 动机 很多系统难维护的原因不是“功能太多”，而是模块内聚低、耦合高。 理解内聚与耦合，是设计优化的基础。 核心概念 内聚（Cohesion）：模块内部的相关性 耦合（Coupling）：模块之间的依赖程度 高内聚、低耦合：可维护性最佳 实践指南 / 步骤 识别“职责过多”的模块 拆分低内聚模块 减少跨模块直接依赖 用接口隔离依赖 引入依赖注入 可运行示例 # 低内聚示例：一个类做太多事 class OrderManager: def calculate(self): pass def save(self): pass def send_email(self): pass # 改进：拆分职责 class OrderCalculator: def calculate(self): pass class OrderRepository: def save(self): pass class OrderNotifier: def send_email(self): pass 解释与原理 内聚高意味着模块职责单一、变化集中； 耦合低意味着模块之间依赖少、替换成本低。 常见问题与注意事项 模块越小内聚就越高吗？ 不一定，小但职责混杂仍然低内聚。 完全无耦合可能吗？ 不可能，关键是控制依赖方向与数量。 怎么衡量？ 看模块修改是否牵连多处。 最佳实践与建议 一个模块只解决一个问题 把依赖集中到边界层 用接口隔离变化 小结 / 结论 内聚与耦合是判断设计质量的核心指标。 高内聚、低耦合是长期可维护系统的基础。 ...

副标题 / 摘要 设计关心方案与体验，架构关心结构与演进，功能关心“能做什么”，美学关心“好不好看、好不好用”。本文给出清晰区分与落地方法。 目标读者 负责产品与工程协作的开发者 需要做系统设计的工程师 希望减少沟通成本的团队负责人 背景 / 动机 很多团队在沟通时把“功能、设计、架构、美学”混在一起，导致讨论失焦。 明确它们的职责边界，是跨职能协作的前提。 核心概念 功能（Functionality）：系统能做什么，输出什么结果 设计（Design）：满足需求的方案与交互流程 架构（Architecture）：系统结构、组件边界与可演进性 美学（Aesthetic）：视觉与体验层面的感知质量 实践指南 / 步骤 先定义功能边界：输入/输出与业务规则 再做设计方案：交互流程与用户路径 确定架构结构：模块划分、接口与扩展方式 补齐美学细节：视觉层级与一致性 建立协作节奏：设计评审与架构评审分开 可运行示例 下面用一个简单例子展示“功能 vs 美学”的分离： def calc_total(items): return sum(price for _, price in items) def render_receipt(total, theme="minimal"): if theme == "minimal": return f"Total: {total}" return f"*** TOTAL ***\n{total}\n***********" if __name__ == "__main__": items = [("apple", 3), ("milk", 5)] total = calc_total(items) # 功能 print(render_receipt(total, theme="minimal")) # 美学 解释与原理 功能是“正确性”，设计是“可用性”，架构是“可演进性”，美学是“感知质量”。 把它们混在一起会造成目标冲突、决策混乱。 常见问题与注意事项 美学是不是不重要？ 不是，它影响使用意愿与信任感。 架构是不是过度设计？ 不是，架构关注长期演进与成本控制。 ...

副标题 / 摘要 封装不是“把字段设为 private”，而是建立稳定边界，让变化被隔离。本文解释封装的工程价值与落地方法。 目标读者 写业务系统但经常“改一处坏一片”的工程师 希望提升模块边界设计的开发者 负责代码评审和架构演进的技术负责人 背景 / 动机 没有封装，系统就像没有隔间的办公室：任何一个变化都会影响到其他部分。 封装能让变化局部化、减少耦合、提高可读性与可测试性。 核心概念 信息隐藏：内部实现细节不暴露给外部 稳定边界：对外只暴露行为和契约 高内聚、低耦合：模块内紧密相关，模块间依赖最小 实践指南 / 步骤 先定义对外行为：先有接口，再有实现。 隐藏数据结构：不要让外部直接依赖内部表示。 用方法维护不变量：禁止外部绕过规则直接改数据。 把变化集中在模块内部：外部只看到稳定契约。 为封装加测试：通过行为测试保证边界稳定。 可运行示例 class BankAccount: def __init__(self, balance: int): self._balance = balance def deposit(self, amount: int) -> None: if amount <= 0: raise ValueError("amount must be positive") self._balance += amount def withdraw(self, amount: int) -> None: if amount <= 0: raise ValueError("amount must be positive") if amount > self._balance: raise ValueError("insufficient balance") self._balance -= amount def balance(self) -> int: return self._balance if __name__ == "__main__": acc = BankAccount(100) acc.deposit(50) acc.withdraw(30) print(acc.balance()) 解释与原理 封装的本质是 把“规则”放到模块内部。 外部只调用方法，不触碰内部状态，这样就能保证不变量始终成立。 当实现方式变化时，只要接口不变，外部代码无需调整。 ...