superior-lean

Superior Lean

以尽可能少的新增表面积解决完整的问题。精简针对的是解决方案，而不是理解、正确性或验证。

寻找最小责任归属

追踪受影响的流程，并在编辑前检查调用方。按以下优先顺序选择：

1. 如果所需行为已经存在，或提议只是推测，则不做更改；
2. 使用现有的项目辅助工具、类型、组件、配置点或模式；
3. 使用语言标准库；
4. 使用原生框架、浏览器、数据库或操作系统的功能；
5. 使用已安装的依赖；
6. 编写由明确责任方维护的少量本地实现。

一旦找到能够完全满足实际需求且符合代码库的选项，就停止。放错层的代码即使行数更少，也不算更简单。

移除意外引入的机制

审视以下内容是否必要：

• 只有一个实现且没有稳定边界的接口；
• 只用于一种固定产品的工厂；
• 为不会变化的值添加的配置；
• 只给现有 API 重新命名的包装器；
• 为代码库已有的功能创建的平行工具；
• 推测性的扩展点、注册表、标志和迁移脚手架；
• 能用几行清晰、易维护的本地代码替代的依赖；
• 本应通过修复根因解决的重复保护逻辑。

如果删除后行为仍完整，就优先删除。不要为了减少行数，把直白的代码压缩成晦涩的表达式。

必须保留的复杂性

不要简化掉以下内容：

• 明确的用户需求或受支持的兼容性；
• 信任边界上的验证与授权；
• 隐私、身份验证、安全和审计控制；
• 防止数据损坏或丢失所需的恢复机制；
• 无障碍访问与响应式行为；
• 实际的并发、顺序、重试、幂等性或取消保证；
• 物理系统或可变系统所需的校准与调优控制。

验证

证明已删除的机制没有必需的使用方，并确认行为仍然完整。对于非平凡分支、解析器、状态转换、金融路径和安全敏感流程，应使用针对性测试。进行评审时，应区分已观察到的复杂性与假设性的清理，并且只建议有明确收益的更改。

说明哪些内容变得更简单、哪些内容经过权衡后予以保留，以及未来什么实际情况会成为增加复杂性的理由。

署名

此技能是对 Dietrich Gebert 的 Ponytail 进行大幅改写后的版本。请参阅 LICENSE。