设计/开发原则

设计和开发中必须包含补救措施

不限定补救措施的方式，只要能安全、快速地解决问题。

尊重客观规律

简单到复杂

手动到自动

局部到整体

保持简单

能具体不要抽象

能显式定义不要隐式推断（业务逻辑中）

• 例如，有条件A和条件B，当同时满足A, B时，条件C满足。代码中，检查A, B同时满足时，应当继续检查条件C是否满足，而不是用推断，省略条件C的判断。

降低耦合

1. 模块/代码之间的相互影响限制在尽可能小的范围中

2. 业务逻辑不应该贯穿到所有组件中，应该把业务逻辑限制在尽可能小的范围里

3. 由第二点引出，后续业务逻辑的改动能被限制在小范围里，避免“牵一发而动全身”

4. 模块化，一个组件只做设计中定义的事，不考虑定义之外的逻辑

5. 后期扩展确保默认情况下的逻辑和定义不变，在默认逻辑外添加新逻辑

定义与实现

• 定义应该是简单的。若定义很复杂，表明当前的定义应该被拆分

• 实现可以复杂，用复杂的实现，100%符合定义的要求