4，软件工程的借鉴之处
众所周知，20世纪中叶爆发的软件危机是世界软件业的灾难，严重的后果迫使各行业与软件相关的专家总结原因，于是便产生了《软件工程》。软件危机爆发的原因，简单地说是软件变得越来越大，但软件开发人员的思维却没有跟上。由于课件的大小有限，再加上有“软件危机”的前车之鉴，爆发“课件”危机的可能性几乎为零。但《软件工程》总结的经验对课件却是同样适用，当然我们不能照搬，只能继承，因为软件是一般类，课件是特殊类。
4.1,谈到软件工程，有以下几点不得不谈：复用，结构化程序设计，优化与取舍，可理解性。
4.1.1,复用就是指“利用现成的东西”，也就是鲁迅先生的“拿来主义”。被复用的对象可以是有形的物体，也可以是无形的成果。复用不是人类懒惰的表现而是智慧的结晶。有数据表明，
在大的软件公司复用率高达90%。这并不表明工作量变为复用前的十分之一，因为开发一个可复用的构件的代价是一般开发的2到4倍，使用复用构件也需要不少的工作量。况且常常有失败的复用构件，主要指开发的构件没有人使用。但总的来说是大幅度地提高了效率。
复用不但提高了效率，更重要的是提高了质量。因为那些构件以前就通过了测试，还可能被多次使用，所以可靠性比较强。如果是Active控件的话，质量更高，因为这些开发者都是程序员中的绞绞者。优秀的程序员可以使用自己熟悉的语言编写控件，另一些程序员可以像使用标准控件一样使用它。举个例子来说，我们编写一个十以内加减法的课件。课件自动生成一个算式，如：4+5。然后让学生输入结果，再根据学生的答案作出反应，注意要美观。我们可以用vc编写一个控件，它有两个方法，一个随机产生一个算式，并以字符串的形式提供给使用者，同时计算出结果，另一个方法是把结果提供个用户。然后用Authorware
编个框架，将控件拖上去就可以了。
开发控件要注意：应用范围要广，我们可以去买铁钉，但我们买不到抽屉，因为卖出抽屉的可能性太小，商家没有利润。做控件也是这样，我们不能做一个控件，它只能对10个数进行排序，这样它被用到的可能性就太小了，它应该改成可以对任意多个数进行排序。
4.12,结构化程序设计原则：
1，模块化
2，自顶向下
3，逐步细化。
它的思想是把一个复杂的问题分解成若干个简单的问题，然后逐个解决。并且每个部分间的联系尽量少，以避免发生“举一发而动全局”。这种朴素的思想来源于人们生活与工作的经验，完全适合于技术领域。软件在执行分而治之的时候，应该着重考虑：复杂问题分解后，每个问题能否实现？最终能否集成为一个课件并有效解决原始的复杂问题？
4.13,优化与取舍
软件的优化是指优化软件的各个质量因素，如提高运行速度，提高对内存资源的利用率，使用户界面更加友好，使三维图形的真实感更强等等。想做好优化工作，首先要让开发人员都有正确的认识：优化工作不是可有可无的事情，而是必须要做的事情。当优化工作成为一种责任时，程序员才会不断改进软件中的算法，数据结构和程序组织，从而提高软件质量。
软件取舍的重要原则是不能使某一方损失关键的职能，更不可以象“舍鱼而取熊掌”那样抛弃一方。例如3D动画软件的瓶颈通常是速度，但如果为了提高速度而在程序中取消光照明计算，那么场景就会丧失真实感，3D动画也就不再有意义了(如果人类全是色盲，计算机图形学将变得异常简单)。最典型的方法是空间换时间，计算一个整数(0到255)的二进制形式有多少位是1，我们可以做一个表将0到255中1的个数存储来，以后直接查表就可以了。
4.14,可理解性理解起来简单，做起来就太难了。
4.2,下面我们列出一些不正确的软件工程观念，以帮助初学者少犯相似的错误。
观念之一：我们拥有一套讲述如何开发软件的书籍，书中充满了标准与示例，可以帮助我们解决软件开发中遇到的任何问题。
“尽信书，不如无书”，“尽不信书，也不如无书”。好的参考书无疑能指导我们的工作。充分利用书籍中的方法、技术和技巧，可以有效地解决软件开发中大量常见的问题。但实践者并不能因此依赖于书籍，这是因为：1，现实的工作中，由于条件千差万别，即使是相当成熟的软件工程规范，常常也无法套用。2，软件技术日新月异，没有哪一种软件标准能长盛不衰。祖传秘方在某些领域很吃香，而在软件领域则意味着落后。这一套书只能算工具书。我必须不断地看新出版的书，并经常上网看一些还不成熟的东西，这样才能保证不落伍。
观念之二：我们拥有最好的开发工具、最好的计算机，一定能做出优秀的软件。
有最好的计算机，但没有最好的工具。就算真有最好的工具，大部分人也会选择。如果一个人能力有限的话，再好的计算机和工具也没有用。
观念之三：如果我们落后于计划，可以增加更多的程序员来解决。
软件开发的大忌：临时加人。（1）首先增加的程序员不会有好的情绪，他们有更大的可能把事情弄糟。（2）项目负责人必须和新加的程序员进入广泛的交流，很可能涉及到其它程序员。这将花去比较多的时间。（3）由于不熟悉环境，新加入的程序员很可能犯错误，而错误很可能影响到软件的其它部分。
观念之四：既然需求分析很困难，不管三七二十一先把软件做了再说，反正软件是灵活的，随时可以修改。
一个错误发现的越早，付出的代价越少。一个错误在分析时被发现，只花了1000元。如果在维护时才发现，可能会花40000元。这种可怕的思想可能使整个软件失败，IBM的某个操作系统失败的原因与这类似，发现了 1000多个错误，不得不修改，修改后又发现了1000多个错误…最后不得不放弃。
4.3,下面的一些问题，是非对错尚无定论，但的确值得思考。
争议之一：如果软件运行较慢，是换一台更快的计算机，还是设计一种更快的算法？
我的观点：如果开发软件的目的是为了学习或是研究，那么应该设计一种更快的算法。如果该软件已经用于商业，能换计算机就换计算机，如果不能完全解决才换算法，但算法还是要设计出来，备用。换算法，将引进许多错误，带来艰巨的维护工作。事实上，用户换不换设备是用户的事，你不可能要求用户更换，所以常常不得不设计更快的算法。“早知如此，何必当初”，最好的办法是在开发的时候考虑好时间复杂度。
争议之二：有最好的软件工程方法，最好的编程语言吗？
我的观点：在软件领域永远没有最好的，只有更好的。能解决问题的都是好方法或是好语言。程序员在最初学习Basic、Fortran、 Pascal、C、C++等语言时会感觉一个比一个好，不免有喜新厌旧之举。而如今的Visual Basic、Delphi、Visual C++、Java等语言各有所长，真的难分优劣。开发人员应该根据客观条件，选择自己熟悉的方法和语言，才能保证合格的质量与生产率。 程序设计是自由与快乐的事情，不要发誓忠于某某主义而自寻烦恼。
争议之三：编程时是否应该多使用技巧？
我的观点：技巧肯定要使用，但不要为了使用技巧而使用技巧。使用技巧之前，好好考虑一下这个技巧可以带来什么好处，其它程序员容易理解吗？
争议之四：软件中的错误是否可按严重程度分等级？
我的观点：在定量分析时，可以将错误分等级，以便于管理。微软的一些开发小组将错误分成四个等级 [Cusumano 1996]：
一级严重：错误导致软件崩溃。
二级严重：错误导致一个特性不能运行并且没有替代方案。
三级严重：错误导致一个特性不能运行但有替代方案。
四级严重：错误是表面化的或是微小的。
上述分类是对开发人员而言的，并不是说明使用时出错的严重性。事实上，一级严重常常不会带来灾难性的后果，因为错误太明显了，用户常常有了防范。举个例子：A使软件无法运行，B是桥梁软件的一个数学函数的错误，它只是精度不够，如果多次使用的话，误差会积累，于是产生灾难性的后果。显然A是一级严重，B是四级严重。开发人员应该意识到：所有的错误都是严重的，不存在微不足道的错误。这样才能少犯错误。
