Appearance
听评课
该应用面向教务处和广大教师，为他们提供收集公开课全链路信息的能力。
教务处或授课教师可以发起【预约】，以表示发起一个公开课日程，包含听课教师、时间、地点等信息。随后教务处会审核【预约】：如果通过，则向全体听课教师推送该日程。听课教师可以根据【预约】发起【听课】，从而形成对特定公开课的评价。此外还有【课后研讨】和【集体备课】：前者与【预约】逻辑相似，后者可单独发起。
系统会根据评课大数据，绘制出各类课程和每个授课教师的表现雷达图。
使用 限一般用户
面向教务处/授课教师
教务处可以代理授课教师，或授课教师自行发起【预约】：
随后授课教师会收到工作通知，要求上传课件：
WARNING
不要直接点击“拒绝”/“同意”，而是应该点击标题！
面向听课教师
当有新的公开课时，被指定的听课教师会收到工作通知：
可进入听评课，提交【听课登记】或【课后研讨】：
可在“授课课题”里选择公开课，即可自动载入日期时间、听课人、课件等信息。根据实际选择“课型”后现场拍照（限移动端操作）、给出各项评分、填写“课堂亮点”和“改进建议”：
初始化 限管理员
权限配置
设置数据管理员；
全部人员 查看 自定义过滤条件（任一成员字段包含当前登陆人）：【预约】、【听课任务】、【听课】、【课后研讨任务】、【课后研讨】、【集体备课】；
全部人员 查看 全部数据：【公告】；
元数据配置
此应用无需配置元数据。
设计思路 限开发者
应用总共分两条数据干流：以【预约】或【集体备课】开始。
以预约开始
首先由教务处或授课教师发起【预约】，创建时，会生成“流水号”字符串，这是后续唯一判别【预约】的根据。
INFO
设计该应用时，QuickMap 尚未迭代出根据实例 ID 查询实例的方法，因此这里的设计应当被取缔，以减少冗余。
由于不能断言发起者与授课者的关系，因此表内存在两个单选成员字段：“操作员”和“授课教师”。
“日期”、“授课时间”、“地点/班级”都只是为了提供更多信息，可根据需要调整。
操作员提交后，按流程授课教师会被要求上传附件。完成后，由异步回调函数对“听课教师”迭代，持久化“未完成”状态到【听课任务】和【课后研讨任务】。由于这两个表都不直接向用户暴露，因此会带有“@SystemGenerate”字段，用于警告人工不得干预。“已完成”是 [boolean | undefined] 类型，读写值需要注意。
TIP
二元状态持久化的最佳实践是采用枚举，而不是枚举列表。
集成与自动化会监控【预约】的实例化，一旦生成，会对“听课教师”迭代，发送消息通知。如果移除实例，则会根据“流水号”同步移除相关的【听课任务】和【课后研讨任务】。
发起【听课】和【课后研讨】时，用户需要先选择与其相关的“授课课题”（由“任务”决定），这会触发关联信息的自动填充。
在【听课】中，有一张巨大的表格，用于模拟打分表。如果需要增减评级指标，直接复制或移除行、修改计分逻辑即可。如果要修改指标层级，则务必仔细设计（在移动端的体验可能会很差）。
以集体备课开始
【集体备课】与【预约】无关，且业务逻辑十分简单，任何人都可以直接发起。此处不予浪费墨水。