层次和状态：技术评审会的收获

第一次参加公司的技术评审会，收获很多，记录一下。

1. 投屏

投屏是教师端app上传了图片以后，在its客户端可以直接显示出来，还可以显示相关学生的信息，老师能在its客户端授予该学生奖章。流程就像我之前画的一张图：

这张图是我在需求评审会后画的，现在看来流程类似，但是细节还是有一些差别的。

• its服务端加入了消息队列MQ，使得推送消息到its客户端的操作异步化了。

• socket连接是在客户端启动的时候，和远程建立的，通过课次id来标识。但是会有一个老师登陆了多台机器的情况，也就是一个课次id对应了多个连接，处理比较复杂，首先，消息不再是一对一的发送，而是一对多，并且对于响应的成功状态的记录也需要考虑到多种情况，比如3个连接，一个失败，2个成功，那么也不能算成功，因为情况较多，后来考虑分开记录投屏状态。会上没讨论出结果。

• 还有一个更麻烦的问题是，奖章只授予一次，如果投屏到了多个its客户端，怎么保证奖章只授予一次。可以在发授予奖章请求之前控制，通过socket来告诉客户端不发那次请求，也可以请求以后在服务端控制，通过修改奖章接口，还可以在多次修改之后，再次更新修改回来。
  个人觉得通过socket来告诉客户端不发送授予奖章请求的方式不靠谱，因为考虑到网络的问题，还是有可能把请求发出去的，还是要在授予奖章接口做处理，修改接口代码没多大必要，但是加一个拦截器还是可以的。

• 关于响应日志记录在数据库，还是通过埋点来记录，也进行了讨论，最终认为，非业务相关的数据，还是不存入业务数据的库更好。

2.动态换肤

本来是想做动态的换肤，但考虑到时间等因素，这期只做静态的。

主要是样式的管理，使用less变量抽出皮肤相关的变化的部分，并且要考虑全量样式包还是皮肤相关的部分样式包的方式。

考虑到皮肤版本和应用版本的一致，还有皮肤包只包含了考勤、登录和顶部导航栏等不是很多的部分，拆出来的成本并不高。最终决定使用皮肤样式单独维护 + less变量配置的方式。

3. 答题器分组优化

分组相关的各场景的its界面显示和答题器上消息的显示都做了处理，对于答题器通信失败的场景，因为不是代码控制的，没有做处理。

4. 多组件学员姓名替换

多个组件都要显示学员姓名，但是是从不同的接口取得，不同接口的字段不一样，现在要全局替换为一致的。

我们的方案是从store中取，因为登录以后会把studentList存入store，具体的形式有4种：

• vue指令
• mixin
• vuex的getter
• httpProxy适配器

前两种是在组件层处理，第三种是store层处理，最后一种是组件和store不做处理，在更高层屏蔽掉差异，使得返回的数据到达store时已经是正确的。

考虑到将来组件需要经常变更，最终决定在store层做处理，使用getter的方式。

总结

技术方面对于websokect的一个id对应多个连接的情况，响应成功失败状态该如何判断和记录、如何保证只处理一次客户端操作，使用MQ来实现多线程模型下的异步，大范围的代码变更应该在哪一层处理，样式的拆分和变量维护等进行了一些讨论和思考。收获很多。