文章图片

软件和软件工程是计算机科学技术恒久的主题 ， 不论信息技术怎么发展 ， 互联网形态如何演变 ， 都绕不开这个关键核心的事物 。 在业界开发者的群体中 ， 人们习惯用“银弹”一词来比喻解决软件领域有共识且客观存在的显著问题的方法 ， 软件史上最著名的银弹问题则源于经典之作《人月神话》一书 。
上世纪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也不是银弹 ， 因为工具本身带来的提效和缩短开发进度 ， 并没有解决软件工程的本质性难题 ， 即如何从抽象性问题发展出具体概念上的解决方案 。 但这些年来涌现出来的工具和方法论 ， 都可以看成是接近银弹的事物 。

文章图片

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