存储方案和数据结构需要认真地进行设计和评审,沉淀成为文档,生产环境提交执行后,需要进行double check。(评审内容包括存储介质选型、表结构设计能否满足技术方案、存取性能和存储空间能否满足业务发展、表或字段之间的辩证关系、字段名称、字段类型、索引等;数据结构变更(如在原有表中新增字段)等)。
需求分析阶段,如果与系统交互的User超过一类并且相关的User Case超过5个,使用用例图来表达更加清晰的结构化需求。
如果某个业务对象的状态超过3个,使用状态图来表达并且明确状态变化的各个触发条件。说明:状态图的核心是对象状态,首先明确对象有多少种状态,然后明确两两状态之间是否存在直接转换关系,再明确触发状态转换的条件是什么。
如果系统中某个功能的调用链路上的涉及对象超过3个,使用时序图来表达并且明确各调用环节的输入与输出。(时序图反映了一系列对象间的交互与协作关系,清晰立体地反映系统的调用纵深链路。)
如果系统中模型类超过5个,并且存在复杂的依赖关系,使用类图来表达并且明确类之间的关系。
如果系统中超过2个对象之间存在协作关系,并且需要表示复杂的处理流程,使用活动图来表示。(活动图是流程图的扩展,增加了能够体现协作关系的对象泳道,支持表示并发等。)
需求分析与系统设计在考虑主干功能的同时,需要充分评估异常流程与业务边界。
类在设计与实现时要符合单一原则。
谨慎使用继承的方式来进行扩展,优先使用聚合/组合的方式来实现。
系统设计时,根据依赖倒置原则,尽量依赖抽象类与接口,有利于扩展与维护。(低层次模块依赖于高层次模块的抽象,方便系统间的解耦。)
系统设计时,注意对扩展开放,对修改闭合。(极端情况下,交付线上生产环境的代码都是不可修改的,同一业务域内的需求变化,通过模块或类的扩展来实现。)
共性业务或公共行为抽取出来公共模块、公共配置、公共类、公共方法等,避免出现重复代码或重复配置的情况。
敏捷开发是快速交付迭代可用的系统,省略多余的设计方案,摒弃传统的审批流程,但核心关键点上的必要设计和文档沉淀是需要的。
系统设计主要目的是明确需求、理顺逻辑、后期维护,次要目的用于指导编码。避免为了设计而设计,系统设计文档有助于后期的系统维护和重构,所以设计结果需要进行分类归档保存。
设计的本质就是识别和表达系统难点,找到系统的变化点,并隔离变化点。设计模式目的:即隔离系统变化点
系统架构设计的目的:确定系统边界。确定系统在技术层面上的做与不做;确定系统内模块之间的关系。确定模块之间的依赖关系及模块的宏观输入与输出;确定指导后续设计与演化的原则。使后续的子系统或模块设计在规定的框架内继续演化;确定非功能性需求。非功能性需求是指安全性、可用性、可扩展性等。
在做无障碍产品设计时,需要考虑到:所有可交互的控件元素必须能被tab键聚焦,并且焦点顺序需符合自然操作逻辑;用于登陆校验和请求拦截的验证码均需提供图形验证以外的其它方式;自定义的控件类型需明确交互方式。