记一次 web 上课系统的开发及经验
项目背景
原先公司就有了移动端和 Windows 的客户端，但是老板在 2020 年的时候想搞一个 web 端。于是就让我去调研，一开始是作了个 canvas 画板，然后去调研第三方 sdk（客户端已有的），集成客户端的协议（这时候还是用 json 格式），做了个 demo。
技术方面基本没有问题后，组内就开始投入人力去开发 web 端。但是呢，没有完整的产品文档以及技术文档，我们只能去研究客户端，找产品和开发聊，一边开发一边梳理。搞了一个月不到，别的项目进来了，就搁置了。
然后 2020 年末，老板又决定搞 mac 端的，但是 ios 组没有这个时间。但是 web 不是做了一段时间嘛，electron 又可以跨端，于是 mac 端的开发也交给我们了。
但是呢，客户端他们更新过好几个版本了，协议也改成了 protobuf，不和之前的 json 协议兼容，而且第三方 sdk 没有 electron 版本，一些功能就得和产品沟通需要砍掉。
模块
要分这么几个模块：发单（学生老师的需求接取）、好友、聊天、课程、账单、回放、上课互动。我负责的是上课互动模块和回放模块。
在上课互动中，主要有这么几种功能：
- 老师学生音视频聊天；
- 互动的内容部分：画板绘图、图片视频及 PPT 上传，及略缩图；
- 课程相关信息的展示；
- 礼物互动；
协议
因为之前用的是 json 协议，后面使用 protobuf 后就需要进行处理，所以就用了桥接的办法，抽象了一个 Parser 对象，用于处理协议部分。protobuf 则使用 ts-proto 来转换。
操作逻辑
在上课互动之中，老师/学生的每一个行为都是一个操作，每个操作都会通过协议发送给另一方，但是同一种操作老师和学生的行为会对另一方造成不同的影响（业务如此）。比如说，老师切换页面的时候，学生需要同步，而学生切换页面的时候，老师不会受到印象。
而回放的时候有些操作和实时的时候又有差别，因为回放是可以拖动进度条的。比如播放视频的情况，上课的时候不需要关心视频播放到哪里了，回放的时候就要计算一下。
问题及解决
一开始做 demo 的时候，我并没有想到回放、多页内容的问题，以及老师学生行为的差异，做第一版（web）的时候业务也没有梳理完就急忙开始做了。所以是直接使用 json 协议转换的对象来操作，根据对象的 type 字段来执行操作。
后面做第二版（electron）的时候，也是时间很紧，也没有改变。但是在开发回放功能，以及测试提出了一些关于老师与学生之间差异行为的 bug 时，意识到了这个问题。改 bug 硬着来一开始解决了一些问题，后面就麻烦起来了。
多页内容的切换、回放，以及用户类型交织在一起，逻辑也很散乱，改了一处就要去另外的文件修改另一处。
然后就下决心改变这种境况，评估了一下决定使用命令模式进行重构，然后估算了一下时间发现没有问题，就用周末的时间完成了重构和自测。
经验
遇到复杂的、难以着手的，一半懂一半不懂的，就需要预先梳理完逻辑，急忙去开发反而容易造成很多问题。有条件的话可以进行预先设计，解决一些问题。
重构的话要及时评估，及时重构，随时重构。
