项目中对于解决方案的思考

项目需求一：构建一个客服中心，一个客户对应多个客户，就会产生多个聊天室。

原本的解决方案： 1、websocket请求整合为一个公共方法/类，这是比较合理的一个思路 2、构建一个对象，用于存储不同房间的聊天记录（不太合理） 3、构建一个对象，用于存储不同房间的人员信息（不太合理） 4、因为该项目的每个聊天室都需要建一个websocket连接(本身就不合理)，所以又构建了一个对象，用于存储不同房间的websocket实例 产生的问题： 切换房间的时候，页面不变的，只是改变数据。所以，切换房间的时候，就需要在多个对象里边去多此查找信息。 关闭房间的时候，也是在多个对象里边去删除修改信息。这个操作显然不适合，而且随着项目的后续扩展，这个弊端会更加明显。 更合适的解决方案是： 构建一个对象，用于存储不同房间的所有信息，合理的数据结构是这样的

let rooms = {
  no_1:{
    member:{},
    msg:[],
    websocke: null
  },
  no_2:{
    member:{},
    msg:[],
    websocke: null
  },
}

项目需求二：拖拉拽配置列表页面，生成基于element-ui的列表页面

拖拉拽功能的解决方案： 1、使用HTML5的drag属性，独立包装一个拖拉拽的类。 好处是：用原生会更加灵活，可以随意配置各种功能；坏处是：包装这个类可能要很久，考量到自己的实力，写得不会比vuedraggable这个库更好。 另一方面，做出这个尝试的原因，也是不太能看懂vue-draggable的文档，所以，有些偷懒了。 2、使用vue-draggable库，这个选择显然是对的。虽然看这个库的文档，包括英文文档，用了较长时间，但总体的时间花费，是比方案1的时间花费更少的。 用于配置展示的列表，是用原生Html元素写一个虚拟的/假的，还是直接在element-ui上进行操作？ 1、一开始是直接在element-ui的table上进行操作，但是遇到了一个问题，table-column列不能拖拽排序。于是转为尝试原生Html,解决了列的排序问题。但是写到后面，产生了额外的问题，el-table那么多的api,我都要一个一个地在原生Html上实现吗？ 2、重新转为el-table，table-column列的排序问题，在侧边栏重新构建一个简单的dom，再进行拖拽排序，改变数据后映射到table中。

这两个需求中，判断解决方案的标准就是时间成本、后续拓展。 其实后续拓展也最终会计算为时间成本，所以，主要标准还是最终的时间成本。

当然，有些需求的主要标准会是性能，AB两种解决方案，A方案的时间成本稍微高一些，也应该选择A方案。