没有银弹何以制服“不死人狼”
——读《人月神话》第十九章（没有银弹）有感
《人月神话》（英语：The Mythical Man-Month）是由IBM System/360系统之父佛瑞德布鲁克斯（英文名：FrederickP.Brooks.Jr.）所著经典文集，全书讲解软件工程、项目管理相关课题，被誉为软件领域的圣经，内容源于作者布鲁克斯在IBM公司System/360家族和OS/360中的项目管理经验。该书于1975年首次发行（ISBN 0-201-00650-2），并于1995年重新发行纪念版（ISBN 0-201-83595-9）。
《人月神话》全书共十九章，可以说每一章都是软件工程的精华，是软件开发人员的精神食粮，没有任何一本书敢与之媲美，即使是39年后的今天，当我再次读到这本书的时候依然有醍醐灌顶之感。
《没有银弹》这一章节，可以说是本书最重要的章节，也是大家最为在意和讨论的章节。本章以巧夺天工的比喻开题，讲述了在所有恐怖民间传说的妖怪中，最可怕的是人狼，因为它们可以完全出乎意料地从熟悉的面孔变成可怕的怪物。为了对付人狼，我们在寻找可以消灭它们的银弹。
大家熟悉的软件项目具有一些人狼的特性，常常看似简单明了的东西，却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物。因此，我们听到了近乎绝望的寻求银弹的呼唤，寻求一种可以使软件成本像计算机硬件成本一样降低的尚方宝剑。但是，我们看看近二十年来的情况，没有银弹的踪迹。没有任何技术或管理上的进展，能够独立地许诺在生产率、可靠性或简洁性上取得数量级的提高。
所谓的人狼，也就是“软件活动的根本任务”。首先，Brooks认为我们并没有足够的精力来放到“软件活动的根本任务”这一目标之上。根本任务的目标是抽象软件构成的复杂概念结构；次要任务的目标是表达抽象实体，在一定范围内映射成计算机的执行逻辑；我们大多时候在关注次要目标，例如写程序和开发“写程序用的”程序；我们写再多的程序与再强的“写程序用的”程序都不会触及到根本任务。
进一步的分析来说，是我们探索目标的方法，分散了达到目标的力量。软件实体是一个许多概念交织的建筑：数据集、数据项的关系、算法以及引用函数。其本质是抽象的，概念架构在许多不同的表示方式下是一样的。编写软件最困难的部分是规范、设计和测试这种概念架构，而不是表式他的劳动和测试这一表示的可靠性。现代软件系统存在的内在的不可减少的特性有：复杂性(Complexity)、遵守随机的复杂的规范（Conformity）、易变性（Changeability）和不可见性（Invisibility）。高级语言、分时系统、统一编程环境、面向对象编程、人工智能、专家系统、自动化编程、图形化编程都只是解决了编程偶然的困难，而不能解决
编程的内在困难。
1. 复杂性：极端的复杂性不可避免
软件系统与计算机、建筑或者汽车大不相同，后者往往存在着大量重复的部分。由于软件产品特有的复杂度导致了成员之间的沟通非常困难，带来了软件产品的进度，质量和成本多方面的问题。特别是在软件规模增加的时候复杂度往往成倍上升。同时复杂度不仅仅导致技术上的困难，还引发了很多管理上的问题。它使全面理解问题变得困难，从而妨碍了概念上的完整性。所以在复杂性方面，人狼是自疗系的：越做越复杂，不可能变简单。
2. 一致性：要背上不可丢弃的历史包袱
由于Brooks强调新的软件需要保证跟旧的软件兼容，你创生了一个软件也就创生了下一个软件的需求，所有的创生活动产生了需求的自增集合，尽管这种“变体不是必需的”，但它一个不可丢弃的历史包袱。某些情况下，因为是开发最新的软件，所以它必须遵循各种接口。另一些情况下，软件的开发目标就是兼容性。在上述的所有情况中，很多复杂性来自保持与其他接口的一致，对软件的任何再设计，都无法简化这些复杂特性。所以在保证一致性这一方面，人狼是自增长的。
3. 可变性：要接受持续的变更
软件系统包含了很多功能，而功能是最容易感受变更压力的部分。所有成功的软件都会发生变更。现实工作中，经常发生两种情况。当人们发现软件很有用时，会在原有应用范围的边界，或者在超越边界的情况下使用软件。功能扩展的压力主要来自那些喜欢基本功能，又对软件提出了很多新用法的用户们。简言之，软件产品扎根于文化的母体中，如各种应用、用户、自然及社会规律、计算机硬件等等。后者持续不断地变化着，这些变化无情地强迫着软件随之变化。需求是无度和不可控的，所以人狼本身又是变形系的。
4. 不可见性：任务无法全面抽象描述
除去软件结构上的限制和简化方面的进展，软件仍然保持着无法可视化的固有特性，从而剥夺了一些具有强大功能的概念工具的构造思路。这种缺憾不仅限制了个人的设计过程，也严重地阻碍了相互之间的交流。你找不到足够的抽象方法描述软件的不同侧面，也就不能将它们表达为抽象概念上的图形。如果你找到了这样的方法，那么这个“软件”本身就不足够复杂，因此也就不是原本含义上的“根本任务”。所以，它是隐形的——你如果看见了它，要么是看见了诸多复杂的方面中的一面，要么根本就是看错了。
面对一个具有“自增＋自疗＋变形＋隐身”的“不死人狼”，我们何以应对？
一、 在应对“自疗”方面，在软件产品开发工厂化的过程中，我们要注意到仍然解决的是次要因素，比如加大公用组件开发，加大平台和框架的建设，而业务功能本身导致的复杂性是无法避免的。现在市场上有很多快速开发平台，但是真正能够不写代码就完成业务功能的开发平台基本上没有成功的，特别是在业务场景比较复杂情况下，编程自动化基本是不可能的事情。唯一看到有所突破的是关于统一框架和技术平台等方面的建设，在原有的框架基础上我们可以构建一个产品开发平台，将跟业务关系不大的权限模型，工作流引擎等集成进去，将常用的可复用组件集成进去，加快开发速度。我们不能在追求自动编程平台上下功夫，可以在加强组件复用和技术平台建设上下功夫。
二、 在应对“自增”方面，我们要在软件产品的设计过程中，尽可能考虑到软件的可扩展性。
三、 在应对“变形”方面，软件开发的过程必须要考虑如何适应变化，我们要在需求，设计和编码过程中都需要考虑如何快速响应变化，如何提高软件产品的可扩展性。我们在软件开发生命周期模型上强调增量迭代的思路，强调测试驱动的思路其根本目的就是为了快速响应变化，降低变化带来的风险。
四、 在应对“隐身”方面，我们要改进软件开发模型，比如增量迭代的开发模型，快速原型法，测试驱动，高级语言和图形化编程等。
总之，尽管我们或许找不到杀死“不死人狼”的银弹，但是只要我们全面剖析“不死人狼”特性，结合人类的智慧，不断改进工作思路，随机应变，找准突破口总能找到有效克制它的方法。
