远离了刀耕火种，我们是否找到新的银弹？

陈徐毅

软件和软件工程是计算机科学技术恒久的主题，不论信息技术怎么发展，互联网形态如何演变，都绕不开这个关键核心的事物。在业界开发者的群体中，人们习惯用“银弹”一词来比喻解决软件领域有共识且客观存在的显著问题的方法，软件史上最著名的银弹问题则源于经典之作《人月神话》一书。

上世纪70年代IBM System/360操作系统之父佛瑞德·布鲁克斯其所著的《人月神话》一作系统性地解说了软件工程、项目管理相关课题，书中通过计算、案例来证明软件开发额外人力的投入无益于软件工程生产力的提高，作者在之后的章节中追加了《没有银弹》一文，并作出了没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍的假设。但是，这个假设在1990年代中期已被认为不再成立。

其实，银弹问题的起源还可以追溯到软件危机。软件危机主要发生在那些开发周期长、费用昂贵、质量控制难以保证、生产率低下的大型软件系统，它们的复杂性已远超出人的智力范畴，大型软件系统不能沿袭工作室的开发方式，就像制造小木船的方法不能生产航空母舰一样。这种大型项目常伴高风险，一直到1980年代面向对象技术才解决了一部分在软件危机上的窘境。

Linux不是银弹，Git也不是

第一次银弹问题的削弱出现在1990年代中后期，因为开发者普遍感觉到软件工程生产力较十年前提升了十数倍，尽管他们依旧习惯于“没有银弹”的说法。那么第一枚银弹是谁？在那个时间点上很容易联想到Linux。

但众所周知的是，Linux本身不可能是银弹，而重点是，它是世界上最庞大的开源软件的软件工程。基于这一点，Linux生态的开发者们有足够多的时间和理由去试错，《大教堂和市集》的作者埃里克·雷蒙德提出林纳斯定律：足够多的眼睛，就能让所有问题浮现。这句话非常契合那个时期，在Linux快速发展的时间里，面向对象、高级语言、统一开发环境、专家系统、人工智能，这些更接近“银色子弹”的事物随之伴生。这些技术的目的是让具体应用的复杂程度与程序本身相分离，Git也是其中之一。

版本控制是软件项目管理的重要一环，也是追求效率的主要改进方向，毕竟软件工程少不了沟通和协作。Git并非一开始就流行于世，在其之前还有BitKeeper和Monotone，甚至更早的CVS。Git作为BitKeeper的开源替代品被林纳斯·托瓦兹开发出来，此后一大批支持Git源码访问的分布式版本控制网站（源代码托管平台）拔地而起，其中最大的拥有超过4000万注册用户和1.9亿代码库。

现在的软件和软件工程领域，早已远离了刀耕火种的年代

Git也不是银弹，因为工具本身带来的提效和缩短开发进度，并没有解决软件工程的本质性难题，即如何从抽象性问题发展出具体概念上的解决方案。但这些年来涌现出来的工具和方法论，都可以看成是接近银弹的事物。

刀耕火种的远去和新的银弹

现在的软件和软件工程领域，早已远离了刀耕火种的年代，摆在我们面前的是模块化的高级编程语言、高度集成的環境，各种库、各种框架，弹性计算带来的流水线和自动化工具，我们正处在一个“敏捷”的时代。尽管在软件工程生产力得到较高程度解放的今天，开发者们已不太关心当初的那个银弹问题，但是我们却面临着新的问题，这迫使人们去寻找新的银弹。

软件工程自动化带来的结果就是高频迭代，但是创新大幅减少，99%的程序员在实现需求，只有不到1%的程序员在创造工具和方法。但我们认为这也是技术进程的一个必经阶段，需求爆炸要求自动化，自动化带来DevOps，DevOps造成分工更加精细化，乃至CI/CD管道部署，一个高度自动化流水线已然在软件工程领域形成。

程序员的精细化分工造成综合素质整体下滑，至少过去20年都是如此。当代程序员很少去研究汇编和机器语言，因为这完全没有必要，现在的开发环境是建立在“高度文明”之上的，绝大多数开发者只需关注逻辑的实现，底层世界与之无关。但是数字文明的底层世界是C语言，再下面是汇编语言和机器语言，这也是回溯技术进程的事实，现在的“高度文明”不可能是空中楼阁。

高度自动化让程序员看起来更像是流水线上的零部件，而不是一个创作者。殊不知人类智能最伟大的地方并非只有逻辑思维，更多的是创造思维。肯·汤普逊和丹尼斯·里奇为了使开发UNIX更高效设计了C语言;林纳斯为了更好地管理Linux内核开发了Git。许许多多的工具一开始也许只是因为一个小目的被创造出来，但是它们后来逐渐成了开发者世界的大器。数字文明会否出现断层是一个警惕性问题，也许过去20年我们失去的，才是今后我们想要的银弹。

之前9月的时候，曾有消息曝出林纳斯怒喷某代码托管平台“合成了一堆无用的垃圾”一事，尽管林纳斯并非因平台本身或者其他项目的粗糙而恼火，而是为即将用于Linux Kernel 5.15的一个驱动程序的合并感到不满。此事也折射出社会化编程也不是银弹。

银弹问题总是关乎程序员、组织和需求的问题，它们一直在变化。有位“谦逊的程序员”曾经说得好：软件危机的主要原因，毫不客气地说，在没有机器的时候，编程根本不是问题;当我们有了电脑，编程开始变成问题;而现在我们有巨大的电脑，编程就成了一个巨大的问题。