本学期的助教工作到今天基本上已经圆满结束了，虽然后面还有补给站等事项，2019 年 OO 课程的总体仍然算是迎来尾声。相比往届的 OO 课程，今年的 OO 进行了许多根本性的改革，例如大刀阔斧更改互测机制、增加 bug 修复机制、增加研讨课等一系列举措，本质是为了尽可能的培养同学们对于面向对象这个概念的进一步理解，减少为了应付课程糊弄一份代码并在测试之后就丢弃的往年现象。就最后的教学结果来看，我认为这届的改革成功了95%，这不仅仅反应在某些社交平台上同学么对于今年课改工作的肯定，也体现在今年的总体成绩相比往年有了一定的提高——即使是在任务变得更复杂的情况下。当然，助教间分工的明确也是促成课改成功的关键之一，而我在本届助教组中担任的主要职责是互测及 bug 修复方面的数据管理与统计，下面来说我在课程进行中曾经遇到过的一些问题。

　　本届课程的学生数据管理使用的是 MySql 数据库，而与我负责部分相关联的是以 bug_fix 为前缀的几张表以及以 mutual_test 为前缀的几张表。很明显，以 bug_fix 为前缀的表记录着学生们在 bug 修复方面的多项数据，而以 mutual_test 为前缀的表记录着互测方面的数据。根据我们的分数计算规则，互测的最终得分由 bug 奖励分（找出别人的），bug 惩罚分（被人找出的以及长时间未修复的）和活跃度惩罚分三部分，其中尤以 bug 惩罚分计算较为复杂，其计算公式为 bug惩罚分=未被修复的 bug 数 \ times \ alpha + 非合并修复对应的 bug 数+合并修复次数（其中 alpha = 2）。对于未修复的 bug 数，我们可以查看 bug_fix_data_points 这张表中的 status 来判断，合并修复的次数以及非合并修复 bug 数（solid）则通过连接 bug_fix_submits 和 bug_fix_run_test_results 这两张表来共同查询得到。特别的，在 bug_fix_submits这张表中，由于设计上的一些问题，多数同学会在每次 bug 修复提交开始的时候被系统自动创建一次提交，哪怕这位同学在这次作业中没有需要修复的 bug 也会出现这一次提交次数，在最后总评算分是就容易为多数同学增加十次 solid 提交，所以必须要仔细检查初始提交的创建问题，以防最后导致整体互测分数偏低。另一个需要注意的是在 mutual_test_run_test_results 这张表中，有一个名为 hack_success 的数据项，要重点注意该数据项代表这位同学是否被 hack 成功而非是否 hack 别人成功，这点同样值得一定的注意。

　　整体上来讲，由于bug修复部分设计数据库的反复查询与验证，在确定最终成绩时一定要多次 check，特别是对于分数出奇高和分数出奇低的同学，一定要查到每一个人每一次的提交情况，确认无误后再算入总成绩。总之，管理数据是一件很枯燥很需要耐心的事情，但也是影响同学们成绩的主要因素，所以花时间在数据整理上还是飞航有必要的。