需求分析:架构师的思维分析项目需求(浅层需求、深度需求、需求总览)

一眼能看到的需求是浅层需求,比如说:登录,创建作品,发布

不容易一眼看到,却很重要的需求是深层需求,比如说:作品恢复、转赠、统计

对架构师而言,对业务的深层理解是很重要

流程图:分析项目需求的工具

全局思维、整体思维、闭环思维

目标不是一成不变的,必要时可以调整目标

架构师和普通程序员的区别:架构师必须精准理解业务需求,对业务完全负责

技术永远是为业务服务的,技术是实现业务增长的工具

一定要重视需求和设计的重要性

脱离业务的架构就是耍流氓。架构师必须要深入理解需求、参与需求、看透需求背后的业务本质


架构设计:确定需要创建的项目、项目范围、项目之间的关系

规划业务组件库:考虑组件的拆分和复用

注意事项:

  • 不要关注细节,要看整体,看范围
  • 考虑扩展性(这就需要深入理解业务,否则你也不知道未来将如何扩展)
  • 考虑可行性,不确定的就调研一下
  • 考虑实现成本,不要为了设计而设计,技术要永远服务于业务 —— 永远都要选择最简单的实现方案

架构设计:调项目技术研,确定第三方和自研服务

尽量使用第三方服务,如果没有合适的第三方服务,则自行研发,如:自定义事件统计


架构设计:数据结构设计和数据流转设计

数据设计基本思路:

每个组件尽量符合 vnode 规范

用数组来组织数据,有序

尽量使用引用关系,不要冗余

绘制数据流转关系图


架构设计:编写技术方案设计文档

写代码前要写,技术方案设计文档(架构设计文档),写文档是为了整理思路,从而更好的写代码

  • 需求背景:把需求文档贴上
  • 范围:整体设计,没有细节
  • 模块设计
    • 模块拆分和关系图
    • 各个模块的功能解释
    • 特殊模块说明:组件库、统计服务
  • 核心数据结构设计
  • 扩展性保证
    • 扩展组件
    • 扩展编辑器功能,如锁定、隐藏
    • 扩展页面信息,如增加多语言
    • 扩展其他功能,如大数据分析和计算等
  • 研发提效
    • 脚手架:创建发布
    • 组件平台
  • 运维保障
    • 线上服务和运维服务
    • 安全
    • 监控和报警
    • 服务扩展性:基于云服务,可以随时扩展机器和配置

关于运维保障

做架构师,要一直有风险意识,让你的系统时刻在你的监视之内,这才靠谱。

  • 大厂:有自己自研的运维工具和流程,要熟练使用,并知道负责的接口人
  • 小厂:了解市面上比较靠谱的第三方服务
Copyright © imooc-lego (2020 - present) all right reserved,powered by GitbookFile Modify: 2021-06-27 08:04:56

results matching ""

    No results matching ""