现在是“软件定义一切”的时代，软件已经成为新型基础设施。过去我们在计算机上开发软件，在计算机上运行软件，后来发展到互联网时代，通过网络开发软件，通过网络运行和提供软件服务。而到了今天，当数字产业化、产业数字化渗透到更多领域时，“软件定义一切”。在20世纪60年代的科学研究方法领域，《科学革命的结构》一书曾提到所谓的范式或者范例变革。科学研究有一定的范式之规，往往一个范式确定下来后，大量的科学家就会在约定的范式中开展科学研究，直到这种范式不能适应科学的发展，才会迎来科学研究范式的变革。比如，业界经常谈到的第一范式、第二范式、第三范式、第四范式，还有现在谈得很多的AI范式，即用人工智能进行科学研究等，就是这种变革的体现。事实上，在软件领域同样有程序范式、数据范式等类似说法，这是从20世纪60—70年代后开始出现的说法。
今天，又到了范式变革的时代。有必要从软件开发的视角，对科学研究进程中的一些重要范式进行比较，以此探究我们应该以怎样的范式应对开源带给业界的机遇与挑战。
一、工程范式：自上而下，逐步求精
工程范式带来的变化，是将软件或者程序从个体创作上升为群体化大规模生产的软件开发模式。在此之前，软件开发如同在作坊中进行个体创作，像绘画、雕刻、木工等一样，是个体创作的产品，是人文成果。直到20世纪40—50年代，甚至20世纪60—70年代，业内开发软件时往往是先在脑海中设想软件跑通的情景，然后再调试部署到计算机上。那时的软硬件规模很小，从第一步到最后一步如何执行都可以在脑海中预演。但是随着数字计算机的出现，软件开发的效率和质量成为突出问题。例如，20世纪60年代，为了推动IBM360系列计算机在商业领域应用时可以适应各种外部硬件的需求，IBM开发出可移植、适应不同设备的操作系统。计算机操作系统的研发和应用在软件史上具有里程碑意义，给软件界留下了影响至今的操作系统关键技术；同时，也给软件开发变革带来一个重要启示，即软件开发所消耗的人力资源远远超出预期，软件质量的可靠性、可控性远远超出软件架构师和程序员的预期。人们发现，原来软件也是如此复杂和不可控的。所以在那个时代，处于工业化生产浪潮中的人们普遍认为西方成熟的工业化流程能够保证工业品的质量，于是顺势形成用保证工业品批量化大规模生产的方法来组织新软件开发的发展思路，这就是所谓的工程范式。1968年，北大西洋公约组织在一次工作会议上提出“软件工程”的概念。北约是军事组织，冷战时期为应对军事挑战、争取在军事领域的领先地位而积极寻求新型信息技术的支持，因而对软件的复杂性以及保证软件开发的效率和质量有着最迫切的需求。在此背景下，北约投资并组织了一批计算机专家，研究如何解决或提高软件开发的质量问题，于是就有了工程范式基本理念的产生和实践。我们将软件工程所遵循的软件开发理念和方法，称为软件开发的工程范式。理解这个范式理念，要从工业化大生产出发，首先是从工程技术中借鉴有效的产品开发组织模式，把人组织好，按照可控制、可预期的流程来设计和生产软件；其次是参照工业化带来自动化的经验，尽可能地研发软件开发工具，使软件开发的质量和效率得以保证。由此，软件开发有了各类V模型，从需求分析开始，然后进行系统设计、程序设计、模块测试、单元测试、集成测试、确认测试，最后再交付给用户一个满足需求的软件。与此同时，一个机构能不能有效地开发软件，对机构的软件开发能力成熟度该如何评估，软件能力成熟度模型（CMM）就出现了，这是一种用于评价软件承包能力并帮助其改善软件质量的方法。再以自动化为例。20世纪60年代，高级语言逐步成熟，业内人员可以用更接近于人类学习或者训练成本较低的高级语言写程序，然后通过编译器将其自动转变为机器可执行的代码。在那一时间段，产生了源代码和目标代码，源代码和目标代码的变换过程就是由计算机工具，即我们所熟悉的编译器完成的。这些如今司空见惯的技术工具，在20世纪60年代，是巨大的技术突破。更进一步的是，软件质量行不行的问题，直接拉升了软件测试的工作量，通过自动测试，可以评估软件是不是能够确保某一个特定的功能性和非功能性的实现，这就促进了用自动验证方法进行软件验证等一系列技术的发展。可以从以下三方面理解工程范式的理念。一是要把一个软件的需求说清楚，以确保软件开发的过程和质量。IBM360计算机就是为解决工程师头脑中的技术没有被精准描述，因而无法保证软件开发质量的问题。所以，给出明确的用户需求描述，是保证软件开发过程和质量的前提。二是软件质量，就是开发出来的软件能够满足需求规格说明的程度，满足的程度越高质量越好。三是软件开发效率，就是在需求确定的情况下，用更少的投资、更少的人力、更少的时间，更快地开发软件。那么，实现上述理念的方法是什么？就是组织工程师按照一个规范流程开发一套软件技术，并用支持工具保证软件开发所有阶段的自动化。更进一步，当时提高软件开发效率的一个重要手段，是用计算机来帮助开发软件。随着IBM360计算机的广泛使用，软件开发效率大幅提升，改进能力逐渐提高，激发了计算机应用在更多领域的推广。但当人们对开发软件的复杂程度和质量有了更高要求时，突然发现按照这种方法开发软件，与制造一辆汽车等其他有形工业产品并不一样，工程范式软件开发方法在开发效率和质量上面临一系列问题。1995年，国际权威IT研究咨询公司Standish Group对美国境内8000个软件项目进行调查分析发现，83%的项目无法在既定时间内开发完成，开发周期平均超222%，52.7% 的项目预算超出原计划的189%，31.1%的项目在执行过程中因无法控制质量和成本而被取消。随着软件复杂程度变得更高，互联网时代到来了，软件开发面临着更大的挑战。出现上述情况，业界有以下四点分析。一是工程范式遇到理论瓶颈。软件开发需要我们明确需求，但当软件需要应对越来越多的问题、互联网时代迅猛到来的时候，我们突然发现自身把一个问题说清楚的能力十分有限，过去把一个问题说清楚要以数学形式来表达，但实现这个能力在理论上存在界限；还有将需求用工具自动转化为可执行代码，同样有计算性和可判定性的瓶颈问题；此外，还存在变换的复杂性问题。大家发现，这一系列问题在理论上是不可逾越的。二是工程范式的效率问题。实践证明，软件开发效率怎么也赶不上“摩尔定律”带来的计算基础设施硬件发展的速度（处理器的性能大约每两年翻一倍，同时价格下降为之前的一半）。三是协同瓶颈。面对越来越复杂的软件，使用更多人力并不能提高效率，可能还会降低效率，甚至可能导致软件开发失败。四是网络时代到来后，业内在开发系统软件时发现，过去开发软件需要先确认需求，但在互联网时代，开发软件并不知道面对的用户是谁。只有当软件开发完成面世后被用户所接受，才可以验证出软件适合的用户群体。这些新情况，都给原有的软件开发方式带来巨大挑战。
二、开源范式：自下而上，关联涌现
互联网时代的到来，给软件开发也带来了重要变化。20世纪90年代，乃至过去的20年，促进软件迅速发展的方法不是我们所期待且瞩目的工程化方法，而是一个不被学术界甚至产业界关注的“下里巴人”状态。它带来了从群体化生产到大规模群体创作的变化，我们称之为开源范式。这种范式的起因是1974年贝尔实验室向大学免费开放Unix源代码系统。美国政府为保护在新兴计算机市场和软件市场的竞争优势，于是支持Unix操作系统免费授权给大学或研究机构做研究使用。随着Unix的自由发展、版本变多，AT&T开始重视Unix的商业利益，因此就出现版权回收问题，比如IBM等被授权的Unix商业版本代码不再能被自由传播，就出现了所谓的开源状态，出现了开放软件基金会。
20世纪90年代的软件系统格局由两部分组成，一是个人计算机占统治地位后，商业闭源软件成为主流，而另一个支流是在学术界传播和发展的Linux开源软件。开源范式支持在不确定的网络世界通过众多的开发者带来丰富变化和竞争，并自然演化出得到用户欢迎的软件制品。Linux正是通过开源范式带来的易变性和多样性，才更能应对未来操作系统发展的不确定性，当智能手机、云计算、物联网等新的需求涌现时，Linux的众多衍生系统就具有更强大的生存能力和市场竞争力。
开源时代的到来，主要是因为开源在互联网时代成为科技领域创新的主要驱动力。开源领域代码生长迅速，到1993年，Linux已经从当初只有一个代码，增长到大概10万行代码；再到现阶段，仅华为开放参与的代码规模就已经超过3300万行，涉及的工程师超过3万人，仅去年一年提交的代码就有120多万个。这种聚集起如此广泛的开发者和贡献者的开源状态，支撑起至少500个版本的开源操作系统被商业化使用。全球超级计算机TOP500强几乎均采用Linux作为其操作系统，而云计算操作系统也无一例外都使用开源系统。如今的智能手机、机器学习、大模型同样是开源系统状态。大模型领域中开源软件的应用非常活跃，由此带动了中国大模型不断涌现。开源之所以取得成功，是因为它通过多样性来应对不确定性。20世纪80年代，在个人计算机时代，计算机发展的确定性使得微软以给企业操作系统发放闭源许可证的方式，获得对操作系统和软件的绝对定义权。作为当时先进生产力的代表，微软以其确定性视野定义了当时的互联网时代，也正因如此，无论操作系统版本如何演化，都完全由这家公司来控制。考虑控制成本，市场主导者就不会开发更多的版本分支，最好一个操作系统版本就能解决所有问题。当软件、操作系统的每个分支均由微软一家开发时，那么这家公司以企业化的方式组织数千个工程师，耗时几年全力开发一个新版本即可控制市场。还好，这种情况在互联网时代发生了变化。按照GPR模型，每个人都可以基于软件内核进行修改，修改后再反馈回来，这是一种双性范式。GPR下的内核可由软件下载方按照自己的理解书写新的版本，如此就可以产生相当多的分支，在不确定性的互联网时代，开源给软件、操作系统等在各个领域的探索提供了巨大的可能。也就是说，适应互联网不确定性的软件可能版本数量变多了，可成本却降低了，这或许就是开源成功背后的逻辑。相较于工程范式，开源范式有很多理念上和方法上的革命性变化。一是从需求看，开源软件没有明确的用户。在互联网时代，互联网软件并不知道自己的用户在哪里，用户就是开发者自己，开发者基于他所理解的世界进行创作，而不以明确需求为开发前提，这不像过去工程范式要求的那样，开发软件之前一定要明确它的用户群体。二是从质量看，什么是好的软件，开源社区中反响热烈的软件就是好的软件。三是从效率看，什么是效率，开源社区中有人提出问题后，响应快就是效率高。不过，开源模式同样有其问题。开源时代的组织模式是自组织模式，工具主要是版本控制。实践中，软件开发的版本控制很复杂，而如此多的版本控制更是灾难性问题。另一个问题就是软件发布。现在开源技术发展如火如荼，当互联网在全世界广泛部署，开源就“遍地开花”了，由少数人、学术界走向全社会，成为一种通过互联网传播的开发模式。这个模式是适应变异和竞争的软件开发范式，可以称之为自下而上的开发方式，和自上而下的开发方式形成了鲜明对照。开源对中国软件发展产生了巨大的影响，也就是在开源大发展的阶段，中国软件终于获得了触达基础软件核心技术实现的机会。工程范式和开源范式都存在各自的问题。工程范式强调确定性，需要有确定的需求和确定的用户，按照给定的时间和预算，最终提交给软件使用者。工程范式强调的是要聚焦交付给用户的软件产品，而开源范式是一个自组织甚至是无组织的群体，最终实现的是程序员或者程序设计者的个人作品，软件发布不对最终结果做确定性承诺。工程范式更加强调围绕质量和需求这样一个汇聚开发者智力的生产控制过程，而开源范式则是一个鼓励自由创作的过程。当然，确定性和不确定性没有好坏之分，当我们能够看到确定性的时候应该用工程化的方法来达成，当我们的目标不那么明晰时可以鼓励更多的可能性探索。那么，实践中如何平衡软件需求的确定性和不确定性之间的矛盾，进而更有效地、可预期地组织软件开发群体的智力？这就需要探索一个更加平衡的方式——群智范式。
获取报价
销售热线
返回顶部
在线咨询
一键拨打