作坊与工厂之间:软件工厂早期发展史(1968‑1999)

今天聊聊软件工厂早期的起源。“软件工厂”这个提法可能比你我年龄都大，是一个标准的60后——1968年，当通用电气的R.W. Bemer第一次提出这个概念时，登月计划还在进行中，大多数程序员们正在用打孔卡一行一行地“编织”代码。

一、那年头，写代码是个体力活

在进入正题之前，先感受一下那个年代的“硬核”开发环境。

1960年代中期，程序员的主要编程工具是打孔卡。IBM 026打孔机设定了80列的标准，一行代码超过80个字符？抱歉，你得换张卡重打。写完一叠卡片，你得抱着它们去排队，等待卡片阅读器一张张吞吐，运气不好的话，编译报错在一万张卡的最后一张——恭喜你，从头再来。直到70年代末，大多数程序员仍然在用打孔卡编程，有些人甚至“一直到1982年都更喜欢打孔卡而不是终端”。

当时的编程语言主要是COBOL、FORTRAN IV，还有IBM雄心勃勃的PL/I。编译工具方面，IBM System/360上的BOS操作系统就已经包含了链接编辑器（Linkage Editor）、汇编器、FORTRAN和COBOL编译器，以及一个叫Autotest的调试辅助工具。听起来还挺全？但问题是，这些工具之间毫无集成，每一步都需要人工搬运数据、检查中间结果。

构建工具呢？1976年，贝尔实验室的Stuart Feldman创造了make，通过Makefile描述文件依赖关系，自动决定哪些文件需要重新编译。在此之前，程序员靠shell脚本来批量执行编译命令，效率之低令人窒息。至于静态代码检查，1970年代初S.C. Johnson在贝尔实验室写出了lint——史上第一个静态代码验证工具，能在编译前帮你揪出代码里的“毛球”。

但请注意：这些工具在1968年统统还不存在，或者刚萌芽。Bemer提出软件工厂构想时，他能想到的最先进的生产力工具，大约就是“一个由计算机管控的编程环境”这个概念本身。

二、1968年，两个男人，两场会议

1968年10月，NATO在德国Garmisch-Partenkirchen召开了一次软件工程会议，11个国家、100多位软件从业者聚在一起，讨论一个令人头疼的问题：软件危机。项目普遍延期、超预算、缺陷多、生产力没法预估——用当时的话说，“软件开发像手工作坊”，用现在的话说，“需求天天变，老板天天催，代码天天崩”。

正是在这场Garmisch北约会议上，M.D. McIlroy（AT&T贝尔实验室）提出软件构件复用思想：主张把软件拆解为可复用的模块化组件，建立专门机构来批量生产构件。这个思路直白地说就是：别每次都从头造轮子，造一个轮子库，谁需要谁来拿。

而同在1968年的IFIP大会上，通用电气的R.W. Bemer独立提出了最早的软件工厂构想：建一套计算机管控的编程环境，集成编译器、测试工具、文档工具，用历史项目数据库做成本进度测算。他的核心主张是工具、度量、管理控制三位一体。

问题是，1968年的现实是：没有版本控制，没有包管理器，没有构件库标准。“复用”在当时的技术条件下，差不多等于“把别人的代码复制粘贴过来，祈祷它能编译通过”。

三、日立率先建了世界上第一家“软件工厂”，然后美国人试了一把

1969年，日立设立了“Software Works”，成为世界上第一家正式以“软件工厂”命名的机构。日立面对的现实痛点非常“接地气”：程序员严重短缺，软件缺陷投诉高企，客户觉得软件应该像硬件一样“买来就能用”。日立的做法是：收集项目生产力与成本数据，制定企业内部软件标准HSS，区分基础系统软件和业务应用软件分别建立流程规范，逐步引入结构化编程和质量管控。

1975-1976年，美国SDC建了美国第一个软件工厂。SDC承接大量美国国防部实时系统项目，开发流程没规范，需求变更像翻书，复用能力基本为零。SDC的工厂架构分两层：上层“程序办公室”对接客户，下层工厂内部拆分为程序设计、程序开发、系统测试验证三个流水线小组。工具方面开发了TOPS（设计建模）、PATH（测试分析）、IMPACT（项目管控）一套工具链，还编制了《软件开发手册SDM》固化流程标准。

结果呢？前期部分项目确实做到了按时交付、缺陷下降。但后续问题全面爆发：项目管理者不愿意把开发任务移交给工厂——“我的人我自己管，凭什么给你？”；陌生领域的规格难以确定，工厂人员大量闲置；工具可移植性差，换一个项目环境就得重来。最终，SDC的实体工厂组织解散了。不过它留下的流程标准文档继续在企业内部沿用，还影响了美国军方的软件采购规范。

四、日本工厂浪潮：当东芝把软件工程师装进“车间”

SDC的失败没有浇灭日本企业的热情。1976-1978年，NEC、东芝、富士通纷纷跟进。

东芝（1977）面向核电、工业汽轮机等高可靠实时控制系统建设软件工厂，是日本工业化软件组织范式的代表作。它的核心策略包括：

·标准化瀑布开发流程——需求、设计、编码、测试，一步不能少

·强制构件复用：设立复用零件指导委员会、构件库中心，用关键词检索可复用模块，把复用指标纳入项目与个人绩效考核

·集成工作台SWB，完整度量体系，质量圈（Quality Circle）

·“前瞻管理（look-forward-management）”：基于历史数据估算工作量，按最小工作单元跟踪每日/每周进度

效果相当显著：复用率和人均产出大幅提升，软件缺陷大幅下降。用明茨伯格的组织理论来说，东芝的软件工厂属于机械官僚制——依靠标准化工作流程实现管控，就像一条精密运转的流水线。

NEC则走了一条略有差异的路：在集团层面统一工具、方法，建立软件质量控制SWQC，引入质量圈，建立专门软件工程研发实验室。1983年，NEC开发了SEA/I（Software Engineering Architecture/One），这是一个CASE环境，明确以“通过全开发过程支持来实现软件工厂概念，取代手工作坊式开发模型”为目标。

富士通最有意思：先从软件移植转换业务入手建工厂，再逐步扩展到全新开发，后期意识到不同项目需要差异化流程，没有完全死守集中流水线模式。这大概是日本四家里最早“想通了”的。

1985-1990年，日本通商产业省启动了国家级SIGMA项目，希望构建全国性基础设施，推广工作站和可复用构件。理想很丰满，落地效果有限——国家级项目协调多家企业的难度，做过跨部门项目的人应该能感同身受。

五、欧洲人的“乐高积木”方案

1987-1996年，欧洲Eureka跨国联合项目推出了ESF（Eureka Software Factory）。它的目标不是直接产出软件，而是产出用来搭建软件工厂的通用架构与组件库。

ESF的核心理念是“软件总线”：定义一套总线接口，各个CASE工具组件可以像乐高积木一样插拔组合。分为四层：通用ESF层、组件库层、工厂模型层、最终定制化软件工厂实例。ESF的设计意图，是提供可插拔的通用工具架构，让企业按需组装、适配自身环境。

但实际落地中，它仍然高度偏重技术基础设施，缺少组织变革和人员管理的配套方案，假设部署工具就能完成改进，结果组织不得不反过来迁就工具所预设的流程框架。组织视角上，ESF和东芝一样属于机械官僚制，但实现标准化的路径不同：东芝依靠工作流程制度标准化，ESF依靠自动化工具实现标准化。局限也很明显：翻译成大白话就是，花了几百万买了一套CASE工具，发现没人会用，用的人不想用，最后变成了昂贵的桌面装饰。

六、美国人绕了个弯：不建厂房，搞“经验工厂”和“成熟度评级”

欧洲人在造工具，美国人在思考组织。两条非实体工厂的路线出现了。

第一条：Basili的“经验工厂”（NASA戈达德软件工程实验室，马里兰大学）。这条路线的起点是1976年——NASA戈达德航天中心、马里兰大学和Computer Sciences Corporation三方共建了软件工程实验室（SEL），Basili本人从这一年起担任SEL主任，一直到2001年。SEL的演进分了几个阶段：1976-1980年先做度量基线，1981-1985年做受控实验，1986-1990年才正式进入“经验工厂组织”阶段。也就是说，从实验室挂牌到“经验工厂”作为一种正式组织范式成型，中间走了整整十年。1992年，Basili等人在第14届国际软件工程大会（ICSE）上发表《The Software Engineering Laboratory — An Operational Software Experience Factory》，系统总结了SEL作为“运行中的经验工厂”十五年的实践；1994年《软件工程百科全书》收录“The Experience Factory”词条，这个概念才算彻底固化下来。

它不追求实体厂房流水线，而是把组织拆分为两套机构：一套聚焦软件交付（项目组织），另一套是独立的“经验工厂”，专职收集、分析、封装项目经验、设计、测试用例和可复用构件，沉淀到经验库，反向供给新项目。采用“计划-执行-分析-归纳”持续改进循环。组织归类为专业官僚制：依靠人员技能和组织学习来协调工作，而不是死板固定流程。

第二条：SEI的CMM（能力成熟度模型）。1984年，美国国防部资助卡内基梅隆大学成立SEI。1986年11月，SEI在Mitre公司协助下开始研发流程成熟度框架。1987年9月，SEI发布了第一份能力成熟度框架和成熟度问卷，同年发布技术报告，介绍CMM及作为评价国防合同承包方过程成熟度的方法论。1991年，SEI正式推出CMM 1.0版，集中了此前四年的评估经验和用户反馈，成为一个可用的模型。1993年CMM 1.1版发布，成为此后通行多年的版本。

CMM没有使用“软件工厂”这个词，但也被视作一类工厂式思想。核心是不聚焦工具，聚焦软件流程本身，设置5个成熟度等级、18个关键过程域，循序渐进提升组织过程的可预测性、可靠性和自我迭代能力。落地依靠SEPG（软件工程过程小组）推动组织内流程改进。同样属于专业官僚制。

CMM的有趣之处在于：它给出了一套普适的流程改进框架和明确的优先级，但实现方案相当抽象，缺少基础设施和工具层面的实操指引——好比给你一份健身计划，告诉你“第1级是能走完1公里，第5级是能跑马拉松”，但没告诉你跑鞋去哪买、怎么热身。

七、四大范式对比

八、三个幻觉，和一个朴素的道理

Aaen等人在论文中重点批判了软件工厂历史上的三大幻觉：

幻觉一：仅仅靠组织架构调整，就能解决复杂软件开发的全部问题。把“软件作坊”改成“软件工厂”，挂个牌子换个组织架构图，代码就不会出bug了？事实证明，组织架构调整是必要条件，远非充分条件。

幻觉二：单纯部署工具链，就能自动实现软件工业化。买了一套昂贵的CASE工具，装好之后大家就会自动用起来，流程就会自动标准化——这个假设在1980年代被反复证伪，在2020年代依然被反复证伪。

幻觉三：只依靠组织学习、流程管理，就可以忽略开发基础设施。流程再完美，工具链跟不上，还是得靠手工搬运。

理想模式应当把基础设施、流程管理、人员与组织学习三者结合。明茨伯格理论视角下，软件组织应当以专业官僚制为主，适度吸收机械官僚制中标准化、度量、复用的手段作为补充，平衡效率与灵活性。

九、尾声：那些“失败”的工厂，留下了什么

回头看，早期大多数实体软件工厂模式并没有延续到今天。日立的Software Works拆分了，SDC的工厂解散了，ESF的CASE工具架构大部分进了博物馆。

但它们留下的遗产无处不在：跨项目度量、软件复用、过程标准化、组织级持续改进——这些思想被后续的软件工程全盘继承，深刻影响了软件过程改进（SPI）、软件产品线（SPL）、乃至今天的DevOps和平台工程。

更微妙的是，“软件工厂”这个术语本身就充满歧义：有的指实体办公场所，有的指一套组织架构，有的指一套工具架构，CMM甚至不使用“工厂”这个词但理念同源。名字叫什么不重要，关键是那个朴素的认知：软件既不能完全照搬制造业流水线，也不能完全回归无约束手工作坊。

50多年过去了，我们有了Git、CI/CD、容器、云原生，工具链比1968年先进了不止一个数量级。但“软件工厂”当年面对的核心难题——如何在标准化与灵活性之间找到平衡，如何让工具服务于人而不是反过来——依然在每一次技术选型和组织变革中重复出现。

说软件工程是伪命题，有点冤；说它是纯工程，又有点心虚。它更像一个“薛定谔的工程”：开会时像工程，写代码时像手艺，交付时像工程，改需求时像玄学。但过去五十多年，我们确实一直在用真金白银、真加班、真秃头，认真回答这个还没写完的命题。