这是我参与「第四届青训营 」笔记创作活动的第2天
一、本堂课重点内容：
-
- 架构面临的问题 全新业务.历史包袱．技术嫡增．信息流通
-
- 常见的架构手段 业务抽象．分而治之标准规范.组织管理
-
- 架构演进的例子 保持重构．迭代升级 应对衰退
-
- 成为优秀架构师 解决问题．技术储备.贴近业务．热爱编码．始终学习
二、详细知识点介绍：
- 架构面临的问题
期望高
- ·良好的顶层设计，从上到下有统一的认知
- ·遵循共同的规范，写出让人舒适的代码
- ·有没有“—劳永逸”的设计,可保基业长青
- ·什么时候能从架构工作中找到成就惑
责任大
- ·设计不合理:这谁写的，看小爷我推到重来
- ·使用不规范:这压根就不该这么用
- ·逻辑太晦涩:这尼玛谁看得懂
- 编码坑太多:这特么是隐藏技能啊，悄无声息改代码
事情难
- 业务历久弥新,历史包袱警加新的场景。
- 随便动动刀子就拔出萝卜带出泥
- 技术栈层出不穷，老朽学不动了啊
- —方面要保持成熟稳定，—方面要积极探索落地
疗效慢
- 影响复杂度的因子众多，单个因子优化不足以撼动
- 没有一年半载，—波治理搞不下来
- 没有特效药，长期在隐隐作痛中前行
- 往往也只是开了一个“方子”，想要根治得长期健身
小结 ·架构设计是为了解决特定领域不同发展阶段的业务问题·不同领域的架构有明显的技术差异，但也有很多相似性·架构不仅面临技术挑战，还要应对组织业务膨胀的嫡增·移动端需要利用有限的设备资源设计符合小屏幕的架构
- 常见的架构手段
架构模型优点 缺点
MVC
- 模块职责划分明确。主要划分层M,V,C三个
- View和Controller容易膨胀
- 模块，利于代码的维护
- View与Model没有完全分离
MVP
- . View与Model完全分离，可以修改视图而
- ·页面逻辑复杂的话，相应的接口也不影响模型，
- 交互都发生Presenter会变多，增加维护成本
- Presenter 与View的交互是通过接口来进行
- 的，方便单元测试
MVVM
- . ViewModel与View的耦合更彻底，
- ·数据绑定使得程序较难调试，因为
- ViewModel只负责处理和提供数据
- 数据都是自动更新到UI
- . View Model里面只包含数据和业务逻辑，
- 没有U，方便单元测试
直接依赖:一个对象A要完成其功能,通常需要依赖于其他对象B、C等,其具体的实现方式就是在对象A中构建(new)其所依赖的对象B、C等,这就相当于A控制了它所依赖的对象、C。
控制反转:打破A直接控制B这层关系，B对象的生命周期交由loC容器来控制，A不用再去寻找和初始化(控制)其所依赖的B、C了，只用等着loC容器的投喂就可以
小结 ·不同架构手段的共同目标是高内聚低耦合·找到适合业务场景的架构而不是炫技滥用.—个复杂的系统是多种架构模型的组合体
- 架构演进的例子
- 表现层:接收用户输入，获取数据，呈现界面
- 业务层:处理业务数据，数据流转，安全检查
- 持久层:提供数据的增删改查能力
- 存储层:按照特定的格式存储数据
小结 ·架构随业务发展由简单变得复杂是规律·没必要最初用复杂架构来解决简单问题·需要用规范持续重构来对抗代码的腐朽
- 成为优秀架构师
定义问题→确定架构→方案落地→结果复盘
亨利福特说，如果我问客户需要什么，他们会告诉我，他们需要一匹更快的马。从亨利福特的这句话，我们可以提炼出一个最直接的问题:客户需要一匹更快的马。立足这个问题本身去找解决方案，可能永远交不出满意的答卷:寻找更好的品种，更科学的训马方式。 思考问题背后的问题，为什么客户需要一匹更快的马?可能客户想要更快的日常交通方式，上升了一个层次后，我们立刻找到了更好的解决方案:造车。 我们不能只局限于问题本身，还需要看到问题背后的问题，然后才能更容易找到更多的解决方案。
三、实践练习例子：
四、课后个人总结：
清楚地认识了客户端架构设计及应用的技术知识，对于常见架构手段的理解还不够，接下来还是要巩固并勤于编码
