抛砖引玉 你觉得大学计算机专业应该怎么教

vupiggy

其实吧，如果自认为很NB的话，去看看 钱学森的《工程控制论》
~~~
hokuhouhi 发表于 2011-08-31 04:20

唉，我说什么来着，除了楼上的楼上那位兄弟，这帖子已经出现的和将要出现的包括俺在内，上大一到大四那几门必修课的时候不是睡觉就是逃课了。

oooooxxxxx

哟，不要因为说被我激怒了而逻辑混乱。

就不要感觉良好了，自己看看你发过的帖子，就你这水准真没法激怒咱。

让我来看看你理解的软件工程是什么东西：


1. 你真以为人的软件工程能力是教出来的吗？

当然可以是教出来的，但不是每个人都学得会。
按照个人经验摸索一样可以总结得出部分的软件工程，并且，固然，软件工程的很多理论本身就是从经验中积累出来的。
但并不代表说，以后每个人都需要这么积累。

如果你说软件工程能力不可以教出来，那请问数学思考的能力能不能教出来？
如果你认为数学思考的能力能够教出来，那请问软件工程的能力和数学思考的能力有什么差别，使得他不能是教出来的？

如果你认为数学思考的能力不能教出来，请问问你自己，你是怎么学线性代数的？
生活中可没有多少东西，可以让你悟出线性代数里面的东西哦？
除非你告诉我你家老早之前就搞这些了，那我佩服你，神童！

不扯虚的，再给你举一个可以学会软件工程能力的例子。

现在软件工程能到数学水准？醒醒吧同学，不管是线性代数还是离散数学都是自成体系的，软件工程是什么？你要能搞出个体系来让学生一步一步的根据已知条件论证一个命题的对错？

估计你应该也没亲自设计过 linker 和 loader 吧，一开始学C什么的时候也应该没有直接告诉你调用函数时，参数是如何入栈出栈的吧以及跳转吧？
但就算你没有这些经验，这也没妨碍你在写代码的时候，跟着老师说的做吧——“重复执行的东西，可以写成一个函数” 你一定懂！

不要告诉我说这是TMD基本常识或者说你天资聪颖！！！
如果你不知道冯诺依曼对计算机的定义和图灵机理论，你一定说不出为什么有必要这样抽象一个可重复执行的函数出来！！

这就是实实在在的软件工程思想，在计算理论和工程实践之间的妥协。
只是有人教了你这种能力，你不自知而已。
更为抽象的软件工程思想和执行能力，你没悟性光看书理解不了，不代表全世界都这样！！

来，你来讲讲冯诺伊曼与可重复执行的关系？讲讲函数与linker/loader的关系？这就是扯淡啊，同学。一文钱的关系都没有，你是不是不知道lambda演算就是建立在函数上的？所有使用lisp的程序员都是天使啊，不学习图灵机居然还把一切建立在函数基础上。
linker/loader处理函数的同时还处理全局变量。函数不管有没有linker/loader都可以存在，你能找找这两者之间的相关性？

2. 软件工程你能给学生什么成果？是一堆开发模型还是什么测试驱动，xp敏捷之流？

瞧你说的这些东西，果然是跟软件工程只有一点点的沾边啊。
开发模型什么的，只是属于工程管理的概念，这固然是一个分量很重的话题，但你若以为这可以代表软件工程，那只能说你目光狭隘。

一个支持多个后端的编译器怎么写？
请问你觉得这是不是软件工程的话题？
但我可以很负责任地告诉你，不需要真的做过编译器，一个研究这方面的研究生也可以做出来，你去WindRiver里面的看看。

事实上，简直就有一本书叫做《编译器工程》。
你该不会认为这本书的作者脑袋进水了，把不能教给人的东西强行塞到人脑子里？

人家叫《编译器工程》可不叫《编译器软件工程》，跟软件工程有毛线关系？
人家教的是编译原理又不是教你怎么写代码。不要看到个工程就乱联系。实际上，除了优化部分以外，现在编译器基本是已经解决的问题，不管是前端还是代码生成。除非你自己写过编译器或者给gcc/llvm这些项目写过代码否则就不要显摆了，哥们儿读书的时候就手写过简单的PL编译器/解释器，跟软件工程真的没关系。

3 现在软件工程的成果大部分不是靠逻辑推理出来的结果而是一些实践经验的总结，到现在为止，软件还是严重受开发者水平影响,不维护过项目你怎么能讲清楚那些经验层次的东西？

这说明你接触的都是低水平的软件工程呗。
事实上，多后端的编译器的设计以及工程执行，直接就是编译原理里面推导出来的。

“到现在为止，软件还是严重受开发者水平影响”
如果不是严重受开发者水平影响，难道是受外星人的水平影响？ 不解释

“不维护过项目你怎么能讲清楚那些经验层次的东西？”

两回事，如果你非要把软件工程当做经验层次的东西，那你就是在说废话。
你都把他当做经验层次的东西了，你还问没有经验要怎么说？
请检查一下你自己是不是陷入的自己的定义陷阱吧。

建筑工地有工人有工头，还有工程师。
但是一个经验丰富的工人也不太可能告诉你为什么一座建筑为什么要有这种力学结构。

如果你说写代码的经验能够完全转化为工程的经验，
那你试试写个编译器来玩玩？
如果你不知道具体算法，我可以都给你，你自己设计一个？
都是那些你平常用的算法而已嘛，还是说平常你都不比在意算法的？

4 你又从软件工程上得到了什么经验教训？还是读了两本书就人云亦云？

所以你明显就是自己对软件工程的定义不清不楚，以为就是什么经验教训而已。

咱接触的水平高低不是你能界定的。
能从理论推导的那是计算机科学，你明白吗？比如编译原理，数据结构与算法，操作系统，你想让软件工程包含这所有学科吗？
你看你扯来扯去，软件工程这东西连个范围都界定不下，还吵吵着多牛x这不是笑话吗？

最后，不要一幅牛比轰轰的样子教训别人，哥们工作多年，搞过内核，写过编译器，弄过lisp，学过类型系统，什么x86，arm手册都还算熟，咱真不认为你能教育哥们儿的眼界问题。

xyfree

滚

bbjmmj

我搀和几句吧。
中国大学教育的弊病就是功利。考大学、念大学全都是功利。大学环境讲究“成果”，“成果”绝对是最功利的功利。教师想要学生学会什么知识，同样也是一种功利。
大学是人生从象牙塔走向社会的最关键阶段，这个阶段里学生需要规划人生，规划他们离开校园之后干什么，相比之下，学知识反倒成了最不重要的事情。大学里不学习知识学什么呢？培养学知识的习惯，培养学知识的素质，培养学知识的能力。
四年校园生活，时间很短，还要为各种事情疲于奔命，考试、找工作、搞对象，你很难说哪个重要哪个不重要。短短四年要做很多事，能学到的知识很少很少，成功的大学教育几乎完全取决于学生离开校园之后的表现，作为一个大学老师，教会学生知识是次要的，给学生指引学习方向，让他们离开校园以后不会迷茫才是最最重要的任务。

oooooxxxxx

不知道是你误解了意思，还是故意转移视线？

软件工程固然不是数学那样的推理证明逻辑体系，但是软件 ...
xyfree 发表于 2011-08-31 14:44

    咱是抛砖引玉，既没有牛x轰轰的说谁误导别人也没有说谁没资格发表意见，何以让你如此激烈的口诛笔伐？明明是你把计算机科学的东西都归类到软件工程里还振振有词的说别人不知道软件工程的重要，你只要读过任意一本软件工程的教材就知道软件工程这门课要教的是什么，什么函数阿抽象啊，读点书，sicp第一章的内容阿，你想说sicp也是软件工程吗？这真是中国特色吗，什么东西都能无所不包？
编译器是已解决的问题与有几个编译器项目一点关系都没有，就像说制造筷子是已经解决的问题，但是你仍然要制造使用筷子一样，你只要找找这几年计算机体系结构上的会议论文就知道现在编译器研究的内容是什么，空口白牙的什么自动补齐一点说服力都没有。
你如果不知道什么是软件工程，这是一本教材的目录，来看看跟你想象中的软件工程有几分相同的，

4: Requirements engineering
4.1 Functional and non-functional requirements
4.2 The software requirements document
4.3 Requirements specification
4.4 Requirements engineering processes
4.5 Requirements elicitation and analysis
4.6 Requirements validation
4.7 Requirements management
Chapter 5: System modeling
5.1 Context models
5.2 Interaction models
5.3 Structural models
5.4 Behavioral models
5.5 Model-driven engineering
Chapter 6: Architectural design
6.1 Architectural design decisions
6.2 Architectural views
6.3 Architectural patterns
6.4 Application architectures
Chapter 7: Design and Implementation
7.1 Object-oriented design using the UML
7.2 Design patterns
7.3 Implementation issues
7.4 Open source development
Chapter 8: Software testing
8.1 Development testing
8.2 Test-driven development
8.3 Release testing
8.4 User testing
Chapter 9: Software Evolution
9.1 Evolution processes
9.2 Program evolution dynamics
9.3 Software maintenance
9.4 Legacy system management
Part 2 Dependability and Security
Chapter 10: Socio-technical Systems
10.1 Complex systems
10.2 Systems engineering
10.3 System procurement
10.4 System development
10.5 System operation
Chapter 11: Dependability and Security
11.1 Dependability properties
11.2 Availability and reliability
11.3 Safety
11.4 Security
Chapter 12: Dependability and Security Specification
12.1 Risk-driven requirements specification
12.2 Safety specification
12.3 Reliability specification
12.4 Security specification
12.5 Formal specification
Chapter 13: Dependability Engineering
13.1 Redundancy and diversity
13.2 Dependable processes
13.3 Dependable systems architectures
13.4 Dependable programming
Chapter 14: Security Engineering
14.1 Security risk management
14.2 Design for security
14.3 System survivability
Chapter 15: Dependability and Security Assurance
15.1 Static analysis
15.2 Reliability testing
15.3 Security testing
15.4 Process assurance
15.5 Safety and dependability cases
Part 3 Advanced Software Engineering
Chapter 16: Software Reuse
16.1 The reuse landscape
16.2 Application frameworks
16.3 Software product lines
16.4 COTS product reuse
Chapter 17: Component-based Software Engineering
17.1 Components and component models
17.2 CBSE processes
17.3 Component composition
Chapter 18: Distributed Software Engineering
18.1 Distributed systems issues
18.2 Client–server computing
18.3 Architectural patterns for distributed systems
18.4 Software as a service
Chapter 19: Service-oriented Architecture
19.1 Services as reusable components
19.2 Service engineering
19.3 Software development with services
Chapter 20: Embedded Systems
20.1 Embedded systems design
20.2 Architectural patterns
20.3 Timing analysis
20.4 Real-time operating systems
Chapter 21: Aspect-oriented software engineering
21.1 The separation of concerns
21.2 Aspects, join points and pointcuts
21.3 Software engineering with aspects
Part 4 Software management
Chapter 22: Project management
22.1 Risk management
22.2 Managing people
22.3 Teamwork
Chapter 23: Project planning
23.1 Software pricing
23.2 Plan-driven development
23.3 Project scheduling
23.4 Agile planning
23.5 Estimation techniques
Chapter 24: Quality management
24.1 Software quality
24.2 Software standards
24.3 Reviews and inspections
24.4 Software measurement and metrics
Chapter 25: Configuration management
25.1 Change management
25.2 Version management
25.3 System building
25.4 Release management
Chapter 26: Process improvement
26.1 The process improvement process
26.2 Process measurement
26.3 Process analysis
26.4 Process change
26.5 The CMMI process improvement framework

vupiggy

作为一个大学老师，教会学生知识是次要的，给学生指引学习方向，让他们离开校园以后不会迷茫才是最最重要的任务。
bbjmmj 发表于 2011-08-31 15:46

完全正确，加十分。``不会迷茫''是点睛之笔。

xyfree

滚

oooooxxxxx

所以在你看来软件工程就是一本书一本教材，某一个具体的课程名就可以学到的？
    看来你就是你自 ...
xyfree 发表于 2011-09-01 03:27

    一本经典教材的目录不足以界定软件工程的范围的话你靠什么界定？靠你空口白牙说什么就是什么？
你不只学习软件工程跟软件工程需不需要学习有什么关系？
难道说因为你学习计算机科学的同时学习了软件工程然后你又是软件工程专业的所以计算机科学就是软件工程？
这本教材的目录如果不足以涵盖软件工程的范围，那么该作者一定很乐意让你指点一下应该增加哪些内容。你满口的思维啊什么思想阿，可是总要拿点实际的内容出来吧？你举些计算机科学的例子，又不承认经典教材的涵盖范围，你不妨定义一下软件工程的内容？

xyfree

滚

oooooxxxxx

如果你不承认你这样是流氓的逻辑，我觉得我没有再必要跟你聊下去。


我可以很明白地告诉你，我没 ...

但是的确是有大家都能同意的属于软件工程研究范围的东西，你列出的那本教材里面也涉及到。

而且正如你所列出的那样，software evolution, testing, programming model，
这些你难道不认为是一种完全不同的角度和思维方式来运用计算机科学的知识么？

如果你据此认为这是简单做做几个项目有经验，就能明白为何要这样做，以及如何推广到其他项目中去的话，只能用有限的经验去依样画瓢，
xyfree 发表于 2011-09-01 04:40

    你看，你早说这些具体内容不就结了，又是思维又是啥的都是虚的。你扪心自问这些关于项目整体运作的问题怎么教给学生？除了老师照本宣科，学生莫名其妙以外还能收获什么？参加了具体项目，这些流程啊要求啊自然就清楚了，不维护过项目，你说破天除了讲几个概念还有什么？
具体的，你只要有足够的基础，能给Linux或者gcc贡献一批代码，不用去学什么软件工程，一堆的工作让你挑，大富大贵没有，小中产是绰绰有余，咱还是这个结论，只要你基础够，软件工程这些东西随便跟两个项目就够。