2021-03-13 初稿，考虑设计文档 2021-05-07 补充，新公司有前端架构了，补充感触

    系统架构（System Architecture）

    软件架构（Soft Architecture）

    近期，我司准备启动新的业务线，作为toG业务，长远看这会成为新的公司盈利增长点，也会逐步铺遍全国。经过产品的调研和需求评审之后，以后端为首进行了技术反讲。

    技术反讲之前，技术部几个后端老哥讨论了系统架构，从肤浅的认识来看，他们从可持续（数据不断挖掘，新需求不断补充）、可拓展（当前架构技术稳定、未来数据上几个量级能够支撑）角度出发，认真考虑基础技术选型、建表、难点分析：着实费心不少。

    前端组类似，屡清业务逻辑，拿原型打眼一看，得到几个关键词：

    • 后端管理
    • 用户管理
    • 表单、表格
    • 可视化

    再用之前的开发经验，大致的开发思路是有了，后续搭个架子，定一下技术栈，过一遍页面分分工就可以开搞了。

    说起来简单，背后也都是长期合作的默契，加上靠谱的几个核心开发做技术规划。

    今天看技术分享，提起了“架构思维”，感觉挺有意思：有些东西需要落实到纸面，也就是落实到《设计文档.readme.md》，方便留存和经验复用。

    内容框架可以考虑以下标题，向里填充：

    • 需求背景，放一放需求文档、原型图。前者文档约定具体实现要求，后者约定业务逻辑
    • 用途范围
      • 几种角色、几种产品
      • 每种产品开发方式
    • 模块设计
      • 和后端差不多，更侧重前端，模块间api交互、组件复用
    • 核心数据结构
      • 产生的数据大致如何组织（我常用的json-schema和vnode）
      • 数据如何流转 store
    • 扩展性保证
      • 后续一定会迭代，准备留口
      • 万一跨端：web electron 小程序
    • 研发提效
      • 经验复用，比如脚手架、组件抽离
    • 运维
      • CI

    说起来，设计文档这个词还是有些陌生，但为每个项目写 readme.md 经验还是有的。

    整一整结构，多储备写架构知识，为的是经验复用。

    画画图。

    遇到一个前端项目，重 package.json 出发，到 index.ts/main.ts 出发走一遍，就大致有数了。