关于清单表格项目反思

前言

看了下gitlab的提交记录，从11月加入璇玑清单组开始，到现在已经4个月的时间，到昨天 （2022/3/11）我疲于应付发布前的bug，当全部搞完上线到beta后在下班的路上我猛然警醒，这个项目已经处于很难维护的程度，不管是开发新功能还是修bug，都已经举步维艰，每加一个新功能都因为前面的技术债造成不可预料的bug，每修一个bug都可能产生其他的bug。明明开发、测试人员都好像很负责，可为什么会造成现在的情况呢，我总结如下：

主要原因：

1. 低估项目的复杂性，缺少dev Design，直接代码一把梭哈，留下大量的技术债
2. 没有高复杂项目的经验

前端

技术选型问题

sotre

使用简单的useContext+useReduce，在开发后期就发现该方案最致命的缺点：缺少衍生属性，造成的问题：

1. store存入大量衍生属性，使得store非常臃肿，每次更新单个属性，就必须要把依赖的衍生属性全部更新。

举个例子，选中单元格：

{
    "role": "cell", // cell：代表当前选中的哪一种类型，cell:高亮单元格,row：高亮整行，col：高亮整列
    "current": [9, 1], //当前选中的高亮单元格行、列位置
    "cellBaseInfo": {
        "width": 159,
        "height": 23
    },//当前选中单元格的宽、高。
    "selectNum": 10, //批量选中单元格的数量
    "shift": [[9,1],[13,2]]//批量高亮单元格矩形中左上角和右下角的行、列位置。
}

那这些属性是否都具备原子性呢。其实只有shift （当然shift也存在问题，正确的应该是保存id，后面会讲）具备，其他的属性都属于衍生属性：

{
    "role": "cell", // shift与表格行、列的length比对获得。
    "current": [9, 1], // shift[0]获得
    "cellBaseInfo": {
        "width": 159,
        "height": 23
    },// shift[0]与表格行列属性比对获得
    "selectNum": 10, //shift计算获得。
    "shift": [[9,1],[13,2]]//批量高亮单元格矩形中左上角和右下角的行、列位置。
}

但是当我需要更新属性时，就必须要把这些衍生属性计算后一起更新到store里。

表格

当时的技术选型，结论是在公司的table组件上做。可现在来看值得商榷，只用到最基本的table元素，里面的表头、列都进行了重写，且对后面的性能埋下隐患。

也许可以使用：

1. 每个单元格用div浮动显示。

优势：

性能优化。

1. canvas实现。

功能函数缺乏封装

表格里一个功能有很多入口，而现在很多功能都没有进行封装，而是把相同的代码遍布在每个需要使用的地方。

选中单元格举例，原本以为只有鼠标操作需要更新属性。后面随着功能迭代，更新的场景越来越多：

1. 从父表返回子表。
2. 切换表。
3. 撤销、重做。
4. 通过输入坐标，选中单元格。
5. 修改行列属性。
6. 粘贴。

没有抽象为组件

todo

性能问题

虚拟滚动：

1. 没有使用dom回收
2. 没有提前考虑撤回功能
3. 数据同步问题
4. 数据更新问题

没有使用websocket

1. 富文本问题

2. 快捷键冲突

   使用栈判断是否处于编辑

3. 方法公用

4. 数据更新后的消息队列

   1. 返回父表后的高亮，位置

5. 富文本问题

6. ts的类型不规范

7. 还好没做协同编辑

8. 交互问题，测试问题

9. 关于样式的选型