类别: 编程
出版年份: 2008
阅读年份: 2020
最高
阅读次数: 1
总页数: 233
摘要（页）: 0
原始出版语言:
英语
其他语言的翻译: 俄语, 中文
基本信息
这本书是2008年出版的，包含了关于开发者和编程的一些事实和误区，共55个事实和10个误区。所有材料被分为特定的类别，例如：管理、开发等。
首先需要说明的是，几乎所有作者讨论的主题和问题都具有争议性（引发激烈辩论），不同的读者可能会有非常不同的看法。为了节省时间和篇幅，我不会在每个点上描述我的观点和看法。在这里，我将简要列出所有的事实和误区，并在最后给出对这本书的总体评价。每个事实或误区的内容大致相当于一篇中等篇幅的文章，因此，如果您感兴趣，可以不读整本书，而是选择具体的主题。在列出所有事实和误区之前，还需要指出，作者在呈现材料时遵循了明确的结构：
- 首先，他讨论事实或误区本身。
- 然后，描述围绕该问题的争论和辩论。
- 最后，列出与该主题相关的信息来源。
编程事实
人类因素
- 软件开发中最重要的因素不是程序员使用的方法和工具，而是程序员本身。
- 根据个性差异的研究，最优秀的程序员的表现是最差程序员的28倍。如果考虑到他们的薪酬永远无法与其能力相匹配，那么最好的程序员就是软件行业最有价值的投资。
- 如果项目无法按时完成，那么增加人手反而会让它更加延迟。
- 工作环境对生产力和成果质量有着强烈的影响。
- 关于工具和方法的广告和炒作是软件行业的瘟疫。大多数工具和方法的改进只能将生产力和质量提高约5-35%。但是，许多这些改进被宣传为能带来“数量级”的优势。
- 学习新方法或工具在初期会降低程序员的生产力和产品质量。只有当学习曲线完成后，才能从学习中获得实际的益处。因此，只有当您看到了新方法和工具的真正价值，并且有耐心等待其收益时，才有必要引入新的方法和工具。
- 开发人员经常谈论工具和方法。他们尝试了许多工具，购买了足够多的工具，但实际上却很少使用它们。
- 项目无法控制的最常见原因之一是估算不准确。（第二个原因在事实23中讨论。）
- 大多数软件项目的估算发生在生命周期的早期。在我们意识到估算是在需求未确定之前做出的，且任务尚未研究时，这一点才会让我们感到困惑。因此，估算通常是做得不合时宜的。
- 大多数软件项目的估算是由高级经理或市场营销人员做出的，而不是由实际开发人员或他们的领导做的。因此，估算通常不是由合适的人做的。
- 软件项目的估算很少在后期进行修正。换句话说，由不合适的人做出的、不合时宜的估算通常不会被纠正。
- 由于估算通常不准确，因此不必太担心软件项目未能按估算的时间完成。然而，大家仍然对此感到担忧。
- 管理人员和程序员之间缺乏沟通。在一项研究中，关于一个未能按估算要求完成的项目，管理层认为它是失败的项目，而技术人员则认为它是他们曾经参与过的最成功的项目。
- 项目可行性分析几乎总是给出“是”的答案。
- “小规模的重用”（在子程序库中）早在50年前就已出现，并且这一问题已得到很好的解决。
- “大规模重用”（在组件中）的任务仍然主要未得到解决，尽管大家一致认为它非常重要。
- 大规模重用的成功往往发生在相关系统的家族中，因此与领域密切相关。这限制了大规模重用的潜在适用性。
- 重用实践中有两个“三原则”：a）多次重用的组件比一次性组件的工作量大三倍；b）多次重用的组件必须在三个不同的应用中进行测试，才能认为它足够通用，可以加入组件库。
- 修改重用的代码非常容易出错。如果需要修改组件的超过20-25%的代码，最好从头开始重写它。
- 重用设计模式是解决代码重用相关问题的方案。
- 任务复杂性增加25%会使得程序解决方案复杂度增加100%。这不是一个可以改变的条件（尽管复杂性始终最好尽量降低），而是现实中的情况。
- 80%的软件开发工作都是智力劳动，其中相当大一部分可以算作创造性工作。只有一小部分是技术性的工作。
需求
- 项目管理失败的两大常见原因之一是需求的变化。（另一原因在事实8中讨论。）
- 如果错误是在运营阶段发现的，修改需求的成本是最贵的，而如果在开发的早期发现，这个成本最便宜。
- 缺失的需求是最难纠正的错误。
设计
- 随着从初始需求到架构的推进，迎面而来的是一系列“衍生需求”（针对具体项目解决方案的需求），由过程复杂性引发。这些衍生需求的清单往往比最初的需求长50倍。
- 最佳的编程设计解决方案很少是唯一的。
- 设计是一个复杂的迭代过程。最初的设计解决方案往往是错误的，且无疑不是最优的。
编码
- 程序员从设计转到编码时，是在任务被拆解到“原始元素”时进行的，而这些原始元素是由设计者掌握的。如果编码者和设计者是不同的人，设计者的原始元素可能与编码者的原始元素不匹配，这将导致问题。
- COBOL是非常糟糕的语言，但所有其他用于处理商业数据的语言都更糟。
- 错误消除阶段是生命周期中最费力的阶段。
测试
- 结果显示，在软件中，典型的程序员认为它已经经过充分测试的情况，实际上仅检查了大约55-60%的逻辑路径。使用自动化工具，如覆盖分析工具，可以将此比例提高到大约85-90%。几乎不可能测试软件的100%逻辑路径。
- 即使能够实现100%的测试覆盖率，它也不能作为测试充分性的标准。大约35%的软件缺陷是由于遗漏的逻辑路径造成的，另外40%与执行独特的逻辑路径组合相关。这些缺陷在100%测试覆盖的情况下无法被发现。
- 没有工具，几乎无法高质量地进行错误修复工作。调试器被广泛使用 – 与其他工具（例如测试覆盖分析器）不同。
- 测试很少自动化。某些测试过程可以并且应该自动化。但与测试相关的大部分工作是无法自动化的。
- 对测试工具的一个重要补充是程序员编写的内嵌调试代码，最好根据编译指令将其包含在目标代码中。
- 仔细的检查可以在第一个基准测试运行之前消除多达90%的错误。
- 仔细的检查带来了许多好处，但它们不能替代测试。
- 普遍认为，事后回顾（也称为回顾性审查）在消费者（软件用户）和过程改进方面都很重要。然而，在大多数组织中，回顾性审查并没有进行。
- 在检查中，除了技术因素，还涉及社会因素。将过多的注意力集中在一个方面而忽视其他方面，是通向灾难的直接路径。
- 维护成本通常占软件成本的40%到80%（平均60%）。因此，这个生命周期阶段可能是最重要的。
- 大约60%的维护开销用于代码改进，约17%用于修复错误。因此，软件的维护和支持主要是在为其增加新功能，而不是修复问题。
- 维护是解决方案，而不是问题。
- 如果比较软件开发和维护任务，它们在大多数情况下是相似的，唯一不同的是维护任务被定义为“研究受维护产品”。它大约占维护时间的30%，并且是维护活动的主导。因此，可以说，维护比开发更费力。
- 提高软件开发质量会导致维护工作量的增加，而不是减少。
质量
- 质量是属性的集合。
- 质量不能仅通过用户满意度、符合客户要求、价格的可接受性、按时交付或可靠性来定义。
- 有些错误是大多数程序员容易犯的。
- 错误有形成聚集的倾向。
- 尚未有一种最佳的方法来消除错误。
- 错误是不可避免的。目标是避免关键错误或将其最小化。
效率
- 效率更依赖于应用程序的优质设计，而不是优质编程。
- 在高阶语言中编写的代码，如果用合适的优化参数编译，其效率可以达到与功能上相当的汇编代码90%的效果。在一些复杂的现代架构中，效率甚至可能更高。
- 在大小优化和速度优化之间存在权衡。通常提高一个指标会导致另一个指标的下降。
关于科学研究
- 许多从事编程工业的科学家倾向于更多地捍卫他们的理论，而不是进行研究。结果是：a）一些被宣传的理论的价值远低于其推广者的想法；b）缺乏旨在帮助确定这些理论实际价值的研究。
编程误区
- 无法管理无法衡量的事物。
- 管理层可以使软件产品变得高质量。
- 编程应该是无个性的。
- 工具和技术是通用的。
- 编程需要更多的 методологий。
- 要评估成本并确定时间表，首先要计算代码行数。
- 使用随机输入数据是优化测试的好方法。
- “所有错误都会显现出来，只要足够多的人关注它们”。
- 知道上次支持的成本，就可以预测将来支持的成本，并做出是否更换产品的决策。
- 通过展示如何编写程序，便能教会人们编程。
结论
尽管这本书写于2008年，但我仍然建议那些学习编程的人阅读它。从缺点来说，首先，最显眼的是很难验证或反驳作者在某些事实中提到的百分比和数字。此外，也有一些事实今天已经不再适用。然而，绝大多数材料仍然是相关的，阅读它不仅对开发人员有益，对于管理人员也同样有帮助。
