[人月神话_7] 再论《没有银弹》

我们继续 上一篇中的《没有银弹》 [人月神话_6] 另外一面 | 一页流程图 | 没有银弹 来看

"No Silver Bullet" Refired

银弹的希望

• 现有的所谓“银弹”技术更多的是针对软件开发过程中的一些非核心障碍提供了不同程度的帮助，而未能从根本上解决软件固有的复杂性问题。
• 未来的软件开发仍需探索新的方法和技术，以应对那些深层次的挑战。

以下是对几种关键技术及其潜力和局限性的分析：

1.Ada和其他高级编程语言

• Ada作为80年代出现的一种高级语言，引入了抽象数据类型、模块化设计等现代编程概念，极大提升了代码的可维护性和复用性。
• 然而，尽管Ada在教育开发者方面做出了贡献，它并未从根本上解决软件复杂度的问题。

这类高级语言的主要优势在于它们减少了与硬件相关的次要困难，但对软件本质复杂性的改善有限。

2.面向对象编程（OOP）

• OOP通过提供抽象数据类型和层次化类型的概念，使得设计者能够更清晰地表达其意图而不必过多已关注底层实现细节。
• 虽然这种方法有助于简化某些方面的开发过程，但它并没有直接触及到软件设计的核心挑战——即如何管理日益增长的系统复杂性。

因此，OOP更多地表现为一种增量式的改进而非革命性的突破。

3.人工智能（AI）与专家系统

• AI被分为两种主要形式：一是解决需要人类智能才能处理的问题；
• 二是模仿人类专家解决问题的方式。
• 后者如专家系统，在特定领域内展示了强大的能力，尤其是在将应用逻辑与程序本身分离方面。
• 然而，AI的应用范围广泛且分散，不同领域的技术差异很大，这意味着没有单一的AI解决方案可以适用于所有类型的软件开发问题。

对于软件开发而言，AI最有价值的地方可能是辅助工具，例如自动测试建议或优化指导，而不是完全替代传统的编程实践。

4.“自动”编程

• 尽管多年来关于自动编程的讨论从未停止，但实际上，真正意义上的全自动编程尚未实现。
• 目前所谓的“自动编程”往往指的是基于规则的选择和生成机制，适用于参数明确、解决方案库丰富的场景。
• 然而，大多数实际软件项目远比这复杂得多，涉及大量的决策和创造力，难以自动化。

5.图形化编程

图形化编程试图通过可视化界面来简化编程流程，但至今为止，还没有证据表明这种方法能显著提升生产效率。

• 一方面，图形界面的空间限制使得复杂系统的全面展示变得困难；
• 另一方面，软件本身的抽象特性也决定了它不适合简单的图形表示法。

因此，图形化编程更多地停留在理论探讨阶段，并未成为主流开发方式。

6.程序验证

• 程序验证旨在确保程序符合预定的技术规格说明，这对于安全关键型应用至关重要。
• 不过，验证过程本身极其耗费资源，且无法保证绝对无误。
• 此外，即使程序经过严格验证，仍需面对规格说明是否准确的问题。

因此，程序验证虽有其重要性，但并不足以成为提高整体软件质量的“银弹”。

7.环境与工具

• 更好的开发环境和工具确实能够带来一定的生产力提升，比如通过集成数据库跟踪开发细节、利用智能化编辑器减少语法错误等。
• 但是，这些改进大多属于边际效益，难以彻底改变软件开发的本质难题。

8.工作站性能

• 随着工作站性能的持续提升，编译时间和其他计算密集型任务得到了极大的加速。
• 但这并未改变开发者思考和设计的时间占比。

因此，虽然更强的工作站是受欢迎的进步，但它们同样不能被视为解决软件开发中根本问题的灵丹妙药。

---

软件开发中的现实进步与策略

• 尽管软件领域尚未出现如硬件那样的革命性突破，但现实中存在着大量优秀的工作和稳步的进步。
• 为了提升生产率，我们首先需要理解软件开发过程中的主要挑战，并识别那些真正能带来显著改进的技术。

生产率公式的思考

• 在评估软件生产率时，可以使用一个简化公式：任务时间 = ∑（频率）i×（时间）i。
• 如果创造性工作占据了大部分时间，那么仅是表达概念的活动对整体生产率的影响有限。

因此，已关注点应放在解决必要困难上——即如何准确地表达复杂概念结构。

商用软件的价值

• 随着个人计算机市场的兴起，商用软件的质量和数量都有了显著提升。
• 对于许多应用而言，购买现成的软件包通常比重新开发更经济高效。

这些软件不仅立即可用，而且往往拥有良好的文档支持，维护得更为完备。这种趋势使得软件成本更多地体现在开发而非复制上，即使少量用户共享也能大幅降低成本。

快速原型化的重要性

在软件开发中，最棘手的问题之一是明确需求。

• 客户往往不清楚自己确切的需求，而详细技术需求的确定又是极其复杂的。
• 为了解决这一问题，快速原型化方法显得尤为重要。
• 通过构建可交互的系统模型，开发者可以让客户直观地体验未来系统的功能，从而更好地理解和细化需求。

这种方法强调迭代反馈，确保最终产品符合用户的期望。

增量开发的力量

增量开发是一种类似于生物成长的过程，它允许系统逐步进化，而不是一次性搭建完成。

（我们平时的学习 也应该是一种增量学习

• 这种方式不仅能提高团队士气，还能让每个新功能或模块自然融入已有系统，便于跟踪和管理。
• 实践证明，这种方法能够支持开发出比传统方式更加复杂且稳定的系统。

卓越设计人员的培养

• 最后，软件行业的核心竞争力在于人才。
• 卓越的设计人员能够创造出既快又小、简单优雅的产品，实现成本效益最大化。

因此，机构应当重视并投入资源去发现、培养这些顶尖人才。具体措施包括：

• 早期识别

尽早识别有潜力的设计人员，他们未必是最有经验的人。

• 职业导师

为每位设计人员配备职业导师，指导其技术成长和发展路径。

• 个性化计划

制定全面的职业发展计划，涵盖高级教育、短期课程及技术领导力培训。

总之，虽然没有单一的“银弹”可以解决所有软件开发难题，但通过采用商用软件、快速原型化、增量开发以及培养卓越设计人员等策略，我们可以有效地应对当前面临的挑战，推动软件工程向更高层次发展。

---

《没有银弹》("No Silver Bullet")在这篇文章中，Brooks探讨了为什么在当时看来并没有一个单一的方法或技术（即所谓的“银弹”）可以解决所有软件开发中的问题

• 并且他预测在未来十年内也不会出现这样的方法。
• 再论《没有银弹》提醒我们，面对软件开发中的难题时应保持谨慎乐观的态度，认识到没有任何一种解决方案能适用于所有情况。（其实 也就像我们的生活一样）
• 相反，我们应该继续探索多方面的小幅改进，并结合具体场景选择最合适的方法来应对挑战。

存在着银弹－就在这里？

《人月神话》一文因其深刻的见解而广受认可，几乎无人质疑其核心论点。

然而，《没有银弹》却激发了广泛的讨论和争议，辩论至今未息。

• 大部分观点，但对“不存在绝对解决方案”的核心论点持有异议，并且坚信他们已经发现了能够解决软件开发难题的“银弹”。
• 回顾1986年至1987年间收到的一些早期反馈，可以发现那些当时被热烈推崇为灵丹妙药的方法和技术，并未能如预期般带来革命性的变化。
• 这提醒我们，在评价新技术或方法的有效性时，应当谨慎行事，尤其是当涉及到声称能大幅提升效率或生产力的时候。

对于任何宣称找到了“银弹”的说法，作者持开放态度，前提是这种方案必须经过实践验证。

就像购买计算机软硬件时依赖真实用户的正面反馈一样，如果有一种方法、工具或产品确实能使某位中立客户的软件生产率提升了十倍，那么这样的见证将极具说服力。

（量化 才是最有力的证据，要不然 一切 都是空谈）

本质（essence）和次要（accident）

软件开发中两个关键方面：本质（essence）和次要（accident）。

这里“accident”并不意味着偶然或不幸，而是指那些附带的、从属的实现细节。而“essence”指的是软件概念结构的本质部分，即那些必须被构思和设计的核心思想。

• 在软件开发过程中，人们往往容易将注意力集中在所谓的“次要”的实现细节上，比如编写代码的具体方式、工具的选择等。
• 然而，这些并不是他所认为的软件开发的主要挑战所在。
• 真正重要的挑战在于如何解决软件开发的本质问题——即如何构思软件的概念性结构。
• 这些问题包括但不限于复杂性、一致性、可变性和不可见性，它们是固有的，并且不会因为技术的进步而消失。

关于术语“accidental”，作者并没有贬低这部分工作的重要性，而是试图区分出哪些工作是对最终产品有直接贡献的核心任务，哪些是为实现这些核心任务而必需但本身不是核心的任务。

• 例如，选择编程语言或编译器、管理内存分配等都是实现上的问题，属于次要部分；
• 而定义系统的架构、设计用户界面、规划数据流等则是本质性的任务。

随着技术和实践的发展，我们已经在减少处理次要问题的时间投入。

当次要部分只占据开发工作的小部分时（例如少于90%），即便我们能够通过某种方式将这一小部分的时间减少到零，这并不会对整体项目进度产生数量级上的改善。

• 这是因为大部分时间实际上是花费在解决本质问题上，而不是在处理次要问题。
• 环境和次要因素只能降低生产率，而不能增加它。
• 这意味着，要真正提高软件开发的效率，我们必须已关注于解决那些与概念性结构相关的本质问题，而不是仅仅优化实现过程中的次要问题。
• 尽管存在固有的复杂性，但这并不意味着没有希望改善现状。
• 通过采用更高级的方法和技术，如模块化设计、重用现有组件等，我们可以更好地应对复杂性，从而在现实中取得有意义的进步。

探索新的理论框架来理解和简化系统复杂性，并强调了层次化和增量化的开发策略对于管理复杂性的价值。

生产力增长与需求增长之间的差距

生产力增长与需求增长之间的差距是一个关键话题。

• 这个差距反映了软件开发能力（即生产力）和市场或业务对软件产品和服务的需求之间存在的不匹配。

生产力增长

生产力增长指的是单位时间内生产出的有用输出量的增加。

• 对于软件工程来说，这通常意味着开发者能够更快、更高效地编写代码，创建功能丰富且可靠的软件系统。

影响生产力的因素包括但不限于：

• 技术进步：新的编程语言、框架、库和工具可以简化开发过程，提高效率。
• 自动化：通过CI/CD流水线、测试自动化等手段减少人工干预，加快交付速度。
• 方法论改进：敏捷开发、DevOps等现代软件开发实践有助于团队更好地协作并响应变化。

然而，尽管这些因素促进了生产力的增长，但它们往往跟不上市场需求的步伐。

需求增长

随着信息技术的快速发展，社会各行业对软件解决方案的需求急剧膨胀。

这种需求不仅体现在数量上的增多，还表现在复杂度和定制化程度上：

• 数字化转型：企业为了保持竞争力，纷纷启动数字化项目，需要大量的软件支持。
• 用户体验要求：用户期望更高的交互性和个性化服务，促使应用更加复杂。
• 安全性和合规性：随着网络安全威胁的加剧以及法律法规的变化，软件必须满足严格的安全标准。

因此，虽然生产力确实在逐步提升，但由于需求侧的快速扩张，两者之间的差距仍然存在，并且可能还在扩大。