之前在growingio（一个toB的企业），被他们对待客户的态度所震撼。客户成功团队除了主动的去沟通以外，还会对不同的沟通对象，针对他的岗位和职责范围制定沟通的方案，更会在沟通之后把沟通的阶段性成果发给双方。我觉得这样的沟通（主动沟通，确定沟通范围，总结沟通结果）是很有效的。我们自己内部也可以用起来。

总结一下，今天的会议主要分为三部分：

• 线上答题器相关bug复盘
• 代码规范和格式化问题
• 考勤和纪律树相关代码设计复杂、代码重复的问题

线上bug复盘

会议人员：前端、测试、产品
会议内容：主要是针对上周五发版后，周日老师反馈给教研，教研反馈给技术的一个答题器相关bug的复盘。问题原因经过分析后是课件的问题，导致答题器被占用没有释放。
会议成果:经过分析觉得是测试的回归范围没有覆盖到的原因，得出的调整方案是：
1.需求的变更，技术方案的变更要同步测试
2.同时尽可能多的覆盖课件各种类型
而且还决定了接下来引入一个线上代码错误监控的工具。

代码规范和格式化问题

会议人员：前端
会议内容：针对代码中有没必要的换行（每个逗号，每个尖括号换一行）以及代码格式化后很难看的问题进行讨论。
会议成果：
1.引入eslint，加上git hook
2.永兴之前的前端规范可以借鉴。

考勤和纪律树相关代码设计复杂、代码重复的问题

会议人员：前端
会议内容：针对考勤页面中纪律树相关代码写的太复杂，以及和其他模块有重复的地方的问题进行讨论。
会议成果：1. 理清了纪律树的状态和通过状态计算出的一些值，并且分析出了所有引起状态变化的交互。决定分两层来维护，向下单向依赖，必要的时候可以引入一个外观模式。

2. action的handler可以用作service层，所有的业务逻辑移到这里面来。
3. 之后讨论了从具体问题抽象到通用的方案的思路，和从通用的方案出发解决具体问题的两个思考方向。

我的一些想法

• 其实vuex就是一个命令模式 + 观察者模式，所以可以应用这个模式的地方，都可以用vuex来实现。也可以说只要实现了命令 + 观察者，那就是一个vuex。代码中service层的代码可以放到action handler，不进行具体的耦合，通过action type来对应。

• 网络错误的默认处理要加上，放在httpProxy里

• 项目引入线上错误监控工具

• 项目引入git hook + eslint + 格式化

• 代码要层次化模块化，从设计原则来说要 依赖倒转、职责分离。