OO助教工作总结（退休撒花
作者：互联网
写在前面
刚刚过去的一个学期，大概率是要载入北航OO课程史册的，它以脱胎换骨的崭新姿态展现在了17级同学面前。一个非常直观的体现是，在此之前，关于这门课程的讨论，在北航御用学生论坛（知乎）上接受着每一级经历过它的6系学子的吐槽。而本学期结束后，经历过OO课程的同学已经能够比较客观和理性的看待这门课程，而不是再上升到对人性本恶的探讨（滑稽.jpg）。有关课程改革的细致说明，可以移步知乎回答：
https://www.zhihu.com/question/30413458/answer/733229545
很荣幸，在这样一个“历史进程”中作为助教组的一员，做了一点微小的工作。正值被选为OO助教一周年（左右），完成工作即将退休的关头。希望站在课程组一员的视角上，不带束缚地以时间为线索，记录一下我所见，所做，所参与的真实的OO。
那年OO
虽然上面小小地把这学期的OO课程吹了一下，但一个课程在进行的过程中也难免出现会被同学吐槽的地方。大概是因为OO的名声早已为一届又一届的同学广为传颂，今年的“南湖捞人计划”，第一次博客作业的提交说明，第一单元的WF要求，课程调课等等也是被一些同学各种“花式吊打”，所谓“屠龙的少年最终变成了恶龙”。看着这些五花八门的吐槽，我真的是能笑出声来，同学们真的很严格呢。
关于这些事件，上面贴的HansBug同学的知乎回答里有相关解释，这里不再赘述。作为18年OO课程的“底层群员”，我想说的是，从18年往上数，虽然也会有各种吐槽，但其中一大半的篇幅中都牵涉到了课程规则中的双盲互测，所谓“人性之恶的体现”。简单来说，就是一个同学的作业会随机分配给另一个同学，由其进行测试。测试的同学测出问题，可以把这个问题以及所使用的样例挂到课程组提供的bug树上，然后被测出bug同学扣分，测试者得分。如果被测者不服，可以与测试者在课程网站进行“友好地探讨”，直到明确这是否能够被算作一个bug；谈不拢了，则需要申请仲裁，这样“青天大老爷”（助教）会从天而降（当然会有那么一丢丢的延迟），给出最终的仲裁结果，这个bug的问题就算完结了。
这个规则实际运行起来真的是很复杂。其中自然存在一些问题，一是这个方式的随机性过高，谁也说不准对面的测试者是“友好的同学”或者“狼王”，而自己的手里又可能是一份无懈可击的代码或“大礼包”，所以并不能很好地从测试分数量化单个个体的水平。二是一对一的测试难免会出现个体标准之间的碰撞，到底什么能算做一个bug？遇到双方互不相让的时候，往往是既耽误了宝贵的学习时间在扯皮上，又影响了心情。同时，对OO好感度--。
一般来说，深刻的体会往往源自真切的经历，我也是这样（捂脸.jpg）。顺便分享下去年的一次互测经历，那次的作业是IFTTT，由于焊板子等诸多事情，我并没有很好地把握时间，仓促提交后发现自己在一个比较关键的程序节点出现了问题，对数组误使用了等号进行赋值（这样做实际上操作的对象是指针）。这就导致了程序的一块主要功能不能正常实现。我的第一感受是认命，虽然只有一行的细节问题，但是导致了一个主要的功能不能运行，算是比较严重了，对面测试的同学给我扣个4、5个bug也就这样了。但测试结果已出，我发现我在这个功能模块的bug树被挂满了（接近20个bug）。这种落差就很令人爆炸了。之后，我大概用了接近两天的时间去和测试者同学做沟通，最终双方均让步，留下了之前的一半bug。（双方的沟通文本有几千字，部分我留存的回复文本如下图
以上是一个我所经历的，最终还算得上得到了解决的一次测试过程。并且，这种测试过程是贯穿整个课程的，而且每次作业还会有测试者和被测者的双重身份。不知大家对曾经的规则作何感想呢？
而课程结束后，我深刻感受到的是，通过这套课程体系的训练，我的代码、测试等诸多相关能力确实得到了很大的提升，但是对这门课的整体体会却说得上五味杂陈。最终，大概因为是一腔热血吧，我选择重新投身到OO课程去，成为一名助教，希望能够通过自己的微薄之力，做一些事情，做一些改变，让后来人能够纯粹地从这门课中学到有益的知识。
规则制定
令人兴奋地是，我并不是唯一一个这样想的人。更是有同学在新一任助教选出之前便与老师进行了相关交流。所以，2019学年OO的主基调从一开始就被确认了，我们将改革这门课程！从规则，课程系统，到作业设计，做出全方位的升级。课程组从九月份学期，便召开了会议，梳理了新一年的规则大纲。“圣杯战争”互测，bug修复阶段，多线程自动化测试，这些17级同学在课程中所实际体会的由此作为概念列入计划纲要中。
明确基本规则纲要后，便是规则细节的制定。我所在的小组负责公测及bug修复具体细节的制定。不得不说，这是一个比较“烧脑”的过程。从之前课程的互测中可以体会到，总有一些意想不到的情况，或是运行不顺利，或是被钻了制度的空子。所以我们制定规则的过程也很清奇，先简单写出初版规则，再站在参与者的角度，模拟各种情况尝试去钻制度的漏洞，进而进行debug。一如我们的群名“钻指导书空子小组”。
这其中自然也有一些难以解决的问题，其中一个令我们思考良久的是，如果采用样例+评测机测试，那么bug修复阶段该以何标准去量化bug数。在之前课程，仅由测试方进行主观判断可是令我吃尽了苦头，公正起见，这里必须有一个统一的标准。但bug数可不太好由机器去做判断，所以这就产生了矛盾。这类问题最终是由课程组成员在会议上共同讨论解决，有关同质bug的判断，最终采用老师的提议，将自动判断同质bug的标准设置为5行以内的代码改动，而如果一个bug的修复超过5行的修改，则提交说明由课程组审核。
这个过程也让我体会到了体系规则制定的困难所在，一个相对完善的规则真的不是一蹴而就，甚至有些时候需要通过一定的实践去发现问题。规则修订的过程历时了大概两月左右。为了确保作为课程基石的规则的公正，也是为同学负责，课程组花了相当的功夫。（下图：笔者本地所存一些规则制定相关文件
指导书大修
正式开课前的一学期，也就是上学期，除了规则修订外，课程组还花大力气对指导书进行了重新修订。一来是因为要使得作业更加体系化，更加贴合课堂内容，所以需要对作业的部分需求进行调整。二来是因为之前的指导书确实有些地方太绕了，每每是讨论区有几页帖子，每个帖子盖了几十层外加爆炸的微信班级群。写一次作业除了指导书还得翻遍讨论区微信群那真的做不到呀，所以还需要修改作业的描述，让它变得简洁且易懂。
我具体负责的是电梯作业的IO设计，刚开始我觉得，就是简单些嘛，用最短的话把事情说清楚，反正不会搞成一次作业写出10页指导书咯。写着写着才发现问题不小，又要严谨，又要简洁，这本身就是一件很矛盾的事情。写完初稿发现长度还是挺爆炸的，不知道这种写法拿去使用会是怎么个反馈（出来挨打警告.jpg）。（下图：笔者本地的初稿和指导书最终稿的部分对比
修订指导书整个的过程还是满有意思的。在写电梯指导书的时候我们曾经考虑描述下基准调度算法(ALS，a little stupid smart)，以降低部分难度。但是在一个调度的情境下起了疑问，于是和另外一个助教同学深夜到寝室楼的电梯做了下实验（问题在下图，答案是1->4->1->5->7）。想着这么描述下去，一是可能说不清楚，二是可能不太真实，最后索性把描述去了，拿大家的平均运行时间当基准算了......
正课工作
经过了一系列前期准备，终于来到了正式的课程运行阶段。12名助教同仁也分别负责了所有工作的一部分。技术dalao负责系统及数据构造，熟悉指导书修订的同学负责讨论区建设与答疑，细心的同学负责数据整理统计，至于我这种“浓眉大眼，五大三粗”的同学自然就负责和同学们的日常沟通和研讨课了。
话是这么说，和同学进行对接还是比较挑战耐力和细致程度的。像是实验课，真的是各种情况都会出现，包括但不限于“该坐哪，机子有问题，网页打不开，账号不存在，账号忘了，密码忘了，密码应该是对的但是报错了，重新注册了一个发现原账户没了，git操作不会用了，提交不上去了”。去之前以为自己会是一脸冷漠的监考，后来发现自己成了忙前忙后的大保姆。emmm，曾经被我的愚蠢问题烦扰过的助教学长学姐，对不起！您们辛苦了！
除了日常的问题沟通，我在这个学期主要负责了一个班级的历次研讨课组织。研讨课的目的主要在于鼓励有想法的同学进行上台的分享，让处于同一环境的同学们进行充分的沟通。毕竟这个是OO的又一大创新，那么第一节课肯定要发挥出超高的水平来镇下场子嘛，于是通过一些渠道联系到了水平相对较高的同学，通过点人的方法凑齐了第一次探讨课上台的同学。第一节课确实效果极佳，各路大佬那确实是有水平，讲解那叫一个深入浅出。但是从第二节研讨课的组织开始，我惊奇地发现，少有同学报名参加研讨了。诶研讨课上台可是当做附加分数的送分题呀？后来不得不找到了一些神隐的dalao，虽然dalao战绩斐然，光环十足，但总是会说一句，哎呀我总觉得自己水平不太够呀...好在17级6系同学也是dalao资源充足，虽然召集同学花了点力气，有时候甚至要去请来自外班的“外援”，好在是顺利完成了课程计划。很多同学的讲解也使我收益颇多，也出现了那种我听不太明白但是还要报以礼貌的微笑的情况（捂脸.jpg）。还是要学习一个呀...
由于这学期组织和参与了历次研讨课，所以我对研讨课本身是有一些心得和建议的，当然也有一些有待解决的问题。这里在下面进行简单的罗列，希望之后的研讨课组织能够传承经验，解决问题，真正发扬研讨课调动同学资源解决同学问题的初衷：
- 研讨课的话题需要征求同学的建议，而同学们的建议更多集中在作业层面，所以需要对研讨话题进行一定的控制，争取在同学想了解的前提下，覆盖作业问题和课程重点内容。
- 研讨课需要更鼓励所有有想法的同学去参与。所以最好不要上来就鼓动一群dalao上场，会一定程度影响后面同学的积极性。当然，激励方式除了分数奖励之外，可以采取更多样的方式。
- 助教和老师在研讨课的参与度和参与点有待进一步探索。助教和老师上场的话其实会压缩同学进行研讨的时间和空间，但一定的参与也能够让同学们更加理解课程设计，引入一些小点子，带动气氛。（我在第一节研讨课最后和同学简单介绍了下写第一单元非常有用的编译原理的方法，当时其实纠结了很久，因为当时作业重点在正则表达式等，有介绍“偷懒方式”之嫌。所以助教和老师的参与方式和参与度需要进一步明确。）
- 其实班际沟通也是很重要的，因为目前存在4个不同的研讨教室同时开讲，班级间较为割裂，如何将其中的精华部分得以统一，又能保证足够的参与度值得探索。
写在最后
一年助教工作下来，真的是收益颇丰。很荣幸成为了这门课程改革的参与者，从一个完全不同相同的角度去重新认识这个“老熟人”。一个课程系统运行下来真的是非常不易的，它离不开我们每一个成员的参与。努努力，这门课程就能变得更好，我们怀着这样的信念走到了最后，也收获了不错的效果，得到了不错的评价。很值得，虽不敢称“敢叫日月换新天”，但至少是不枉此行了。
最后，感谢老师们的帮助和支持，感谢各位努力的同僚，感谢参与到这门课程中的优秀的同学们。
文章到此为之啦，祝我退休快乐~
标签：OO,助教,撒花,课程,研讨,同学,bug,指导书 来源： https://www.cnblogs.com/buaaidealee/p/11141127.html