这学期已经结束，助教的工作也告一段落。第一次当助教，这一学期，有收获也有教训，还是用文字记录下来，给自己一个总结，也给其他人一个参考。

背景

这学期开设软件工程的班级是南通大学大三的学生，共计44人，采用的教材是《构建之法》，讲师鞠老师，我是助教。

作业通过博客的方式完成。主要的沟通方式是通过博客的点评和QQ群。在分工上：

• 作业：作业题目由讲师拟定，助教参与提供意见
• 点评：讲师和助教共同对作业在博客上点评
• 评分：讲师评分，助教根据作业结果反馈做的好的和不好的

前期准备工作和计划

在学期初，和鞠老师有讨论过一些准备工作和计划。大概是：

• 了解学院领导对于课程结果的期望。由于这学期南通大学是试点教学，希望教学中可以考虑学院领导期望，以后可以继续采用新的教学模式进行教学
• 准备一个实际项目让学生分组完成
• 课程安排参考《构建之法》的课程安排建议

实际执行情况

和学院领导沟通的结果

鞠老师跟学院领导沟通后，学院领导对这门课的期望结果是：

1. 没有硬性的考核指标；
2. 期望最终的学生对教师的评价尽量好；
3. 期望能带出少量动手能力较强的学生（学生团队）；
4. 确保那些较差的学生能通过课程的学习（考试），达到基本要求。

相对来说这个要求还是比较宽松的，正常应该可以达到。最终结果还需要鞠老师那边反馈一下。

实际项目的准备

在讨论项目时，鞠老师和我都提出了很多想法，比如做手机App、做网站应用等，中间也有和邹老师沟通，发现绝大部分想法还是脱离实际，没有考虑到学生的技术基础和硬件条件，最终讨论的结果是做一个Android的手机App，第一版本做简单的Hello World，第二版本做一个简易计算器，第三版本学生自己选题。

实际课程安排

作业一

第一次作业主要是开通博客，同学们基本上都能完成，也有个别同学是大段抄袭。邹老师对这次作业题目也有很好的点评：

老师怎样出题目，才能预防抄袭？
- 不要出“综述” 这样的题目， “综述浏览器的发展”。。。 学生只能抄别的综述。 可以出 “结合自己的具体使用经历，描述浏览器的发展，和自己的体会”。
- 学生可以引用别的文献，但是要注明来源。
- 讲究现场感，例如结对编程的总结，一定要有照片显示两个人坐在一起编程。
- 先把丑话说在前头， 一旦出现没有注明的引用，同学间相互抄袭，一律倒扣这次作业所有分数。

作业二 多维数组求和

这次作业是参考构建之法的课程安排，对每个人的编程能力进行摸底，让每个人练练自己的手艺。

实际作业大家完成的非常不理想，第一次作业直到有一位同学完成后，并且他写了个小工具帮助分享给大家，后面的同学们才陆续完成，并且都和第一个同学的结果差不多。同时因为整体完成情况不理想，作业时间点有后延。

在改完作业后，和鞠老师沟通了下，一方面通过QQ群给大家补课，讲了几次作业，鞠老师也在课堂上对作业进行了讲解。但讲解和补课效果不理想，一方面薄弱的编程基础没办法通过短期培训弥补，另一方面通过网络的教学效果也不好。

通过这次作业我们也发现像林杰、张振渊这样的核心同学如果能好好培养，是能带动其它同学的。但可惜这样的同学还是太少，所以后面发挥的带头作用也有限。

因为学生的作业提交都有延迟，导致一直对学生们没有打分结果。在邹老师提醒后，开始通过博客公布了打分情况。

作业三 类的优化

这是第一次结对编程实践，同时希望对作业二的问题进行改进优化。实际情况和作业二一样，完成结果不理想，有很多同学时间点到了没有完成作业，所以后来作业时间点有后延。

这两次编程作业完成情况非常糟糕，总结下主要有两方面的原因：

1. 题目本身设计存在问题。学生对于二维三维数组的理解费力，还需要考虑类的概念
2. 学生基础比较差。南通大学的学生第一学期没有C语言课程，直接上手C++，其他课程也几乎没什么编程练习，缺少实际动手能力。

作业四 软件分析

这是第一次团队作业，对软件进行分析。这次作业鞠老师在布置时要求比较细，另外没有代码要求，基本都能按照要求完成，但也有的组比较敷衍了事。

作业五 项目的NABC以及计划

这是第二次团队作业，进行了团队分工，确定了PM，让各个团队根据《构建之法》的学习分析项目的NABC以及计划。从作业情况下，学生们对于NABC的理解还有所欠缺，对项目计划的制定偏理想化，缺乏可操作性。

作业六 电梯系统之结对编程

由于前几次编程作业完成不理想，所以这次编程作业设计的时候，鞠老师和我反复商量了下，尝试降低难度，将一个可以运行的程序故意修改了几个Bug，让学生可以简单分析代码并修改即可调试通过。代码发布到了Github上。

结果一个星期后，没有一个同学提交作业，中间询问也没有什么反馈，怀疑是Github操作对大家还太难，于是把程序从Github发到了QQ群，即使如此，最终这次作业没有提交的。

此次作业结果对鞠老师和我“打击”蛮大，一方面对学生的编程基础很过失望，另一方面我们也对自己作业的设计有怀疑。同时我们也感觉到学生对课程已经没有什么信心和兴趣。面对这种情况，我们最终决定对这批学生，后面还是偏向理论教学，减少编程作业，同时增加课堂互动。

作业七 构建之法互动游戏

这次课堂互动是鞠老师和我的一次尝试，目的是增强课堂互动，让学生能更多参与到构建之法的学习。

这次教学和作业的尝试非常成功，所有同学都非常投入的参与到这次课堂互动和后续的博客作业。但在设计上还是有些不足：

1. 重点不突出。虽然大家热情很高，但是和构建之法的教学联系偏弱
2. 周期偏短。这是个很好的主题，但是如果只是一个单次的作业，一次互动和作业发挥有限，学习有限。如果能设计成一个系列，就可以通过系列完整的学习各个知识点。

作业八 南通大学教务管理系统分析

这次作业主要是通过实践学习如何需求分析。从作业来看，基本上大家都能发现问题，但是缺少系统科学的分析依据，更少有同学能提出科学的改进方案。

作业九 课程总结

总结一下学生们反馈的问题：

1. 反馈最多的是PPT英文比例过多
   这个有点出乎意料，但这么多反馈说明还是要正视这批学生的英文基础，尽可能用中文的PPT
2. 代码量太少。
   整个学期下来，基本都在100行代码左右，少数几个同学代码行数超过1000，个别说每天几百上千行的可信度不高。
   这部分主要原因在于我和鞠老师的编程作业布置过少，然后同学们自己在业余时间也少有编码的。

3. 课堂互动不够

   部分同学反映课堂上互动不够，容易走神。这个问题我们在中期有所调整，尝试更多互动，另外在以后的课程还要更多考虑如何和学生之间更多互动，增加学生参与度。
   比如有个学生提到了其中一个老师的教学方式可以借鉴的：

   建议的话希望还是学习陈耀老师的教学方法吧，或许在他的课程上你听着可能觉得很随意讲的东西简单却一遍又一遍的去讲解，但是我们从中反而能发现很多实用的东西。第二节课开始又叫我们回忆上节学过什么教过什么，加深了我们的记忆。记得他每次问我们上节课讲了什么回答不上来他会叫其他同学回答，切不回去怎么数落你而是想你记住然后叫你记下来别忘了。http://www.cnblogs.com/lxy95/p/5069547.html

4. 有同学更喜欢板书的形式，而不是PPT
   这个问题我觉得一方面部分学生还是习惯传统的教学模式，另一方面也是课堂互动不够导致大家觉得无聊。所以如果能增强互动，应该会好很多。
5. 没有实践项目，偏理论知识
   有几个同学对参与实际项目是有期望的，但最终我们的项目没有能做成，还是偏理论教学。
   实际工程项目从一开始就有考虑和准备，但是前期的编程作业，效果很不太理想，估计大家平时编码比较少，基础比较薄弱，所以在后面的电梯结对作业的时候，也针对性调整了，改成在完整项目基础上改错，但即使难度降低，整体完成情况还是很不理想，所以最终鞠老师和我商量后调整成课堂上的虚拟项目。
6. 语言基础不够
   从作业情况和反馈来看，这批学生的编程基础确实相对比较薄弱。
   如果从大一开始重新学习，我会首先自学C语言。大一的时候学校给我们安排的第一门编程语言课程是C++，由于我们从来没有编程的基础，而C++又相对较难，所以C++学的很艰难，编程基础没有打好，对编程也有了稍许畏难情绪。C语言可以说是编程的入门语言，C语言和C++有相通之处，而C语言相对于C++要简单，容易理解一些，所以我会先自学C语言。

7. 软件项目管理工具的使用偏少
   软件项目管理工具也是软件项目管理很重要的一环，这个之前没有考虑过，以后要考虑在课堂中适当介绍并作为作业要求。

总的来说，如邹老师所言，学生们的博客有很多有价值的反馈，从某种意义上说， 他们是我们的老师。希望这些反馈对其他老师和助教也有帮助。

总结

以上是上学期的实际执行情况，整体情况不算好，从中有很多经验教训。对这些问题总结一下的话主要有这些问题是需要改进的。

改善沟通

沟通问题存在多方面：

1. 老师、助教和学生之间的沟通
   这次沟通方面一直是很困扰我的一个问题，通过QQ群效果非常不理想，同学们参与度非常低，博客的点评也少有回复，这个在鞠老师课堂上提醒后有所好转，另外很多同学不知道博客的评论回复可以邮件订阅，导致不能及时看到点评。
   另外周老师建议学生助教的方式是个值得尝试的方式，如果有学生作为沟通桥梁，也许能有所改善

2. 助教和老师的沟通
   在上学期的助教过程中，和鞠老师的沟通还是比较顺畅的，很多次作业、调整都是一起商量后的结果。当然还是有改进的地方，比如有时候鞠老师的作业布置下去了我还不知道。
   另外就是分工上也有些模糊的灰色地带，比如评分这事，我偷懒就没评分，只是点评。

3. 和邹老师、周老师以及其它助教的沟通
   在很多问题上，邹老师和其它助教已经积累了很多经验，请教一下可以避免很多问题。同时让邹老师及时指导我们进度也有助于及时发现问题。上学期这方面做的不好，还需要加强。

及时反馈

在这次教学过程中，我们一个很大的教训就是在作业上没有及时反馈。

1. 打分
   如果迟迟没有打分结果公布，对做的好的学生没有及时肯定，对于做的差的也没有给低的分数，不利于激励和惩戒。这部分需要改进。
2. 答案
   每次作业可以公布标准答案，让学生们可以有标准可以参考。
3. 调查
   在最后一次作业，做了一次调查反馈，学生们反馈了很多有价值的信息，所以未来还可以继续以作业的形式在期中就做一些调查反馈。根据反馈的结果能有及时调整。

代码和项目实践

本次教学，最终没能进行实际项目实践，确实是一大遗憾。另外在编程作业的布置上，难度的梯度设置还不够合理，一开始的作业远高出了学生的编程能力。

以后在编程作业的设计上，要从较低的难度开始，根据学生的水平，及时调整后续的难度，提供适合学生水平的作业，不至于打击学生的积极性和自信心，也让学生有一点挑战。

另外上代码的行数上，参考邹老师的标准，可以以1000行为标准。

提高学生参与度和积极性

这次有一点值得肯定的是我们设计的课堂互动游戏，极大的提高了学生参与度和积极性，只是在设计上还太粗躁，昙花一现后后继乏力，还需要更多的形式和方式来让学生积极的参与到学习中。

整体规划

在学期初时，我们理想的认为只要简单按照《构建之法》上面的课程安排即可，但是实际上这更多的是一个参考。

• 根据学生能力的不同需要灵活的做出调整。
• 执行时要严格，不能有Delay，不然后面一环套一环，就像我们这次，后面很多安排根本就没办法实施。
• 在前半学期要多安排内容。邹老师在一开始时就提醒过我们，在一开始时要多安排内容，这样学生期末时，就不至于因为要忙考试而单独进度。

结束语

其实《构建之法》的教学本身也是一个项目：

• 需求分析：分析学生和学院需求，了解学生的能力水平
• 设计阶段：合理的计划、老师和助教明确的分工
• 实现阶段：严格的执行最开始的规划设计、根据情况及时调整
• 稳定阶段：学生们熟悉了新的教学模式，按时完成阶段的作业
• 发布阶段：学生们能运用构建之法的知识，分析问题，完成项目
• 维护阶段：课程结束了，学生们和老师们都有总结

在教学的过程中，做中学，不断改进学习。