8.26第一讲
项目介绍
T31
用户的诉求:不是kpi的诉求
边界:
用户故事:买票 候补 接朋友查到达的时刻,场景
用户路径:我们和系统的触电 路径要尽可能的短
用户故事和业务场景有相似处也有差异,前者要包括对用户真实需求的甄别过程。
Eg: 拍照输入密码 点击拍照
对于伪需求要分清提需求人所占的位置,进行相关的调研得出可行性报告如果达到一定的比例,例如40%就要慎重考虑是否可行
对于老板提的需求要明确是否可行,注意沟通的方式,给出解决方案,提出风险预警
作业pmf
mock 视频认证
对于不能实现的直接赋值为ture
解决的是用户的问题
逆向流程也需要考虑,架构是一种能力不是一种职位
协调能力好的心态很重要
尽量不要出现重复代码,大量出现重复的代码就可能出现迭代更新修改时候的遗漏
听起来简单做起来不容易,知道和做的差距是非常大的,过程里面吧七大原则内化于心
首先是掌握设计原则的名字,其次才谈的上掌握和怎么使用
单一原则
在发送message的接口中添加一个发送maill的方法,违反了单一原则,不方便别人维护,扩展
里氏代换原则
父类能出现的地方子类一定能出现
接口隔离原则
同意退款是人工审批的缓解,于接口的付款退款无关
组合服用原则
继承会导致接口污染出现其他service的方法
宪法不会依赖地方法律,但是地方法律就要看是否符合宪法
只知道结果,不知道怎么实现的
前后关系,视觉元素的中心,跳色是重点,灰色是非重点
业务上是否可行
统一的建模语言,方便不同公司的人进行交流
组合强 ,聚合若
聚合 显示器 和笔记本
组合 人脑和身体
聚合 可以交给不同的人做
组合 只能一个人做否则需要调用的 组合不能乱分解
架构是一种能力,而不是一个职位,架构需要确定系统边界,在技术层面上收否要做这件事,判断需求是够合理,是否上伪需求
确定各模块之间的需求关系具体是组成还是聚合,分配任务,考虑程序的健壮性,明确功能需求和非功能需求,非功能需求指的是安全性、可用性、可扩展性。