前言
有幸参与孤尽老师的T31课程,借此机会开启自己写作旅程。
T31训练营是一个为期31天的项目课程,从0到1实现一个购票项目。
内容包含需求分析,架构设计,代码实现,代码评审等。
第一天课程主要讲的是项目的需求分析,设计原则,架构图等。
项目简介
T31项目是一个仿12306的购票项目,包含查票,购票,下单,支付,乘客管理,车次管理等模块。
需求分析
需求分析核心思想就是理解和发掘用户的诉求,以及背后的逻辑,转化成可行性的分析结果。从非结构化到结构化,确定系统的职责、模块的过程。
需求分析我认为最重要的是理解需求方想要的东西再进行下一步,否则容易浪费彼此时间。
可以从三个方面来开始考虑:
- 边界:项目需要实现的功能到什么地步
- 用户故事:基于什么原因,想要实现功能
- 用户路径:用户在使用系统时需要经过什么流程
在T31购票项目,主要实现的功能大体可分为以下几个模块:
- 用户注册登录,个人信息管理
- 车票车次车站管理模块
- 下单模块
- 支付模块
设计原则
KISS原则(keep it simple and smile)
DRY原则(Don't repeat yourself)
七大设计原则
- 单一职责原则
- 里氏代换原则
- 接口隔离原则
- 依赖倒置原则
- 迪米特原则
- 开闭原则
- 组合复用原则
架构图
如何画架构图?
1.搞清楚要画的架构图类型
2.确认架构图中的关键要素
3.梳理关键要素之间的关联:包含,支撑,逻辑并列
4.输出关联关系清晰的架构图
架构图分类
- 业务架构图
- 应用架构图
- 数据架构图
- 技术架构图
UML类图六大关系
- 泛化关系:继承关系
- 实现关系:实现接口
- 聚合关系:整体与部分可以分开,关联关系的特例,弱关联关系
- 组合关系:整体与部分不可以分开,关联关系的特例,强关联关系
- 依赖关系:类中使用到对方,存在依赖关系
- 关联关系:业务逻辑的关系,依赖关系的特例
总结
在以前工作中其实并没有太注重各种原则与画图,都是比较随意不规范,在项目的架构上比较杂乱无章。通过这次学习,意识到这一部分还是不可缺少的,短短一天其实已经收获良多,继续努力!