principle-laziness-protocol

精简原则

用最少的代码和复杂度，实现尽可能多的成果。

• 优先删除。 当被要求重构或改进时，先看看能否删除，再考虑添加。
• 保持调用层级扁平。 避免过深的调用链。隐藏大量工作的丰富接口不算深层调用链。如果回答一个问题需要追踪超过 3 个文件或层级，就把它扁平化。
• 集中决策。 不要在多个地方重复做出相同选择。将其设为唯一事实来源，并通过简单的标志传递结果。
• 尽量缩小差异。 用最小的改动解决问题。行数越少越好，胜过“优雅”的样板代码。
• 审视信号传递。 如果任务要求你通过类型、架构、流水线或类似层传递新的信号，先停下来寻找更直接的途径。
• 及时处理细微泄漏。 在细小的传递层、表示泄漏和重复选择扩散之前将其移除。小泄漏会逐渐累积，最终造成持续的协作成本。

检验标准： 如果人类开发者觉得这段代码维护起来很费劲，那它就是糟糕的解决方案。