《人月神话》变革与矛盾

本文是《人月神话》阅读的一个加餐，不属于任何一个章节，是作者自己的思考，希望对大家有帮助。

PC的出现可以说是《人月神话》成书之后的几十年里最重要的改变，这对于软件工程意味非凡。PC改变了每个人使用计算机的方式，这是一个量变引起质变的例子，即随着时间变化而引起工作方式上的巨大变化。其他行业的暂且不谈，PC的革命改变了每个人开发软件的方式，即便现在廉价的计算机也比1985年Unix工作站还要快，开发者不需要再考虑等待时间、编译时间、读取时间、文件共享等问题。

由此诞生出了一个全新的软件产业——成品软件包装行业

与传统软件行业相比，这个行业的产品能够以低于1程序员1天的成本获得，同时可以完成成千上万的规模销售。这两个产业在很多方面都不同，它们是同时存在着。

注意区分现在的互联网行业，本书没有任何关于它的内容，我也不会讨论

传统软件行业有若干可识别且存在差异：

1. 计算机提供商：提供操作系统、编译器和一些实用程序
2. 应用程序用户：如公共事业单位、银行、保险公司和政府机构等，他们为自己实用的软件开发应用程序包
3. 定制程序开发者：为用户开发私用软件包，这类承包商大多数工作在服务其他行业，这些项目的需求、标准和行销步骤都是与众不同的
4. 商业软件开发者：为市场开发大型应用，如统计分析软件和CAD系统等

对于成品软件行业包装产业中的开发者，面对的是与传统产业完全不同的经济学：软件成本是开发成本与数量的比值，包装和市场成本非常高。在传统的内部应用开发产业中，进度和功能细节是可以协商的；而在竞争激烈的开发市场面前进度和功能支配了开发成本。正如人们所预期的，完全不同的经济学引发了非常不同的编程文化，同时也诞生了一批处于矛盾当中的软件公司。

成品软件产业更加自由，关注结果，而不是流程，在这种趋势下那些天才的个人程序员更容易获得认可，并根据他们的贡献获得奖励。而传统软件产业中，公司的社会化因素和薪资管理计划总会让上述做法难以实施。因此，很多高手总是被吸引到成品软件包装产业，这十分常见。

介于新老之间的矛盾

其实在《人月神话》（P11）为舍弃而计划中已经从微观的角度描述过这种矛盾，当时提出的解决方法也是微观的，这篇加餐的文章将从宏观的角度来给出我认为的方法。

矛盾存在于下面几个点：

1. 试图用成品软件行业的价值观指导传统软件行业，最突出的就是用成品软件的方式来做定制开发，盲目提高包装和市场成本
2. 既没有传统行业的管理风格和企业文化，也没有成品行业的关注结果、行事自由和贡献反馈，对优秀的开发者没有任何吸引力
3. 丢掉了传统行业中的严谨、规范和重视技术，又拿不起成品软件的销量

或多或少具备以上特点的网络公司，大部分都是软件行业发展不成熟的产物，这种不成熟是多方面的，包括市场环境、政府关注、人才培养、市场接受度、业内评判标准等方面。

首先承认现在的软件行业已经分化为多个领域，每个领域都有它独特甚至相反的编程文化，在进行对比和借鉴时一定要明确自己的定位，否则只会适得其反。

使用成品软件作为构件

彻底提高软件健壮性和生产率的唯一途径是，将开发流程拔高一个层面，使用模块或者对象组合来进行程序开发。一个特别有希望的趋势就是使用大众软件包平台（npm，composer），在上面开发更加丰富和定制化的产品，现在已经能够看到许许多多的定制化模板和特殊函数。

使用模板和函数为部分软件用户进行功能定制的过程被称为“元编程”，这并不是新概念，像微软一样的大型信息公司都有专门的专家团队在做这件事（例如Excel中的宏和微信的小程序）。由此产生的元程序形成了二级市场（例如微擎应用商店），这样的市场正在悄无声息的崛起，这是非常令人振奋的。

这种方式使得开发人员可以忽略细节，直接针对概念结构要素打造的根本问题，所以将来一定会快速发展。成品软件提供大量的功能模块和精心定制的接口，它的内部概念结构根本无需再设计。下一级应用程序开发者可以获得丰富的功能、更短的开发时间、经过测试的组件、良好的文档和彻底降低的成本。

如何实现不重要，程序的根本目的是帮助人，程序的根本问题是概念要素的构架

当然，缺点也是有的，成品软件作为独立实体来设计，元程序员无法改变它的功能和接口。作为成品软件开发者，要求他把他的产品做成更大型系统中的一个模块似乎没什么吸引力。但小程序的例子告诉我们，这种想法极可能是错误的，如何为元程序员提供软件包，这里面一定有一个未开拓的巨大市场。

那我们需要怎么做呢？可以把软件成品用户分为以下四个层次：

1. 直接使用用户。他们以简单直接的方式来操作，对设计者提供的功能和接口感到满意（易企秀）。
2. 元程序员。在单个应用程序的基础上，使用已经提供的接口来开发模板或者函数，主要为最终用户节省工作量（Excel宏）。
3. 外部功能工作者。向应用程序添加自行编制的功能。这些功能本质上是应用语言原语，调用通用语言编写的独立模块。这往往需要中断、回调或者重载函数技术，向原接口添加新功能（小程序）。
4. 元程序员。编写特殊的应用程序，作为更大型系统的构件。他们是需求并没有得到满足的用户群（AppleScript）。

成品软件需要对元程序要提供“文档化接口”，这就在很多方面提出了要求：

1. 元程序需要在整个应用程序集的控制之下，而每个软件通常假设是受自己控制的
2. 软件集必须控制用户界面，而应用程序一般认为这是自己的职责
3. 软件整体必须能够调用任何应用程序的功能，就好像参数传递那样
4. 它还应该像屏幕那样能够接受应用程序的输出

未来

相比化学等其他领域，软件工程的发展实在是太慢了，但它并不是没有希望，只是还不够成熟。

想想第一章提出的问题：

1. 如何把一系列程序构建成系统
2. 如何把程序构建成健壮的、经过测试的、文档化的、可用的产品
3. 如何维持对大量“复杂性”的控制

很长一段时间内这些问题还是会使人们举步维艰、不能自拔。软件系统可能是人类创造中最错综复杂的实物，只能期待在力所能及的范围内进行探索和尝试。

这个复杂的行业需要：

1. 时间
2. 坚持学习
3. 优秀新工具的最佳实践
4. 经过论证的工程管理方法的最佳实践
5. 良好的自我判断以及——上帝所赐予的谦卑

自由转载-非商用-非衍生-保持署名（创意共享3.0许可证）