团队阅读——怎样学习软件工程

看到这个题目，我首先想到的是邹老师对于软件工程教学负责的态度和践行的方法。邹老师在课堂上跟同学们的互动一直就非常高，对同学们项目工程的进展都给予了十分详的关注。现在相当于做个调查，让我们从受教育者的角度，谈一谈对软件工程教育中的看法。

首先我们阅读了给出的几篇关于软工教学的材料：

一个是软件工程不等于计算机科学（http://blog.sina.com.cn/s/blog_553f355101017g6l.html），另一个是软件工程教育中实践者的反思理论（http://blog.sina.com.cn/s/blog_553f355101017j8q.html）。两篇都是译文，译者是新悦论坛的博主灵凤。还有一个是关于软件工程教育和多学科结合的（http://norvig.com/hybrid-research.pdf）。

软件工程和计算机科学，都是从传统数学发展而来的，但与传统数学都有本质的区别。同时这两者之间也有相互联系的地方。计算机科学显得更为理论化和严谨，许多命题有明确的，有正式的结果，即使是对于其中开放性的问题，我们期待的新的结果也有正式规定。对于软件工程领域，相对而言令人感到有些不靠谱。许多东西没有明确的概念界定，结果的描述都是一般（usually）或者大致（general）；今天的工作对明天的帮助可能有也可能没有；新的方法往往推翻旧的方法。软件工程中的主题都有一个共同的属性：直接涉及人类活动的（directly involves human activity），这些学科的结果可能被人类所用，但他们的结果不会直接影响到人类。软件工程有人类必不可少的成分，例如软件的可维护性，安全性，可塑性等。从联系上看，经典的计算机科学有助于软件工程，但不是全部。良好的软件工程还包括创意，远见，多学科思维和人文科学。

根据以往教育工作者反思得出的经验，学生通过实验室实践——一种建筑学校的基本训练方法——通过一个具体的软件工程项目的开发和改进，能够更深刻的学习与之相关的理论知识。软件不是一种传统意义上的产品，比如房屋，工具之类的，其设计已有设计对象的影响。这使得开发软件系统过程中有两个重要因素：一是复杂性，二是有效的沟通。软件作为一个工程化的产品，强调高效，可靠，功能强大，易于维护。因此软件开发专业化的，系统化的方法加以指导。采用实践者反思的方法，学生不能想要什么老师就教什么，而是要训练他们：要以自己的方式或手段来获取成果。没有人能看到他，他不能看到刚才自己'说'的过程，虽然说可以引导合适的他们看见，从而帮助他看到他所需要看到的。更具体地说，在软件工程方面，如果我们能更好的理解一个软件系统的开发过程，我们就可以更好地去指导这一过程。

假如一个杰出的结构工程师，一位对建筑材料，应力和应变，载荷分布，风切变，地震力等方面了知识如指掌的世界级的专家，在设计一栋建筑物时，可能与客户有一个很糟糕的谈话，不能设计一个令人满意的居住的空间，白谈论审美感了。成功的架构师，包括创意，远见，多学科思维，和人文学科。搞软件系统就像搞建筑一样，先要由架构师设计软件的架构，而且这个架构师应该是身经百战的，对各方面的软件系统都有熟悉。这类人才要具备多方面的思维和知识，特别是未来的人类将很大程度上工作、学习和生活在软件这个虚拟社会里，如何保持一个软件系统的可持续性至关重要，需要有这类人持续关注整个过程。

联系到我们自己的计算机学科的学习过程，从大一到大四的课程安排上可以看出，这是一个有结构的有计划的学习体系，先驱课程与后继课程依序，理论课程和实践课程结合，工科课程与人文课程相辅，因此我个人感觉还不很不错的。关于改进，我读了邹老师另一篇博客：习而学的方法才有了启发。

然后我们采访了几位前大班的同学，向他们了解了一下他们的软件工程课的相关情况。相比于我们的软件工程课，他们的课看起来确实显得有些水。

先从作业方面来讲，他们平时基本就没有什么作业，只有一个期末要交的大作业。而我们则是做了个人作业，结对编程，团队项目，从中收获的东西相对比较多。个人作业，结对编程什么的他们完全没有想过。

接着谈在做项目时的开发技巧，或者说叫开发方法。我们通过上课和阅读老师的博客了解到，做项目并不是高兴了就写一点，不高兴就拖两天这么做完的，都要有一定的系统的开发方法，比如说敏捷开发之类的。而采访的同学说，他们的大作业也就是一个人写一点，然后凑到一起，看看结果如何，什么时候写完全取决于每个人自身，没有一个固定的PM监督每天的工作，调配每个人的任务，也没有tfs之类的东西让大家认清楚自己的工作任务和工作时间，以及同组同学的代码进展。

还有一点就是团队协作。前面已经说到他们的软件工程大作业是团队项目，那么按我们的理解应该有固定时间的讨论或者说组会。而他们说他们之间基本没有交流，他们认为每个人的代码风格都不同，沟通起来应该是一件比较困难的事情，特别是大神和其他组员的，码代码能力也不同，为了追求效率，一般都是大神完成大部分工作，其他成员打打杂，完成一些比较轻松的活，这也许是效率最高的方式。

谈到对我们的软件工程课的看法，他们说的第一点就是我们没有考试，这是让他们羡慕的地方。不过他们也觉得我们的软工课和他们的软工课完全不是一个概念，我们学到的东西确实比较多。问到他们愿不愿意上我们的软工课，他们还是觉得作业量是他们难以接受的，不过绝对比他们的软工课有价值。

总的来说，他们的软工课就像一门普通的必修课，期末交个大作业，然后老师划重点，大家复习准备考试。一个学期下来，估计学到的东西也很少，真正码代码的同学还能有些进步，其他的人基本就是水过了。我记得这话也听上一届的一个学长说过，他们的软工课基本就是这样水过的。这让我又想起了大二下的面向对象，基本就是一样的形式，最后自然是过了就过了，到现在也不理解那门课的意义。

最后谈一谈我们对于软件工程应该怎么上的理解。像前大班的上课方式确实有些不足，如果不对团队项目有系统的规划，肯定是不合适的。但是从另一方面来说，很多大学生都喜欢作业少的课程，这也是一个矛盾。我们觉得，像我们这样的上课方式一定是值得推崇的，它不仅是一门普通的让我们为了学分而学习的课程，而是一门让同学学到真正的技术，真正的软件开发方法和技巧和课程。但是考虑到同时进行的别的课程也有相当大的作业量（特别是不低的挂科率让人很纠结。。），我们觉得这样的课其实可以专门拿一段时间来上，相当于一个小学期之类的东西，一段时间全用来搞这一门课，这样也许能使这们课的意义更大。

 

参考资料：

1.《软件工程≠计算机科学》http://blog.sina.com.cn/s/blog_553f355101017g6l.html

2.《软件工程教育中的实践者反思理论》http://blog.sina.com.cn/s/blog_553f355101017j8q.html

3.http://norvig.com/hybrid-research.pdf

 

转载于:https://www.cnblogs.com/coding-hundredOfYears/archive/2012/12/12/2814276.html