软件工程课程教育的一点想法

  大学本科的软件工程课程一直遵循瀑布型的为线索的各个里程碑的相关知识点的展开介绍，现在多有理论框架与实践能力孰重孰轻之争。这里我也有一点点自己的看法。

       软件工程在项目开发教学中的作用实质上类似计算机导论在计算机教育中的学科地位，应当属于前导性，线索性，框架式介绍，细思量其内容之广、理论之重、实践之繁的教学之繁重，本身就不是一个学期能承载得了的。既然教学大纲只安排一个学期，充其量，将来慢慢发展应当只是领学习者进门的而一个入门学科而已。而不是有些人说的那么危及及乎的想法。

      站在更高一些的高度，比如体系架构或者整个IT业高度，或者整个知识体系更高的高度来看。软件工程，只是前人的经验总结，前辈们总结失败与成功的经验，借助了其他工程的思想来指导项目的开发而已，并不能说明这种就方法是真理绝对正确，这个理论也还在不断完善、推翻和重新整理的过程。这个方法也许只是在一定的范围内可行，但并不表示其绝对的正确。正如爱因斯坦相对论对牛顿定律，当物体速度达到光速，牛顿定律并不适用了。

        而现在软件业高度，深度，广度日新月异的发展，想用一套并不完全成熟理论来定义和约束，还要硬塞进学生的大脑，显然是狭隘的，也是可笑的。

     其一、软件工程思想只是前人总结的经验，并不是多么有高度的绝对真理。数学的集合理论尚有驳论，更何况所谓的软件工程思想。软件工程课可以手把手教学生用这个方法来开发一个项目，但是绝对不是逼着学生们一定要如此来做才是正确，殊途同归，也许聪明的学生会想出更有办法的方法来达到同样的目的，又为何不可呢？所以对于现在的本科学生教育的软件工程所谓的在学中做，我个人是不太赞同的。容易犯了把学生的思路和开拓性框死的弯路，其实可以鼓励学生不同组采用不同的模式和框架来开发，也鼓励小组长们采用不同的管理方式，学期末的时候，讨论各种不同方法的优劣，引导学生在失败中吸取教训，而不是直接告诉他们什么是对，什么是错。因为应用的学科本身就没有对错之分。

      其二，软件工程到底应该偏理论还是偏实践呢？其实需要区分学生的所在专业的，有的专业是计算机方面学科，软件工程只是三年级的一门专业课，有的专业是软件工程专业，软件工程课则是专业基础课，二者有着本质的不同。而且光靠一门软件工程课教会学生软件产品开发，是一种本末倒置的想法。如果要让学生会软件产品开发，可以在软工后续加修一门项目管理或产品开发类的选修课或者开设实践基地，学生按照兴趣选择不同类型的项目，理论结合实际，让企业来指导的不同类型软件产品开发。所以我个人认为软件工程课应该是偏向理论与标准的学习、文档的撰写等，虽然理论课枯燥，不能为了引导学生的兴趣就盲目降低理论的要求，本身大学教育就不在于引导兴趣（理论上来说高中填报志愿就应当默认学生选择了自己感兴趣的学科），而是引导学生更多的挖掘自学能力、解决问题的能力，钻研理论的能力，建立高屋建瓴的思想，无论将来是从事项目开发还是科学研究都打下坚实的基础。

       把软件产品开发实践教学硬揉入软件工程课，有脆化软件工程课理论部分之嫌，而且学生容易一叶障目。只有一个学期的时间，时间非常紧，学生从事开发充其量只看到一种方法，只开发了一种项目，难以见到整片森林，白白耽误了大好的学习和博览群书的时间。软件产品开发和软件工程理论，虽然关系紧密，但是他们犹如树叶和树根的关系，产品开发和项目管理的方法有很多，但是其根本的理论精髓是简单的规律性的东西，他们之间关系应该是现象与本质、形与神的关系，如果只教会了本科学生软件开发的“形”，而忽略了软工思想灵魂的“神”的传达，完全是本末倒置，自以为是的想法。

       其三，教育应该是一种可持续的教育，而不是“应试”教育。把理论厚重，任重而道远的软件工程课，上成了一种很有趣的，项目开发课，看似皆大欢喜，满足了同学的“学会技能”的假象，其实对学生的可持续发展能力是令人担忧的。没有理论铺垫，只是学会了一两种方法，看似会开发软件产品了，其实项目换个框架、换个语言、换个环境，很可能这个学生没有理论的指导，只怕是从头开始学习，重新摸索。这样的学生后续难以有可持续的学习和进展的可能，若干年后可能还是必须搬出大学的“软件工程”理论书重新学习，才能解其“饥渴”。

     我多年教学中软件工程课，发现学习最认真的是专升本专业的那些学生。因为这样的班级大多的学生都有开发工作的经验，在企业工作了几年，重新回来学习，对软件工程的想法完全不同。记得2014年的一届学生，一个同学的表现特别突出，软工课特别认真，对课上布置的文档撰写任务非常认真，小小的一个项目，需求文档写了上百页，认真画每一个UML图，细致入微，自觉加班加点，对任何一个理论都充满了兴趣钻研和实践，作为小组长撰写了非常正规的小组管理规章和规约，而且自己制定了一整套的管理制度，因为同学们都服他，经过他同意那个小组后来陆续加入到15名同学，针对不同层次他就自己发明了分阶梯的管理方式。他经常会找机会与我课后聊天，了解到，其实他是专科毕业后在北京一家软件公司工作了好几年，从事软件工程师的工作，他说那几年他深刻体会软件工程的重要，他甚至没有机会接触到需求报告和概要设计的撰写，现在回来读书，居然可以做项目组长，完全自由发挥的写需求和设计文档，是他梦寐以求的事情，没日没夜的学习和撰写，然后学习如何管理小组内不同的人，学习如何把自己头脑中的想法转换为制度，转换为文档，如何传达给其他组员等等，他说他感谢那个学期的课完成了他的梦想。那个学期的课，后半学期的实验课，都交给这个同学来组织全班小组之间的项目开发方法的讨论，因为我当时实验课允许小组用任何方法来实现项目开发，理论课依然是则介绍软件工程思想，至于小组用与不用悉听尊便。后来每节实验课都由这位同学来共同组织大家的讨论，比较不同小组的每周的进展程度，每个小组总结自己的失败与成功，互相探讨，鼓励互相争论。有些小组代码能力强很快就开发完项目，不写文档，我就会在期中的时候，修改他们的需求，换掉他们最强的代码开发的同学，让他们体会不写文档的痛苦，事后自觉补写文档，防止我随时修改需求和换人的举动。

      当然，我终归还是一个心软的老师，只要有参加实验讨论，只要有做实验，笔试只要及格，所有的同学都会通过考试。我认为，学习重在体验，考核并不重要。人只要经历了，总是会留下印象的，这比什么都重要，这个过程中学会的东西，比分数重要的多。我的打分标准是，所有的小组长都是90分以上，无论小组做的怎么样，因为在我的班里，小组长一定是付出最多的，我采用的是组长负责制，组员完全归组长来教育和组织，分数也有20%是由组长来打分。

     最后提一点关于 敏捷方法，我认为敏捷方法只是教会开发者一种思想高度合作的工作方式，其实其中很多工作方式并不适用于中国国情，生搬硬套的教育学生必须结对编程，站立会议，形如填鸭，缺乏开拓思想。有些人应用的好，是因为他的思维方式适应敏捷方法，并不表示这个方法有多么科学，我认为应该针对中国国情，尊重现实情况，找到一条属于我们国家自己的一种敏捷方式，应该启发学生对于“思维合作”有更多自己喜欢的方式，鼓励孩子们学习的同时，尝试走一条属于自己的路。

       总之，我认为，大学就是一个允许让学生们犯错的地方，通过犯错同时学习理论而不断总结经验的地方，而不是老师教育对和错的地方。大学应该是一个让学生犯错的同时，学习理论，自己判断跌倒是否与不采纳理论有关，是否可以有自己更好的方法，避免将来走弯路等，老师的作用只是告诉学生理论是什么，是否是真理，理论是否正确应该让学生自己去探索和实践，作为老师不能按一己之见而下定论。所谓的用“软件开发教学来作为软件工程课”，究其实质是填鸭似的，只让学生知晓所谓的简单线条理论，生搬硬套的放入实践，疲于奔命的大量作业，最后发现学生和老师都很疲惫，学生也失去了在大学期间能博览群书的珍贵时光，也失去了理论指导实践，实践上升到理论总结的科学方法论。