云计算时代：是否依然没有银弹？

Posted 2021-04-29 PM私董会

《没有银弹：软件工程的本质性与附属性工作》是IBM大型机之父佛瑞德·布鲁克斯所发表一篇关于软件工程的经典论文，原先是在1986年都柏林IFIP研讨会的一篇受邀论文，隔年电机电子工程师学会《Computer》也转载了这篇文章，他们用了几张《伦敦狼人》之类的电影剧照来当作说明，还加上了一段〈终结狼人〉的附注，用来引出非银弹则不能成功的（现代）传说。该论述中强调由于软件的复杂性本质，而使真正的银弹并不存在；所谓的没有银弹是指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。

佛瑞德·布鲁克斯

 

上一次推送，我把《没有银弹：软件工程的本质性与附属性工作》的前半部分的中英文对照版推送出来。虽然几十年过去了，我们现在已经在云计算时代好几年。但文中说的软件的特性到现在看来，不仅都依然成立，而且是随着硬件能力的增加和各种内外因素的影响是更加强化了，而且是更加倍，甚至数十，上百倍的强化了。今天我再来探讨下《没有银弹》一文中软件的四种基本特性在现在的状态。

 

复杂度：30多年过去之后，我们现在已经进入了到了云计算时代，硬件，软件以及编程语言的已经有了翻天覆地的变化。硬件上来说，摩尔定律虽然在近几年因为硬件已经向物理极限的因素正在慢慢的提升变缓了。（另一方面，无论是开源社区或者是闭源的软件，在体积上都变得庞大起来。）文章中只提到了ada，当时还没有java/python/php，更没有go，java script等等。时至今日，高级语言支持了非常多的特性，可以很方面的提升了开发的效率，而开源社区又在高级语言的基础上提供了非常多的应用库。通过高级语言和对应的应用库，开发者可以非常方便的构建各种应用。这些应用又可以通过云，迅速的构建起实际的服务，通过互联网向数以亿计的人提供服务。

但与此相对应的是，现在的应用无疑要比以往任何时候都复杂。一个再简单不过的WEB应用，通常都需要经过一系列的工序，从产品概念设计开始到用户体验设计、用户界面设计、架构设计、开发、测试、部署然后交付给运维人员才完成一款真正的应用，而如果成为一个相对成熟的软件应用，刚需要经过若干个版本才能达到。而这些工作又和原作中的可变性的描述交织在一起变的更加复杂而更难达到一致性。

 

一致性：在《没有银弹》文中提到：

在多数情况下，软件通常是最后到达现场的，所以它必须和相关的接口保持一致。而在其他情况下，它必须一致，因为它被认为是最一致的。但在所有的情况下，多数复杂性来源于软件必须和其他的接口保持一致。这种复杂性无法通过单独重新设计软件而简化。

 

这一句真的是说中我的泪点。这一点尤其是在某些替换老系统的项目上线过程中显得特别重要。如果一个新上的系统后出了某些故障，那么几乎所有人的潜意识中就认为是这个新系统导致的。尤其是这些故障点在新的接口上时，你需要用足够多的证据来证明这些故障或者问题的根本原因不在于自己时。有些时候，尽管你已经说清楚了问题和你新上的系统无关，而是由于业务中关联的其他模块、子系统的问题不合理不合规的行为导致的。但是，新的系统依然需要保持与原有系统这种不合理的一致性。

 

在传统的软件开发过程中，一致性和一个叫基线的概念紧密联系在一起的。在一个软件版本的发布时，必须经过一系列的功能测试，兼容性测试等工作，保证软件能在基线的硬件上，固件版本以及对应操作系统版本上能正常的工作，而在软件/硬件发布时，也通常附带一个支持列表的文件，列出了这个新发布的软/硬件可以正常工作的环境。而在项目管理领域，有的地方也会提到基线的概念，和软件/硬件的基线略有不同。这里，不展开讨论什么是基线。因为在互联网时代，这个概念感觉已经有点淡出大家的视野了，一是变更太多太快，二是软件服务化。

 

上一段提到的开源社区中还会涉及到一种新的一致性：开源库版本的一致性。开源软件/库其实是现在的绝大多数的定制开发项目的基础，从java/python/go等各种语言为各种基础的应用，功能，通信提供了大量的工具。可是开源世界是多变的，版本更替的频率也是开源库的生命力的重要表现，而开源库之间也是有相互依赖的。这就造成了另一种可能性，我们在开发自己的软件时，依赖的第三库可能本身依赖版本/功能是相互冲突的。而即使在初始创建项目时你顺利的没有碰到这些一致性的冲突，对于经常更新开源软件库，还必须保持相应的更新，特别是对于安全问题的更新。这都是软件的一致性的带给大家新的困扰。

 

说到开源软件和一致性这个话题，另一个可能触及内心的词可能就是“魔改”了。当开源软件的bug或者一些功能无法满足项目的需求时，项目团队的一些资深的工程师的一条最快路径就是“魔改”了。在原有开源软件的基础上，或直接在原来的源代码上小改几行或者数百行代码，然后再将这些魔改后的开源库的版本置入到自己的项目中来。更有甚者，为了避免将来某些可能的冲突或者达到其他的目的，例如为了避开源代码的权限问题、方法可见性问题等，将所有的源代码的路径或者包名改成自有，然后再在此基础上改，形成开源库的私有代码。这样，这些开源库的后续版本再更新就会有着极高的成本。甚至来说，这些魔改后的源代码会因为人员的工作交接，更替而消失的无影无踪。而这些需求和功能，则如同拥有了魔法一般，或者会出其不意的消失，或者又会不经意的在某些地方又出现了。

 

可变性：在今天，在《没有银弹》一文中提到的可变性可以说是解决了一部分， 在操作系统这一层，一般都是有硬件的抽象层， 只需要硬件厂商完成相应的硬件设备的驱动就可以的，而在应用软件层面这里基本上不需要再去关心底层的硬件，特别是在我们现在个人用的Windows/Mac/Linux等桌面操作系统这里。很多古老的软件依然可以正常运行于新的硬件上。

另一方面，互联网的出现却是将可变性发挥到极致。在三十年前，开发一个软件的周期通常都是按年来算，尤其是大型的软件。而放到现在的互联网时代，软件版本的更替都是以天来算的。现在我们手机里的每天都有APP在版本更新，而对于同一APP基本上至少每个月也会更新1-2次。而在服务侧，这种更新则变的更频繁。基础设施层面从物理机到虚拟机，从虚拟机到容器，再到现在的servless，而在应用架构层面，则从单体到SOA，再到微服务 再到现在的service mesh，无一例外的都在支撑着软件的可变性。大型的互联网厂商都有自己对应的DevOps（无论他们是否符合某些标准机构的认证），管理着成千上万台的服务器、虚拟机和容器。一旦自己的服务器侧程序需要更新，DevOps系统会在数分钟内将程序部署到分布于全球的对应服务器上。

 

不可见性：软件的架构依然是不可见的，原文说的每一句话，到今天依然成立。尽管我们现在有各种绘图的工具，但依然无法表达复杂的软件逻辑。而且是因为软件变的更复杂，很多的逻辑变的更不可见且不可知。借用我们公司的培训教室里贴着程序员最讨厌的四件事，“1， 没有文档；2，没有注释；3，写文档；4，写注释。”这其实也是软件不见性的另一个侧面。正因为难以用自然语言和图表来表示软件的功能，逻辑，而让软件变的更不可见。

 

正是因为这四点，互联网、软件业的项目经理的生存变的更加困难，一个将自己置身于产品（交付物）实现逻辑之外的项目经理几乎无法生存。可能也正是因为此，互联网、软件业的更需要的有项目思维方式的码农吧。

精彩回顾

”