软件工程的真实与谬误

http://del.icio.us 上收藏的一篇书评，随手翻译了一些，原文在：

http://www.codinghorror.com/blog/archives/001083.html

有些条款不理解，也没有上下文，译得暴烂:-)

人

1．软件工作中最重要的因素是程序员的质量。

2．最优秀的程序员比最糟糕的程序员好上28倍。

3．在延期的工程中加入人员，会使工程更为延期。

4．工作环境对生产力和工作质量有深刻的影响。

工具和技术

1. 对工具和技术的炒作(hype)是软件工厂的瘟疫(plague)。
2. 新工具和新技术是生产力和质量流失之源。
3. 软件开发者大量讨论工具，却很少使用它们。

评估(Estimation)

4. 两个常见的导致项目偏离正轨(runaway)的缘故之一是评估不力。
5. 软件评估常发生在错误的时候。
6. 软件评估常由错误的人来完成。
7. 软件评估甚少跟随项目进程而改进。
8. 软件评估不当并不意外，然而我们生死以随。[言下之意是：我们常作出错误的软件评估，虽然明知是错，但我们常常将错就错，一错到底。]
9. 软件管理者和程序员存在断链。
10. 可行性分析的结果通常是：“可以”。

重用

11. 小规模重用可解决问题。
12. 大规模重用依然存在许多问题未能解决。
13. 大规模重用在系列相关系统中工作出色。
14. 可复用组件的构建难度3倍于普通组件，并且需要尝试三种不同的设置。
15. 修改复用代码极易导致错误。
16. 复用设计模式是解决代码复用问题的一个方案。

需求

17. 两个常见的导致项目偏离正轨(runaway)的缘故之一是不明确的需求。
18. 需求错误的修改代价在整个生产过程中最为昂贵。
19. 未被发现的(missing)的需求是需求错误中最难被纠正的。

设计

20. 显式的需求会“爆炸”，就像隐式的需求会导致解决方案演化。[言下之意是：我们认为是需求的需求会暴多，但我们没有洞察到的需求却会左右方案的演化。]
21. 对一个软件问题而言，甚少有个“最好”的设计方案。
22. 设计是个复杂和交互的过程。最初的设计方案通常是错误的，而且显然是未经优化的。

编码

23. 设计者的“初衷”甚少与程序员的“初衷”相符。
24. COBOL是门极为糟糕的语言，然而其他所有语言更为糟糕。:)

除错

29.除错在整个(项目的)生命周期中是个最为耗时的阶段。

测试

25. 当前最好的软件测试也只有55%到60%的覆盖率。
26. 即是100%的测试覆盖率仍然是远远不够的。
27. 测试工具是必备的，然而甚少被用。
28. 自动化测试被夸大了，多数测试不能被自动化。
29. 由程序员编写的，嵌入在代码里的调试代码是对测试工具的很好补充。

复审和检查

30. 严格检查可在第一个测试用例运行前解决90%的错误。
31. 严格检查并不能替代测试。
32. 提交后之复审，事后检查，以及回顾很重要，但甚少执行。
33. 复审包括技术和社会学两方面，且此两个因素必须相互包含。

维护

34. 典型的维护会消耗40%到80%的软件开销。它也许是整个软件生命周期中最为重要的阶段。
35. 加强表现力(represent)大概占据了60%的维护开销。
36. 维护是个解决方案，而非一个问题。
37. 理解维护对象是维护任务中最困难的一环。
38. “更好的方法”导致维护(成本)增加，而非减少。

质量

39. 质量是(各个)属性(的质量)之集。
40. 质量不是用户的满意度、会议需求、预算和日程，也不是可靠性。

可靠性

41. 大多数程序员都有犯某些错误的倾向。
42. 错误倾向积聚(出现)。
43. 没有一个最好而又简单的途径解决软件错误。
44. 总是存在清楚未尽的错误。我们的目标应该是最小化或者消灭掉严重错误。

效率

45. 效率更多的源自设计而非编码。
46. 高级语言能到达相应汇编代码的90%的效率。
47. 折中时间优化和空间优化。

研究

52.多数研究者喜欢主张胜过求证。