unix-software-design

目的

在涉及模块边界、接口设计、复杂度取舍时，提供 Unix 哲学下的设计原则作为参考，帮助做更简单、透明、可组合的决策。

适用场景

• 设计新模块或服务的边界
• 重构时的拆分与接口规划
• 讨论复杂度取舍、抽象层次

不适用

• 已经是纯实现任务，主要问题不在设计而在落代码
• 只是选一个现成工具或框架，不涉及系统边界和结构
• 若任务主要是「开新坑 / 维护推进 / 读项目提炼」的流程与产出结构，用 spark；本 skill 聚焦边界与原则，不替代工作方式契约

使用方法

1. 先复述当前设计目标、约束与非目标，避免把原则套到错误问题上。
2. 找出真正的设计轴：模块边界、数据表示、接口协议、状态归属、错误处理、扩展点，或部署/运维边界。
3. 只选 2-4 条最相关原则用于判断；不要把所有原则逐条罗列。
4. 给出最小可行设计：优先清晰的数据流和可替换的小部件，再说明哪些复杂度暂不引入。
5. 若有多个方案，用简短表格比较取舍，并明确推荐方案与反悔成本。

输出偏好

• 优先给出可执行的设计建议，而不是抽象格言。
• 明确“现在做什么 / 暂时不做什么 / 以后什么信号出现再扩展”。
• 对复杂方案说明它解决的真实问题；若问题尚未出现，倾向推迟。
• 保留可观察性：建议日志、文本状态、dry-run、检查命令或小型诊断入口。

模块化原则

• Rule of Modularity: 编写简单部件，通过清晰接口连接。
• Rule of Composition: 设计程序以便与其他程序连接。
• Rule of Separation: 分离策略与机制；分离接口与引擎。

简洁性原则

• Rule of Clarity: 清晰优于巧妙。
• Rule of Simplicity: 为简洁而设计；仅在必要时才增加复杂性。
• Rule of Parsimony: 仅在明确证明别无他法时才写大程序。
• Rule of Extensibility: 为未来设计，因为它会比你想象的更快到来。

健壮性原则

• Rule of Transparency: 为可见设计，使检查和调试更容易。
• Rule of Robustness: 健壮性是透明和简洁的产物。
• Rule of Representation: 将知识融入数据，使程序逻辑可以更简单和健壮。
• Rule of Least Surprise: 在界面设计中，始终做最不令人惊讶的事。
• Rule of Silence: 当程序无话可说时，应该什么都不说。
• Rule of Repair: 必须失败时，要尽快大声地失败。

效率原则

• Rule of Economy: 程序员时间昂贵；优先节省程序员时间而非机器时间。
• Rule of Generation: 避免手写代码；用代码生成器（如 protobuf、SQLAlchemy、cargo-generate）替代重复劳动。
• Rule of Optimization: 原型先于优化。先让它工作，再用 profiling 工具定位瓶颈后优化。

多元性原则

• Rule of Diversity: 质疑"唯一正确方式"的所有声明。

补充原则

• 尽可能将数据流设计为文本格式（便于用标准工具查看和过滤）。
• 数据库布局、配置和应用程序协议优先采用人类可读、可 diff 的格式（JSON/YAML/TOML 等），除非性能或兼容性明确要求二进制格式。
• 复杂前端（用户界面）应与复杂后端清晰分离。
• 把策略与机制分开：核心机制保持小而稳定，策略放在配置、规则或可替换模块里。
• 将知识融入数据结构、schema、状态机或声明式配置，减少散落在流程代码里的隐含规则。
• 对输入慷慨，对输出严格；输出应稳定、可解析、可测试。
• 过滤时尽量不要丢弃不需要的信息；保留原始输入或提供可追溯路径。
• 小即美。编写尽可能少做与完成任务一致的程序。
• 技术栈、容器化、CI/CD 等工程化建议只在它们影响模块边界、可组合性或可重复性时提出；不要把它们当作默认答案。