面试系统-调度
目录
为了解决社团招新面试的混乱问题，社团正如火如荼地开发一个面试系统。我在水群的时候想到了一个关于调度的策略，正好该写博客了，就简单整理一下。
背景与需求
- 人员：面试官、面试者、引导人员。
- 流程：
- 面试者可以报名多个部门
- 可能会存在联合招新，即多个部门一起一面的情况，如前端、后端今年一起一面
最「正常」的调度策略
先不考虑联合招新。
- 面试者在引导房间内签到。
- 每个部门的待面试者，按照签到时间顺序，成为该部门的等待队列。
至于联合招新问题，如果部门A、部门B联合招新，那么可以在报名的时候，就设立一个新的部门C。
新的调度策略
引进「面试房间」的概念。
- 预先在系统内建立好面试房间，设立好筛选规则，如房间1只能由报了部门A或部门B的同学进来。每个房间可以有 n 个面试官，面试官也在房间内线上签到。
- 面试者在引导房间内签到。
- 面试者根据筛选规则、签到时间，自动加入到对应的面试房间的等待队列下。
新策略的核心观念
将面试房间作为一个纯粹的「运行时」，即，一个有着 n 个面试官，和 m 个面试者的环境，他们在进行「面试行为」。
以及 ，原来不同的部门，在程序上看起来有点像「完全不同的对象」。现在他们就是完全可复用的对象（意味着随时创建与销毁），只是运行时的参数不同而已。
优点
乍一看好像差不多是不是？哈哈哈。
但是这样极大地增强了灵活性，把部门和面试地点完全解耦了。如：
- 旧的策略，可能要先定好房间，且不能修改；新策略，可以动态地创建、销毁房间。
- 旧的策略，一个部门只能在一个地点面试，不方便修改；新策略，通过房间的筛选规则，可以实现多个部门在同一个地点面试。新策略甚至可以实现负载均衡，即一个部门同时开启两个房间进行面试。更进一步，之前的筛选规则只是按照部门，也可以弄一些特殊的标签，并且使用 and、or、not 等逻辑运算符，实现更加复杂的筛选规则。
- 新策略减弱了部门的区别，增加了面试官安排的灵活性。以前是通过硬性标明这个教室在面哪个部门，然后这个教室只能坐当前部门的面试官，如果面过了就说明该面试者已经完成了该部门的面试；新策略，房间与房间不是完全不同的个体，没有强行规定某个房间只能由哪个部门的面试官就座，可以实现面试旁听等功能。
- 新增了面试房间的概念，更贴合物理世界的现实，更加直观。以及房间的概念是抽象的，并不是只要同一地点就算一个时间，还可以加上时间的维度。之前是一个部门定死一个房间，但是可能要连续面好几天。有了新的面试房间的策略，可以在每天的面试结束，将房间关掉，第二天开启或新建房间，这样就可以实现每天的面试都是一个新的房间，搜索聊天记录的时候，第二天的聊天记录也会在最上面，而不是第一天的末尾处。（当然新的策略也可以把房间一直开着，即不同天的面试视为同一个房间。新策略提供了极大的灵活性，可以根据实际情况灵活地选择。）
- 新策略的技术实现更简单，更容易多维度统计。在新策略的理念加持下，不同的房间在数据库中的存储结构是一模一样的，只是相应字段不用，全是简单的数据表关联操作。如某个房间的开启时间是几点到几点，筛选规则是什么，有哪些面试官，有哪些面试者，有哪些聊天记录等等。这样就可以很方便地统计每个房间的开启时间、筛选规则、面试官、面试者、聊天记录等等。想统计哪个维度的数据，就在数据库中查询哪个字段就行了。
- （注：筛选规则并不与「该面试者已经参与了某部门的面试」直接绑定。因为面试的过程中肯定会存在面试交互记录（评价、提问等等），只要面试者A与任意房间的属于部门B的面试者有过交互记录，就可以视为A已经参与了部门B的面试。这样就真的把面试房间当成了一个简单的「容纳面试官、面试者，并进行面试的场所」，与其他内容无强绑定关系。引用某人对这个新策略的评价：「有点GPM那味了」）