时间过得很快,从2月份布置第一次做业起,到如今居然已经快过了半年。git
全部同窗的总结博客我都一字字的看了,几乎都提到经过博客做业学到了不少。有同窗说“这门面向对象是我到如今最有大学感觉的课程”,真的,我大一结束后也是这样想的,一模一样。github
经历了从零开始一股脑扔出一大堆新东西,第一次接触博客园、接触Git、接触Markdown,第一次写博客、第一次打开VS点下new project、第一次用C++编写图形界面……即便这个过程当中挫折无数,但最终完成编码的时候那种喜悦远远多于中间经历的全部痛苦。这种感觉大概只有亲自体验过才会最明白。常常会在看你们博客的时候无限感慨,回头去看了本身之前的做业写的啥:D。算法
当看到有同窗吐槽说本身零基础什么都不会、缺乏新技术的新手指导的时候,我是不太赞成的。由于每次布置做业中,基本都有给出相应的参考连接。好比第一次开通博客的做业中就给了markdown入门参考;后续编码做业要求上传github时也给出了西瓜学长的git教程和推荐参看廖雪峰的git使用教程等等,我认为这些就够了。至于详细地去教在遇到不会的东西时如何探索学习是没有意义的,由于这个问题好像和解决方案自己就是一个闭环(?)我认为彻底不必解释。编程
虽然前面说的是没必要要阻断探索空间,但能够改进的是,更多地对大一同窗提供简单的思路引导,抛砖引玉。好比电梯做业中关于bus和taxi的简化思路是获得邹欣老师提示后在第三次做业中才给出的,有一点晚,若是在第一次布置电梯做业的时候就先给出这样的基础提示,可能交做业的人会更多一些。当年西瓜学长那种手把手的经过做业一步步指导构建计算器做业(从读入字符串处理、中缀转后缀、用栈实现运算、GUI),脉络清晰并且极其容易上手。今年的电梯一开始就极大的开放性和高难度,吓倒了一批人也确实不足为奇。这也体现了我做为助教的经验不足啊,不该该在寒假做业一开始就把需求罗列的那么详尽庞大,若是把开学后的第一次电梯和寒假的第一次电梯对换一下,才比较合适。以后的我的做业可能须要在计算器和电梯作一个折中,由于按照计算器那次布置做业的方式,不提题目自己彷佛不够面向对象,手把手的要求会在写代码的过程当中,出现同窗本身的思路和做业要求不一致,非得改为那样就很别扭的问题。markdown
总得来讲,电梯做业仍是留有至关多的遗憾,原本这个选题应该是很不错的。足够体现面向对象的优点,题目自己虽有必定难度但也不是实现不了。但就结果来看,我以为只有5个不到的同窗能称上完成了这个做业。有位同窗在总结博客中说,“虽然已通过了这么久,仍是忘不了被电梯支配的恐惧。”我想最大的问题除了上面提到的寒假一开始难度过高,还有就是:架构
1、同窗对完成题目的关注点偏了,全在聚焦调度算法(oj刷多了看什么都是算法题),本应该先把能运行的电梯实现出来再优化(这其实也能够经过控制做业要求手动实现的,要是先不提调度两个字就不会这样了)。不过深挖优化算法也是好事呀,但愿那些在总结中说“哪天掌握了算法就去改”的同窗以后真的会作吧(虽然有了这句flag后,可能性就已经无限趋近0了hhh) 2、拖沓的时间太长,从寒假做业拖到开学做业还在电梯,别说完成做业的同窗了,就算是我本身看博客的时候都审美疲劳。不过这也和布置做业的时间规划有关,若是在一开始就把做业次数根据题目难度和寒假时长规划好,就不至于拖到开学了。函数
寒假布置做业的步调很乱,先前进了一大步,而后发现不对劲要原地等程度较弱的补齐,致使第三次做业(控制台读入改成文件输入输出+需求小调整)对于一部分同窗就稍改几行代码而后就能交了,博客也一度尴尬。有了寒假的教训,开学后的做业就明显好了不少,渐进式前进+更多的提示。工具
还有遗憾的是,由于时间关系没能对接上栋哥提过好几回的电梯调度游戏的网站。若是能加上的话,同窗本身的代码产生调度结果配合可视化的小人,趣味性效果会好不少。不过我有去看过,那个网站貌似只支持js代码,并且封装的不够,想用的话得开始就在做业要求里规定一堆东西,成员变量和函数名和功能等等都要一致。若是之后仍是选这题,想对接可视化可能要助教本身开发,使得和具体编码无关只与输入数据和输出结果有关,而后提供API。学习
至于团队项目,这一届应该是第一次在C++课程中就接触团队编程。我也没想到早就说好的王者荣耀大做业会是以团队的方式进行,但意外的发现你们的完成度远远比我想象的高,那天在课堂展现的时候看到的都挺不错呀(惋惜栋哥居然没给助教提问的机会orz)。可是最严重的失误就是,在做业要求中没有关注github的签入,我认为这致使了最终结果稍微有失公允。若是要求阶段的签入量和团队成员必须签入的话,就不会存在究竟是本身从头开始逐步构建仍是把已有的别人的东西拿来稍做修改就上交应付的疑虑(这里又不得不懊悔一下经验不足)。优化
装甲车队是惟一一个有在github协做开发的,能看到团队每一个人都有签入量(其余队伍都是发文件改来改去)。但也是最惋惜的一队,虽然每一个人的能力都不错,但一开始目光过高太远,架构要完美代码要优雅UI要炫酷,结果出现各类问题又加之做业时间很短,最终没能完成想要的效果。课堂展现的时候就看着装甲车队长一脸生无可恋地挪动屏幕上的英雄一边吐槽遇到的各类坑。后来我私下找了他们稍微提了下MVP的概念,一边以为没有软件工程概念以前玩团队合做是真的很虚啊。当时在要布置团队做业以前栋哥看完我拟的初稿,说不要强调软工的套路,这门课是面向对象,以他们本身朴素的方式便可。我才反应过来本身不知不觉的在往软工靠了,后面就在着重强调面向对象自己而不是团队编程。因此你们即便完成度不高或者团队合做不顺利也不要气馁呀,有收获就足够了,更多的软工内容之后会学的。
还有一点就是,这学期的博客做业拖过久了,应该在考试月以前就结束掉比较好,否则直接形成你们被期末考压制着无法多处分心,也影响了做业质量和教学效果。(虽然很大一个缘由也是今年开学太晚了orz)
说中途没有疲惫心累过是不可能的,毕竟不是老师职业而是兼职助教,要在本身的事情中抽时间权衡、负担今天再不布置出做业又要拖你们时间的责任。三次在动车上写助教博客,两次是在去外地比赛的途中,一次是如今在回家的路上2333
当初自荐作了栋哥助教的缘由也很简单,就只是以为本身之前在课程中获得了西瓜学长和乾神的好多帮助,也想体验一下作助教玩。但以后好几回特别疲的时候就在想,我为啥要当助教呢?寒假那会特别迷茫,以为在琐碎的事情上花费了一大堆的时间也不知道到底收获了什么。后来去问了乾神,他安慰我说,这也是进入社会的锻炼,特别是在耐心和运用自动化工具上。有疲惫心理很正常,一开始是热情推进,后面就是使命感了,因此想着如何高效率的完成任务比较关键。
后面就心态放平了不少,尽力去协调和完成每一件事,加之本身事情的DDL结束,也更投入助教工做上了。虽然助教团队也不仅是我一我的,但赵畅毕竟大二课程很是多,因此大多数时候仍是个人任务更重一些,但也很是感谢是他在我忙于比赛的一段时间里替我作了大量的评分工做。
每次无论是布置做业、回答问题仍是点评博客的时候,都会不知不觉的像是西瓜学长或者乾神那样的方式,经常翻看他们之前的助教博客,想着他们是怎么作的。看到很多同窗都在总结博客中提到谢谢助教的帮助,是真的很开心了,感受以前作的事情都并无白费~
此次的构建之法助教培训没有参加,多是由于栋哥今年开始再也不上软工实践了,也就没有多问。以后还会作助教吗,对我仍是未知数。