设计

副标题 / 摘要 大量 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")) 解释与原理 开放接收降低了“因为小差异导致系统失败”的概率。 保守发送则保证你不会向外部传播错误数据。 常见问题与注意事项 会不会掩盖错误？ 会，因此需要告警与监控。 开放接收是否意味着接受所有输入？ 不，仍需严格校验关键字段。 何时不应开放接收？ 安全敏感或金融类场景要更严格。 ...