回顾总结，从面向对象助教毕业

前言

助教，英文Teaching Assistant，简称TA，这一名词的出现最早可以追溯到西晋武帝设置国子学的时期。

《晋书.职官志》：“武帝初立国子学，定置国子祭酒、博士各一人，助教十五人，以教生徒。”

《新唐书.百官志三》：“国子学。博士五人，正五品上......助教五人，从六品上。掌佐博士分经教授。”

助教的指责是跟随讲师或教授批改作业，辅助教学，甚至可以被认为是一个教师职称，教师职称从低到高分别是助教、讲师、副教授和教授。

其实在大二上开始就担任了学业与发展支持中心的朋辈辅导师，也是服务同学，每周末串讲知识点，但是和助教还是有些不同。辅导师是根据同学们填写的问卷进行选题，并在周四周五的时间放出当周所直播讲解的内容，同学们可以根据自己的时间安排选择收看直播或者是回放，我们都是对着电脑讲准备好的内容，也没有老师进行指导，按照我们自己的理解去讲知识点和习题。由于每次选题的变化观看的同学和人数也不同，其实讲到后面虽然自己非常激昂但结束还是有一种空虚感，缺少了那种互动。之前也没有尝试过助教这种全新的体验，于是在大二的OO课程结束博客中也写下了自己想成为助教的想法。但是自己的整个学期的表现并不是非常突出，甚至有点*庸，感觉自己当上OO的助教希望渺茫。

大二结束的暑假，意外地在回家的火车上接到了吴老师的电话，经过电话面试回答问题成为了面向对象设计与构造2020的助教团的一员。后来得知我其实错过了助教团的集体面试，是吴老师阅读我的博客注意到我在最后一次总结中有加入助教团的意愿联系我的，实际上以我的成绩集体面试也是完全没有希望的，所以当时接到吴老师的电话除了激动之外，更甚的是感激之情，感激老师给予我这一个机会加入到助教团队。

面向对象的助教工作挺特殊的，提前一学期开始准备，有别于其他的所有课程，从中也可以看出老师们的用心良苦。为了给下一届的同学们更加良好的体验，我们对上一个学期自己的亲身经历开始复盘，总结每个单元的优点与不足，进而修订指导书，甚至考虑是否有替换单元甚至是替换训练目标的需要。

我在团队中的角色其实比较特殊，参与了实验组的实验命题，有时也在文档组帮做会议记录，大多时候是系统组进行数据的分析，此外还承担了纪老师班级随班助教的工作，用蓝头的描述来说像是万金油，哪里缺人跑哪里，以至于这个学期结束时，蓝头还给我开了一个后勤组的仓库，里面存放一些脚本资料。在一学年的助教经历中，确实有些感想，是有用文字记录下来的冲动的。

各个组的那些事儿

文档组真就写写文档？

文档组听起来像是企业中的文职人员，听起来感觉没有什么核心技术，但事实并非如此。文档组作为每次作业指导书的发布，是课程组与学生沟通的直接桥梁。文档组负责指导书的审核与校对，需要从学生的角度去研读指导书中描述不清的地方并进行修订，所以实际上是对技术水*提出了更佳高精尖的要求。此外，每次实验指导书配套的学习资料也是文档组负责，需要给同学们的实验进行铺垫，以免在接触新知识的时候短时间内难以接受，所以在有限的文档中，搜集什么资料、收集什么内容是对文档组很大的挑战。

在后两个单元引入了JML和UML的学习内容下，同学们对指导书存在的疑问越来越多，这也使得我们反思，是否需要新开辟一个"验题组"，对指导书的内容进行更加深层次的校对。刚才说到文档组也进行了审核，那么文档组的工作和验题组的工作区别在哪里呢？我个人认为区别在于是否动手写代码。文档组目前的审核主要是靠脑子去想，脱离了动手去做，很多时候可能改了一些地方之后，脑子觉得这个指导书读通顺了，但也仅仅是读通顺了，真正落笔的时候可能会在某些判断语句上出现理解的分歧，所以如果要成立验题组，其在助教团队中应该是处于文档组之后，并且和文档组之间形成一个往复的循环，直到验题组通过指导书不需要其他的提问就能够通过所有测试用例，这时指导书才达到一个出口标准，发放给学生，如果用示意图来表示的话大概是这个样子：

实验组这锅好像还挺大

首先非常自责也非常抱歉这一个学期的实验给大家带来的体验并不是特别好，我是负责第三单元JML单元的实验，也就是根据JML填代码和根据GC背景填JML的单元。说实话，这一个单元在收到你们的反馈之前我还是特别有信心的，我甚至觉得这一个单元的实验给大家带来了一些不一样的东西。大家一直在强调OO，一直在强调面向对象，多态继承封装三特性出口成章，以至于很多人之将Java作为一门这学期临时使用的语言去学了，没有想过深入了解Java语言。客观来讲，Java还是非常重要的，不仅体现在当前诸多大型架构依然是使用Java作为后端，还体现在语言的设计是非常值得学习的。我们这个学期所接触到的知识内容可能只是作为Java的冰山一角，还有很多没有探寻，比如线程池，比如锁升级，比如垃圾回收，所以在第三单元的JML实验中，引入了垃圾回收，希望能拓宽一点大家对Java的理解。然而从大家的反馈来看并不是特别理想，和我们所设想的有一定的差别。无论是JML还是代码实现都会按照预习PPT中的讲解和参考链接的图文，在出题时都是完全按照图文进行出题，然而还是很多同学出现概念理解不清、找到错误不敢改正的问题。由于这一次的实验是我负责而且与预期的差别太大，所以我也进行了反思，主要有以下几点原因：

1. 题型没有提前预告导致大家对找错题不是非常熟悉，出现了找到错结果来问助教是不是题目出错，质疑实验指导书中给的样例的正确性的情况。

2. 预习方面助教和学生共同承担责任：

   • 助教没有强调预习的重要性导致大家对突如其来的新的垃圾回收机制十分陌生，光是弄懂就花费了一些时间；
   • 但同时也暴露了同学们在线上教学中对实验预习的重视程度有待加强，老师辛苦录制的讲解视频和文档组整理的资料有多少人做到了提前一天开始预习？

3. 缺少验题的环节：这一单元比较特殊，从开始的微调上学期实验到大幅动刀改成全新的fhqTreap数据结构再到改为JVM的垃圾回收机制，导致最后没有留给验题足够的时间，在周二才确定下来最后的题目并准备数据。如果有验题的环节或许能找到出题人与做题人之间的认知的区别从而做出针对性的提醒。

此外，实验的打分方式也有待改进。本学期的实验主要以通过测试点为主，但也有几次的实验是进行找错和选择填空，特别是JML单元为了考察大家对JML语法的掌握程度出现了填空题，所以对填空题的正确性的判断就比较麻烦。本学期的解决方法是：

1. 所有提交答案去重；
2. 手工筛选出所有正确答案；
3. 拿正确答案集进行比对。

看到第2步的手工筛选所有正确答案确实是很累的一件事，但是比起正向限制“唯一的”正确答案要合理的多，大家提交的答案可以说是“五花八门、千奇百怪”，出现了一些我们没有想到的、实现起来异常繁琐的答案，考虑到我们只考察正确性所以都给过了。其实蓝头在第一次填空题出现的时候就建议我们使用无监督的强化学习去进行答案的比对，只要给出一个正确答案就能够进行自动评判，当然也可能是玩笑，从真实的几次情况来看还是太乐观了，当然也不怕下一届的助教团确实很棒做出来了这样一个东西可以永流传造福社会了。

从实验组的经验来看，要提醒下一届助教团的有如下几件事情：

1. 单元实验与单元作业结合更加紧密：听说可能要按照单元进行任务分组，这也是一个值得尝试的方案，大家在填写助教申请的时候都对特定的单元提出了改进意见，完全可以让几个助教合并成为一组进行整个单元的包括作业和实验的设计，这样可以更加紧密，实验可以作为一个提前预习的试炼场，给作业进行适当的铺垫，这样应该更能发挥出实验两个小时的优势；
2. 提前确定选题并与老师商量：定好选题才能将任务继续进行下去，而且要提早与老师沟通，这样可以从老师的角度去审视本单元实验的训练要点是否符合教学的训练目标，而且老师对实验难度也可以进行初步的评估，如果过难或者过于简单还能够及时换题纠偏。一定要多沟通多探讨，遇到难题要和老师解决，被打回重做也没有关系；
3. 验题验题再验题：出题的脑回路和做题的脑回路终究是不一样的，为了出一道完整的GC，推荐给大家阅读的推文我可能看了有上十遍，但大家作为预习能点开看一遍就已经很不错了，所以可能出题人觉得简单的地方，虽然在推文里面明确写着一行黑字，但是大家可能就是没注意到。此外，出题是挖空的过程，做题是填空的过程，一个空被挖掉之后有没有可能导致出现多个答案，都是需要验题组进行检查的问题，验题组能够模拟真实实验的场景完成实验没有遇到理解、做题和提交的障碍才能客观上说明本次实验的内容是可行的。

就俺一人的后勤组

感谢蓝头鸽鸽在这学期结束之后给俺开了一人的后勤组，那么这个只有一人的后勤组究竟是做什么的呢？相信大家都听说过后勤组吧，面向对象这门课的助教团队也有一个后勤组，那么究竟这个后勤组是干什么的呢？接下来小编就带你走进面向对象的助教团队的后勤组。

实际上后勤组的工作大多是和老师打交道，协助老师进行每个单元最后的单元数据分析总结，这学期大家在单元总结的PPT中看到的图表应该大多都是我做的，比如下面这些：

还有吐血的所有人的Java Designate分析：

还有每次作业强测结束后的本次作业整体统计，有所有人的第一次提交时间、第一次AC时间、第一次AC提交次数、总提交次数、公测通过点数、每个点的得分和通过情况、强测最后成绩、代码checkstyle得分、互测hack和被hack的点数和成功率等指标，这些指标最后都会给到诸老师进行老师端的进一步的分析总结。此外，在每次得到的数据的基础上进行最后的颁奖和所有人的成绩评定，做到所有指标有迹可循、客观公正公开。

一开始做数据分析，也就是第一单元的时候还是比较懵的，不知道老师希望得到什么样的图表，一顿操作下来被老师直接打回，心里却想着不应该呀，后来和吴老师深入交流之后，学习到了CDV(Conclusion Driven Visualization)，此处引用吴老师的原话：

做这种数据分析，一定要首先想着期望什么结论，简单给个可视化，没什么意义，之前做的那几个对比，2019~2020，不清楚能得到什么结论。如果只是简单的都差不多，似乎没什么surprise，也没必要挨个说一遍。

chart tells the answer, but at first you need to figure out the problem

用图表去表达自己想说的，首先要了解自己想说什么，这不仅仅是做数据分析中用到的思想，也是我们*时做presentation之类的汇报的时候，如何在有限的PPT中充分利用有限的图表该考虑的事情。

后勤组是一个前期比较累后期逐渐轻松的工作，大多都是用脚本解决，但是却是一个从零开始的工作。在这学期开始的时候，遇到了挺多的困难，开始使用chromedriver模拟，但是总有纰漏而且速度很慢，后来得知有专门的api进行查询，进行了优化。开始时对老师需要什么数据进行分析也处于一个摸索的阶段，经常老师会提出一些新的需求不断更新脚本，到后期逐渐稳定下来得到一个全面的分析脚本。最后的颁奖的数据统计也是比较辛苦的工作，毕竟十二次作业的数据一起分析，一不小心可能会出现差错，颁奖多了或者漏了都非常尴尬，最后颁奖前的几个小时反复进行名单的确认，所幸没有出现差错。

至于成绩分析助教就是excel活，大批量数据的拷贝和计算，本身没有什么技术难度，使用vlookup很好解决，就是不能大意，所以审查的机制还是非常重要的。我做完一版发给蓝头，一下就找出了不合理的地方，比对发现确实是因为有一个人中途退课导致的数据移位，后来进行了几次的修正和迭代呈现给老师。

后勤组更像是一个苦力活，不过也让我入门了python，主要是pandas和json库，还有一开始的爬虫的学习，都受益匪浅。可以看出，无论是哪个组，和老师的沟通都是非常必要的。助教毕竟是辅助教学而不是亲自上场教学，需要和老师的反馈沟通改进我们所做的事情去更好的实现老师的教学目标，当然提出创新的想法和老师进行沟通也是值得鼓励的。

最帅的纪老师的随班助教

如果说上面几个组别和同学们之间都是“敌人”关系的话，随班助教算是一个“友军”的存在。随班助教剥离了与同学们的直接扣分有关的作业和实验，负责给同学们送福利的加分环节，而且长期主持研讨课与班级同学的互动也非常多，主要是不够人做研讨要拉人···，对同学们的了解也是非常多的角色。特别是在疫情期间，老师和同学们失去了天然的下课交流的环节，与同学们的沟通变少，这时候随班助教的作用就体现了出来，老师可以向随班助教了解同学们的学习情况，有哪些的主动积极研讨的，哪些是作业实验表现出色的等等。当然随班助教除了和同学们达成一片还需要进行详细的记录工作，这一点是下一届助教团需要考虑的，这里以研讨课为例：

1. 每次研讨课的分享人和分享主题
2. 主动提问和点名提问的记录
3. 提问问题和回答关键词

在与下一届助教的沟通中也看到了宣传组想要将每次研讨课所有班级的优质内容进行汇总的想法，当然想法非常好，但是需要所有随班助教的积极配合与支持，只有将自己本班的研讨内容详细记录才能从多个中选取更优的几个制作推送进行宣传。

当然，看到大家对后期的研讨课中有出现摸鱼分享的情况随班助教也需要进行预防，比如要求分享人提前制作好PPT并发给助教预览，随班助教根据内容的详细程度和价值进行反馈，对于想摸鱼研讨混分的情况进行预防，优化研讨课体验，让同学们愿意来听，踊跃报名。

感谢老师和蓝头还有其他所有助教们

当助教除了能力上的锻炼之外，收获最大的还有处理人际关系的能力和沟通能力，这一点的重要性实际上是远超于编程能力或者是数据分析能力的。在我们这一届的助教团中，蓝头承担了助教骰子的角色，接受老师的任务并安排给我们，并且负责任务最大最艰巨的系统组的任务。蓝头在用人和处事方面的做法非常值得每一位助教学习。在助教骰子的面试中我们也提出了这样的问题：“你认为leader是一个怎么样的角色？如果你是leader你会怎么做？”从中我们也得到了一些满意的回答。

用吴老师的话来说，leader有两种：

1. 消防员型的leader：哪里有火就去救，每天辗转于各个组之间，看起来非常劳累
2. 外表乐呵呵的leader：把任务布置下去，看起来并没有过多插手组内的事务，大家都笑着把事情做了，氛围其乐融融

当时吴老师就让大家选择，你觉得哪一种leader更好。不出所料的是，很多人觉得外表乐呵呵的leader要更好，但是在自己的实际生活中往往见到的甚至是自己承担的，都是消防员型的leader，这实际上涉及到一个威慑力的问题和监督组员的问题。

作为一个团队的leader，首先需要具备过硬的业务能力，蓝头直接负责系统组的任务，甚至有时候通宵修锅，这种“脏活累活”且重要的活如果一个leader如果不能独当一面，是存在一定的风险隐患的。组员可能修到一半要睡觉，但是锅依然存在，第二天可能会影响同学们的学习进度，这时候“骰子不下地狱，谁下地狱”？同时也说明了成为助教骰子还要绝对的担当，甩锅这件事情是不能也不允许发生在骰子身上的。

其次leader要学会分配下发任务，给够充裕的时间让下面的组员发挥，设置检查时间点进行审核。一个合格的leader肯定不是消防员，将任务一并包揽并不是成熟的体现，最终得到的结果不是都按照自己设想的发展，最大可能是全线崩盘，要不是影响整个助教团的进度要不就影响自己的学习。助教团中最忌讳的就是逞能，一个人做事确实很快，但是贯穿一个学年的oo要做的事情太多了，一次两次或许还顶得住，有哪一个人能顶一学期？最好在秋季学期的时候就开始给每个人划分明确的任务，在任务小组中设置小组的负责人，骰子直接对接负责人提高沟通的效率。实际上大家宁可自己一个人折腾也不愿意一起做的原因就是觉得沟通的效率太低，讲清楚一件事花费的时间代价如果太大称不上有效合理的沟通，最简单的解决方式就是减少沟通的内容，关注整体进展而非细节部分。蓝头在这一方面我个人感觉做的非常好。首先布置任务的同时设置检查时间点，在规定的时间内不会对你进行多次询问而是放手去做。在时间点进行进度审查，如果进度偏慢再了解详细情况，询问是否需要增派人手；如果进度正常甚至超前则继续放手不管。但这种处理方式其实也有一定的弊端，比如负责人“说谎”的情况，这里的说谎并不是指真正的说谎，可能只是负责人对自己的任务进度估计存在偏差，对任务难度存在不当的估计导致的，这种情况埋下的隐患很可能只会在最后验收的时候暴露出来，但暴露的时候为时已晚。解决的方式有增加检查点、一个任务至少两名助教参与等，尽早暴露出问题，避免偏差估计。

还要感谢课程组所有的老师，一学年的接触让我体会到了真正的“亦师亦友”。在我大二上OO课程的时候，觉得老师们都是威严的教师身份，不太好亲*，*时联系也是邮件沟通。但我大三成为课程组的一名助教之后发现老师们也有逗比的一面。老师们也会迫害助教骰子，老师们也会push login的女装，老师们在直播间也不会摆架子，甚至直接高歌一曲燃起气氛。老师们对我们助教的工作也是非常信任，对我们的工作内容不会进行太多的过问，充分让我们自己放开手做，只需要最后参与验题检查结果。我沟通比较多的是吴老师，吴老师口中经常能蹦出一些绝妙的语录，希望下一届助教可以将语录库进行完善。不要放过一个老师。还要感谢其他所有的助教们在我的工作中给予我的帮助，包括两位高阶助教和一些已经退役的助教，能和大家一起共事是一件非常值得开心的事情。其实我自己个人本身还收获了一定的自信，为了解答同学们的问题也会主动去学习Java的一些知识，对于 同学们突如其来的提问也不会尬场，其实我的成绩能够成为大家的助教完全是一个意外，但从结果来看希望没有拖OO优秀课程组的后腿。

一路走来 ，感恩有你们。向前看，希望在软件工程中能成为蓝头一样的助教骰子。