今天是孤尽老师训练营第一天,听了老师的直播课程,感觉老师讲的一些东西都是以前没接触到
的,有些问题原来可以用另一种思维方式去思考,有一些细节方面的东西感觉自己在平时工作中都
没注意到,感觉知道的越多,才发现不会的也越来越多,今天也写下自己对这次课程的心得和体
会。
一、需求分析
1、定义:
理解和挖掘用户的诉求,以及背后的逻辑,转化成可行性的分析结果。从非结构化到结构
化,确定系统的职责、模块的过程,有逻辑的把需求转换成产品可以描述的功能。
2、需求分析需注意的三点
- 边界:哪些数据已经有了,哪些模块用已经有的,不能对需求扩的无限大
- 用户故事:从用户的角度出发实现场景化
- 用户路径:用户从一个功能点的开始到结束最短的路径,用户路径越短越好
3、伪需求、权利需求
伪需求:没有调研、没有目标、没有逻辑的无脑需求
权利需求:老板或者强势业务方的需求
4、问题的分层
用户问题、业务问题、产品问题、技术问题为四个分层,一般开发人员都是拿到自己的需求之
后对分到自己手中的需求对需求文档进行分析后就进入开发阶段,这块感觉后续应该在开发需求之
前,站在这四个问题的层面上去结合自己的需求进行进一步的分析,这感觉这块还是需要去进一步
加强。
注:DRY原则:一切重复的代码都可以抽象
重复代码的危害性:不一致性、代码冗余、易出BUG
二、七大设计原则
共同点:提示软件的扩展性,可维护性是抽象思维和归纳思维的集中体现。
1、单一职责:一个类只负责一个功能领域中的相应职责(最简单的,但确实最难的)
2、里式替换原则:所有引用基类(父类的)地方都可以用子类来替换,且程序不会有任何的
异常。但是反过来就不行,所有使用子类的地方则不一定能用基类来替代
3、接口隔离原则:每个接口都应只承担一种相对独立的角色,不干不该干的事
4、组合复用原则:尽量使用对象组合,而不是继承来达到复用的目的。
5、依赖倒置原则:要求我们在设计程序的时候尽量使用层次高的抽象层类,即使用接口和抽
象类进行变量的声明、参数类型声明、方法返回类型声明以及数据类型转换等等
6、迪米特原则:不需要关注具体的代码实现,只关注接口本身
7、开闭原则:对扩展开发,对修改关闭
三、架构
1、架构是一种能力,而不是一个职位

2、架构的目的
确定在系统边界、在技术层面上做与不做,个人理解一个系统架构在设计之初,需要考虑司
是以技术为驱动,还是以业务为驱动,系统在后续的发展演变过程中是否对安全性、可用性和可
扩展性都有很好的支撑,避免系统架构的过度设计,在技术方向上有更好的技术选型,此处仅代表
个人观点,可能也有很多表达不是很准确的地方,希望大家可以纠正!
3、如何画架构图
什么是架构图
水平层面上的业务模块加上垂直面上的技术模块互相依赖形成的逻辑结构图,就是架构图
1、搞清楚要话的架构图的类型
2、确认架构图中的关键要素(比如产品、技术、服务)
3、梳理关键要素之前的关联:包含、支撑、同级并列等
4、输出关联关系的清晰的架构图
架构图的好坏
布局、颜色、逻辑
架构图的分类
1、业务架构
2、应用架构
3、数据架构
4、技术架构
传统架构图
物理视图、逻辑视图、开发视图、处理视图、场景视图。
UML
1、定义:统一建模语言,使用图形和符合描述软件模型中的各个元素和他们之前的关系
2、UML的分类:
静态结构图:类图、对象图、包图、组件图、部署图
动态行为图:交互图(时序图与协作图)、状态图、活动图
总结:听完课程感觉自己还欠缺好多东西,好多东西需要学习,知道的越多,不会的也越多,加
油吧,骚年!
本文概述了需求分析的关键技巧,包括理解边界、用户故事与路径,以及识别伪需求和权利需求。深入探讨七大设计原则,如单一职责、依赖倒置,以及架构设计中的决策和绘制架构图。作者分享了自我成长中发现的知识空白和学习需求。
477

被折叠的 条评论
为什么被折叠?



