《软件工程的事实与谬论》 之五十五大事实

近期有幸阅读到《软件工程的事实与谬论》一书，作者对于软件工程的相关内容见解颇深，在此与各位读者分享、探讨：

一、人员

　　事实1：在软件开发中，最重要的因素不是程序员采用的工具和技术，而是程序员自身的质量。

　　事实2：对“个体差异”的研究表明，最好的程序员要比最差的程序员强28倍之多，即使他们的报酬不同，优秀的程序员也是软件业中最廉价的劳动力。

　　事实3：给延期的项目增加人手会使项目进一步延期。

　　事实4：工作环境对工作效率和产品的质量具有深刻的影像。

二、工具和技术

　　事实5：夸大宣传是软件的瘟疫。多数软件工具对于效率和质量的提高幅度仅为5%～35%。但是总有人反复说提高幅度是“数量级”的。

　　事实6：在学习新工具或者新技术的初期，程序员的工作效率和产品质量都会下降，只有克服了学习曲线之后，才可能得到实质性的收益。只有满足下面两个条件，采用新工具或新技术才有意义：(a)新东西确实有用；(b)要想获得真正的收益，必须耐心等待。

　　事实7：软件开发者对于工具说的多，评估的少，买的多，用的少。

三、估算
   
    事实8：项目失控的两个最主要原因之一是糟糕的估算。
   
    事实9：许多估算是在软件生命周期开始时完成的。后来，我们才认识到在需求定义之前，即理解问题之前进行项目估算是不正确的；也就是说，估算实际是错误的。
   
    事实10：许多软件项目都是由高层管理人员或者营销人员来估算，而不是由真正构建软件的人或者他们的主管来进行估算。因此，估算软件的人员是错误的。
   
    事实11：软件估算很少根据项目进度进行调整。因此，这些估算通常是错误的人在错误的时间的出的错误的结果。
   
    事实12：因为估算的数据如此糟糕，所以在软件项目不能达到估算目标时，不应该再考虑估算。但是无论如何，每个人都在考虑它。
  
    事实13：在管理者和程序员之间存在隔阂。对于一个未满足估算目标的项目的调查表明：从管理者看来这是一个失败的项目，而在技术人员看来却是最成功的项目。
   
    事实14：对于可行性调研的回答几乎总是“可行”。

四、复用
   
    事实15：小规模的复用（子程序库）开始于50多年以前，这个问题已经得到很好的解决。
   
    事实16：虽然每个人都认为大规模复用（组件）非常重要、非常急需，但是这个问题至今还没有基本解决。
   
    事实17：大规模复用最好适用于相关的系统，也就是依赖于具体应用领域，这样就限制了它的应用范围。
   
    事实18：有关复用问题，有两个“三倍法则”：（a）构建可复用的组建比使用组建难三倍；（b）在将组建收录到复用库并成为通用组件之前，应该在三个不同的应用中尝试应用该组件。
   
    事实19：修改复用的代码特别容易引起错误。如果一个组件中超过20%～25%的代码需要修改，那么重新实现的效率会更高。
   
    事实20：设计模式复用是解决代码复用中故有问题的一种方法。

五、复杂性
   
    事实21：问题的复杂性每增加25%，解决方案的复杂性就增加100%。这不是一个可改变的条件（即使人们都努力降低复杂性），而是客观存在的。
   
    事实22：80%的软件工作是智力活动。相当大的比例是创造性的活动。很少是文书性的工作。
   
    事实22，好像忽略了“体力劳动”?
   
六、需求
   
    事实23：导致项目失败的两个最常见原因之一是不稳定的需求（另一个见事实8所说的项目估算失误）。
   
    事实24：在产品完成时修订需求错误的代价最大，在开发早期修订需求错误的代价最小。
   
    事实25：遗漏需求是最难修订的需求错误。

七、设计
   
    事实26：从需求转入设计，因为制定方案过程的复杂性，会激增出大量的衍生需求（针对一种特定设计方；案的需求）。设计需求是原始需求的50倍之多。
   
    事实27：对于一个软件问题，通常不存在惟一的最佳设计方案。（对于同一个问题的定义，多位优秀的设计者通常也不可能提出完全相同的最优设计方案。“在一个房间中坐满了顶级的软件设计人员，如果其中任意两个人达成一致，那就可以通过了”）
   
    事实28：设计师一个复杂的、迭代的过程。最初的设计方案可能是错误的，当然也不是最优的。

八、编码
   
    事实29：从设计转到编码阶段时，设计者按照自己掌握的水平，已经将问题分解为“原语”。如果编程者和设计者不是同一个人，二者的“原语”不吻合，就会出现问题。
   
    事实30：COBOL是一种非常糟糕的语言，但是其他的（用于商业数据处理的）语言也同样糟糕。

九、错误消除
   
    事实31：错误消除是软件生命周期中最耗时的阶段。

十、测试
   

    事实32：普通程序员认为已经彻底测试过的软件其实只执行了55%～60%的逻辑路径。采用覆盖分析器等自动工具，可以将上述比例提高到85%～90%。几乎不可能测试软件中100%的逻辑路径。
   
    事实33：及时测试覆盖可能达到100%，这种测试也不够。大约35%的错误是源于逻辑路径的缺失，还有40%的错误源于执行特定的路径组合。不可能实现100%的覆盖。
   
    事实34：没有工具就无法做好错误消除工作。人们常用调试器，很少使用覆盖分析器等其他工具。
   
    事实35：自动测试很少，也就是说有些测试可以也应该自动化，但是有许多测试任务不能自动完成。
   
    事实36：程序员在程序中嵌入测试代码、目标代码中的编译参数等方法，都是测试工具的重要补充。

十一、评审和检查
   
    事实37：在运行第一个测试用例之前进行严格审查可以消除软件产品中多大90%的错误。
   
    事实38：虽然严格审查由很多优点，但是不能也不应该代替测试。
   
    事实39：通常认为，事后评审对于了解客户的满意度和改进过程都很重要。但是很多软件公司不开展事后评审。
   
    事实40：同行评审涉及技术和社会两方面问题，忽视任何一方面都会产生严重的灾难。（这一点一定要记住，现在已经遇到这方面的问题，经理参与技术评审，往往偏离主题，他们评审的不是技术，而是技术人员。通常搞得技术人员非常不爽。关系好的一帮人员一起评审，也应该抛开个人因素，记住，评审的是技术，不是人。）

十二、维护
   
    事实41：维护开支通常占软件成本的40%～80%（平均为60%）。因此，维护可能是软件生命周期中最重要的阶段。
   
    事实42：增强功能大约占软件维护成本的60%，错误更正仅占17%。因此，软件维护的主题是在旧软件中加入新功能，而不是更正错误。
   
    事实43：维护是解决方案，而不是问题。
   
    事实44：比较软件开发和软件维护中的工作，除了维护中“理解现有的产品”这项工作之外，其他工作都一样。这项工作占据了大约30%的维护时间，是主要的维护活动。因此可以说维护比开发更难。
   
    事实45：更好的软件工程开发导致更多而不是更少的维护。

十三、质量
   
    事实46：质量是一组属性的组合。
   
    事实47：软件质量不是用户满意、满足需求、满足成本和时间表目标，或者可靠性。

十四、可靠性
   
    事实48：绝大多数程序员都会犯某些错误。
   
    事实49：错误通常聚集在一起。
   
    事实50：没有惟一最好的消除软件错误的方法。
   
    事实51：总会有残存的错误。我们的目标应该是消除严重错误，或者使之最少。

十五、效率
   
    事实52：效率主要来自于优秀的设计，而不是优秀的编码。
   
    事实53：高级语言代码配合适当的编译器优化，大约可以达到汇编语言90%的效率。对于一些复杂的现代体系结构，效率更高。
   
    事实54：在空间和实践之间折中。通常，改进一方面会降低另一方面。

十六、研究
   
    事实55：许多软件研究者不是做调查，而是鼓吹。因此，（a）有些概念比鼓吹的糟糕、更少；（b）缺少有助于确定这些概念真实价值的评估性研究。