[微前端] 架构前期准备
架构师分类
系统架构师, 应用架构师, 业务架构师
系统架构师
从系统的维度, 负责整体系统的架构设计. 主要是基础服务和各系统间协调, 着眼全局. 比如关注负载, 可靠性, 伸缩, 扩展, 整体项目切分, 缓存应用等方面的基础架构设计.
应用架构师
从应用程序的维度, 负责某个应用的技术架构, 主要偏业务系统. 关注理解业务, 梳理模型, 设计模式, 接口, 数据交互等方面.
业务架构师
从业务流程的维度, 关注某一个行业, 业务的领域分析, 获取领域模型, 最终获得系统的模型. 也可以叫业务领域专家, 行业专家, 产品咨询师, 资深顾问
技术前期准备
技术选型
社区氛围, 发展规模, 未来发展趋势, 与当前团队的契合度, 执行成本, 维护和迁移成本, 执行效率等内容的调研和报告.
技术优化
在架构发展过程中, 可能会存在一些有悖于当前架构设计的实现, 造成了架构发展阻塞, 所以需要进行架构优化, 使架构设计的适应性更高.
架构优化
比如所有的函数都放到一个文件中, 不利于代码书写和查错, 就需要按照功能来划分, 比如 router 文件夹, lifecycle,store 文件夹这样划分
架构不是一蹴而就的, 在业务发展过程中, 架构也在不断演进. 对架构设计进行实时调优, 使架构优化成为常态化. 通过不断的调整架构实现, 改进初始架构中设计的不足, 补足短板.
技术债务
技术债务产生原因
开发过程中因为时间紧迫导致的实现不合理
暂时没有想到更好的实现方式而妥协的版本, 比如刚开始使用 if ... else 实现
架构设计前期没有考虑到的细节. 比如项目刚开始组件层级比较浅, 使用 props 传递参数还 ok
不合理的交互设计, 导致技术实现复杂
旧功能文档缺失, 无正确拓展, 修改和兼容旧功能, 导致上线后问题剧增.
不修复可能产生的后果
修复变重构
影响开发速度
如何解决避免这种问题
优秀的架构设计是基础
必须能够有效处理当前需求可预见的情况, 对于未知的, 可能出现的特殊情况, 很小的改动就能解决问题
根据业务, 进行合理的项目拆分, 尽量的代码解耦
必须有日志模块, 操作日志, 错误日志, 业务日志等
良好的技术培训和传帮带能力
让每一位开发者可以从更深一层次理解自己所需要实现的功能
从最开始的代码规范, 到熟悉业务, 最后再到编写文档
充分的技术方案可避免一部分技术债务的产生
与他人的 code review
崩溃预防
架构崩溃是严重的架构设计事故, 也是我们需要预防的关键所在
对脏数据进行兜底和检验
单元测试
崩溃报警
自动化测试
更广的灰度触达
--------------------------------
系统重构
架构不是永恒不变的. 架构也是具有生命周期的, 也会经历初生, 发展, 巅峰, 衰弱, 消亡的过程
什么是重构
对软件内部结构的一种调整
重构目的:
在不改变软件可观察行为的前提下, 提高其可理解性, 降低其修改成本
重构理念
运用大量微笑且保持软件行为的步骤, 一步步达成大规模的修改
重构流程
确定问题点, 确定重构功能和范围 --> 旧架构设计和逻辑梳理 --> 稳定性保证 --> 性能保证 --> 需求过程中的冲突问题