中国建设银行宁波分行网站,商超网站,外贸公司网站开发,如何做网站页面转载自 阿里巴巴制定了这 16 条
本文内容整理自《阿里巴巴Java开发手册 1.4.0》#xff0c;获取完整版请在公众号后台回复关键字#xff1a;手册。 1、【强制】存储方案和底层数据结构的设计获得评审一致通过#xff0c;并沉淀成为文档。
说明#xff1a;有缺陷的底层数…转载自 阿里巴巴制定了这 16 条
本文内容整理自《阿里巴巴Java开发手册 1.4.0》获取完整版请在公众号后台回复关键字手册。 1、【强制】存储方案和底层数据结构的设计获得评审一致通过并沉淀成为文档。
说明有缺陷的底层数据结构容易导致系统风险上升可扩展性下降重构成本也会因历史数据迁移和系统平滑过渡而陡然增加所以存储方案和数据结构需要认真地进行设计和评审生产环境提交执行后需要进行 double check。
正例评审内容包括存储介质选型、表结构设计能否满足技术方案、存取性能和存储空间能否满足业务发展、表或字段之间的辩证关系、字段名称、字段类型、索引等数据结构变更如在原有表中新增字段也需要进行评审通过后上线。
2、【强制】在需求分析阶段如果与系统交互的 User 超过一类并且相关的 User Case 超过 5 个使用用例图来表达更加清晰的结构化需求。
3、【强制】如果某个业务对象的状态超过 3 个使用状态图来表达并且明确状态变化的各个触发条件。
说明状态图的核心是对象状态首先明确对象有多少种状态然后明确两两状态之间是否存在直接转换关系再明确触发状态转换的条件是什么。
正例淘宝订单状态有已下单、待付款、已付款、待发货、已发货、已收货等。比如已下单与已收货这两种状态之间是不可能有直接转换关系的。
4、【强制】如果系统中某个功能的调用链路上的涉及对象超过 3 个使用时序图来表达并且明确各调用环节的输入与输出。
说明时序图反映了一系列对象间的交互与协作关系清晰立体地反映系统的调用纵深链路。
5、【强制】如果系统中模型类超过 5 个并且存在复杂的依赖关系使用类图来表达并且明确类之间的关系。
说明类图像建筑领域的施工图如果搭平房可能不需要但如果建造蚂蚁 Z 空间大楼肯定需要详细的施工图。
6、【强制】如果系统中超过 2 个对象之间存在协作关系并且需要表示复杂的处理流程使用活动图来表示。
说明活动图是流程图的扩展增加了能够体现协作关系的对象泳道支持表示并发等。
7、【推荐】需求分析与系统设计在考虑主干功能的同时需要充分评估异常流程与业务边界。
反例用户在淘宝付款过程中银行扣款成功发送给用户扣款成功短信但是支付宝入款时由于断网演练产生异常淘宝订单页面依然显示未付款导致用户投诉。
8、【推荐】类在设计与实现时要符合单一原则。
说明单一原则最易理解却是最难实现的一条规则随着系统演进很多时候忘记了类设计的初衷。
9、【推荐】谨慎使用继承的方式来进行扩展优先使用聚合/组合的方式来实现。
说明不得已使用继承的话必须符合里氏代换原则此原则说父类能够出现的地方子类一定能够出现比如“把钱交出来”钱的子类美元、欧元、人民币等都可以出现。
10、【推荐】系统设计时根据依赖倒置原则尽量依赖抽象类与接口有利于扩展与维护。
说明低层次模块依赖于高层次模块的抽象方便系统间的解耦。
11、【推荐】系统设计时注意对扩展开放对修改闭合。
说明极端情况下交付的代码都是不可修改的同一业务域内的需求变化通过模块或类的扩展来实现。
12、【推荐】系统设计阶段共性业务或公共行为抽取出来公共模块、公共配置、公共类、公共方法等避免出现重复代码或重复配置的情况。
说明随着代码的重复次数不断增加维护成本指数级上升。
13、【推荐】避免如下误解敏捷开发 讲故事 编码 发布。
说明敏捷开发是快速交付迭代可用的系统省略多余的设计方案摒弃传统的审批流程但核心关键点上的必要设计和文档沉淀是需要的。
反例某团队为了业务快速发展敏捷成了产品经理催进度的借口系统中均是勉强能运行但像面条一样的代码可维护性和可扩展性极差一年之后不得不进行大规模重构得不偿失。
14、【参考】系统设计主要目的是明确需求、理顺逻辑、后期维护次要目的用于指导编码。
说明避免为了设计而设计系统设计文档有助于后期的系统维护所以设计结果需要进行分类归档保存。
15、【参考】设计的本质就是识别和表达系统难点找到系统的变化点并隔离变化点。
说明世间众多设计模式目的是相同的即隔离系统变化点。
16、【参考】系统架构设计的目的 确定系统边界。确定系统在技术层面上的做与不做。 确定系统内模块之间的关系。确定模块之间的依赖关系及模块的宏观输入与输出。 确定指导后续设计与演化的原则。使后续的子系统或模块设计在规定的框架内继续演化。 确定非功能性需求。非功能性需求是指安全性、可用性、可扩展性等。 本文内容整理自《阿里巴巴Java开发手册 1.4.0》获取完整版请在公众号后台回复关键字手册。
