需求总揽

全局思维，闭环思维，架构师思维

职责

在深入理解业务需求之后，能用软件把业务模拟出来。并且保证稳定执行和后续增长。

注意事项

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

需要项目

B端和编辑器，做前后端分离

biz-editor-fe
biz-editor-server

H5适合做SSR，因为要考虑性能

H5-server

管理后台，做前端分析

admin-fe
admin-server

[注意] 大家都到处嚷嚷SSR，使用还是得分场景。一般来讲，toB的不适合用，toC的适合用。所以，架构设计要考虑成本，要用最简单的方案，不要为了设计而设计

添加时向服务端传递的数据的大致是什么样子

{
    // 作品
    work: {
        title: '标题',
        setting: {/* 一些可能的配置项，用不到就先预留 */},
        props: { /* 页面body的一些设置，如背景色 */},
        components: [
            // components 要用数组，有序结构
            // 单个node要符合常见的vnode格式
            {
                id: 'xxx',// 每个组件都有id，不重复
                name: '文本1',
                attrs: {fontSize: '20px'},
                children: [
                    // 文本内容，有时候放在children，有时候放在attrs或者props，没有标准，看实际情况来确定
                    '文本1'
                ]
            }
        ]
    },
    activeComponentId: 'xxx'
}

layers (图层)使用vuex getter，使用computed计算出来的索引

{
    layers() => {
        store.work.components.map(c => {
            return {
                id: c.id,
                name: c.name
            }
        })
    }
}

基本思路：

每个组件尽量符合vnode规范
用数组来组织数据，有序
尽量使用引用关系，不要冗余

数据流转

核心：B端、C端、管理后台，公用一个数据库

创建作品：初始化一个JSON数据
保存作品：修改JSON数据
发布作品：修改一个标记，仅此而已
C端浏览作品：获取JSON数据，SSR渲染页面
屏蔽作品：修改一个标记，C端来判断

当然，其中C端还有缓存，防止频繁访问数据库

技术方案设计文档

关于技术方案设计文档

为何难写？

没有规范可依
不常写

如何写，技巧：

随性一些，解释一下你要如何做，即可
可以先尝试写一部分代码，捋一捋思路，再来写文档

写设计方案文档是浪费时间吗？

如果你真的想明白了，最多浪费你1-2h时间，不会导致项目延期
如果你写不出来，说明你没想明白，正好暴露了问题

第一周学习笔记