liaosw97 设计原则规约
七、设计规约
1.【强制】 存储方案和底层数据结构的设计获得评审一致通过，并沉淀成为文档。 说明：有缺陷的底层数据结构容易导致系统风险上升，可扩展性下降，重构成本也会因历史数据迁移和系统平滑过渡而陡然增加。
2.【强制】 在需求分析阶段，如果与系统交互的 User 超过一类并且相关的 UseCase 超过 5 个，使用用例图来表达更加清晰的结构化需求。
3.【强制】 如果某个业务对象的状态超过 3 个，使用状态图来表达并且明确状态变化的各个触发条件。 说明：状态图的核心是对象状态，首先明确对象有多少种状态，然后明确两两状态之间是否存在直接转换关系，再明确触发状态转换的条件是什么。 正例：淘宝订单状态有已下单、待付款、已付款、待发货、已发货、已收货等。
4.【强制】 如果系统中某个功能的调用链路上的涉及对象超过 3 个，使用时序图来表达并且明确各调用环节的输入与输出。
5.【强制】 如果系统中模型类超过 5 个，且存在复杂的依赖关系，使用类图来表达并且明确类之间的关系。
6.【强制】 如果系统中超过 2 个对象之间存在协作关系，并需要表示复杂的处理流程，使用活动图来表示。
7.【强制】 系统设计时要准确识别出弱依赖，并针对性地设计降级和应急预案，保证核心系统正常可用。 说明：系统依赖的第三方服务被降级或屏蔽后，依然不会影响主干流程继续进行，仅影响信息展示、或消息通知等非关键功能。
8.【推荐】 系统架构设计时明确以下目标：
- 确定系统边界。确定系统在技术层面上的做与不做。
- 确定系统内模块之间的关系。确定模块之间的依赖关系及模块的宏观输入与输出。
- 确定指导后续设计与演化的原则。
- 确定非功能性需求。安全性、可用性、可扩展性等。
9.【推荐】 需求分析与系统设计在考虑主干功能的同时，需要充分评估异常流程与业务边界。
10.【推荐】 类在设计与实现时要符合单一原则。 说明：单一原则最易理解却是最难实现的一条规则，随着系统演进，很多时候忘记了类设计的初衷。
11.【推荐】 谨慎使用继承的方式来进行扩展，优先使用聚合/组合的方式来实现。 说明：不得已使用继承的话，必须符合里氏代换原则。
12.【推荐】 系统设计阶段，根据依赖倒置原则，尽量依赖抽象类与接口，有利于扩展与维护。
13.【推荐】 系统设计阶段，注意对扩展开放，对修改闭合。 说明：极端情况下，交付的代码是不可修改的，同一业务域内的需求变化，通过模块或类的扩展来实现。
14.【推荐】 系统设计阶段，共性业务或公共行为抽取出来公共模块、公共配置、公共类、公共方法等，即 DRY 原则（Don't Repeat Yourself）。 说明：随着代码的重复次数不断增加，维护成本指数级上升。
15.【推荐】 避免如下误解：敏捷开发 = 讲故事 + 编码 + 发布。 说明：敏捷开发是快速交付迭代可用的系统，省略多余的设计方案，摒弃传统的审批流程，但核心关键点上的必要设计和文档沉淀是需要的。
16.【参考】 设计文档的作用是明确需求、理顺逻辑、后期维护，次要目的用于指导编码。
17.【参考】 可扩展性的本质是找到系统的变化点，并隔离变化点。 正例：极致扩展性的标志，就是需求的新增，不会在原有代码交付物上进行任何形式的修改。
18.【参考】 设计的本质就是识别和表达系统难点。 说明：准确地表达系统难点需要具备：表达规则和表达工具的熟练性、抽象思维和总结能力、基础知识体系的完备性、深入浅出的生动表达力。
19.【参考】 代码即文档的观点是错误的，清晰的代码只是文档的某个片断，而不是全部。
20.【参考】 在做无障碍产品设计时，需要考虑到：
- 所有可交互的控件元素必须能被 tab 键聚焦，并且焦点顺序需符合自然操作逻辑。
- 用于登录校验和请求拦截的验证码均需提供图形验证以外的其它方式。
- 自定义的控件类型需明确交互方式。