科学哲学视域下软件开发方案评价标准的研究

周宇先

（渤海大学 马克思主义学院，辽宁 锦州 121000）

1 哲学思维在软件开发中的作用

史蒂芬·霍金在其著作《大设计》中说“哲学死了”，[1]他之所以这样说是因为他认为“哲学跟不上科学”，[1]许多本来需要哲学来解决的问题现在转交给了科学。然而事实真的是这样吗？或许有失偏颇。至少在计算机科学技术领域的软件开发中，是一刻也离不开哲学的。从思维方面来看，哲学的三大特性——抽象性、批判性和反思性在软件开发中是“须臾不可离也”。[2]从哲学的方法来看，无论是探索真理的“向上的路”与“向下的路”，无论是研究方法的“时间在先”与“逻辑在先”“循序思索”与“从后思索”，还是叙事方法的“逻辑与历史的统一”与“从抽象到具体”，都贯穿于软件开发过程的始终。如果说哲学在某个角落没有发挥作用就说它死了，那么我们每个现存的人，在活动范围之外的领域都是以死了形式存在着；如果说哲学作为思维活动的层次没能居于一定的高度，那么只能说作为思维活动主体的人没有达到那样的高度；如果说哲学作为一种能力不再是自我超越的了，那么丧失超越能力的也必然是人本身。所以问题不能得到解决不能归咎于哲学，而应该将视线回归到人自身，聚焦于人对自身的能力如何正确的认识，聚焦于人对处理问题的方法如何正确的运用。

2 关于库恩和拉卡托斯思想的简述

科学发展模式是指科学是以怎样的形式发展演变的，它是科学哲学中的一个重要问题，许多著名的科学哲学家都对这个问题进行了全面而深刻的讨论，最具代表性的是科学哲学四巨头——卡尔·波普尔、托马斯·库恩、费耶阿本德、拉卡托斯。由于本文要借鉴托马斯·库恩、拉卡托斯的思想来分析软件开发中的问题，所以需要在此对二人的思想做出必要的简介。

托马斯·库恩提出了科学革命的范式转换模式，该模式体现在《科学革命的结构》一书中。库恩认为在前科学时期学派林立、百家争鸣，其中一个学派取得巨大成功使纷争消失了，从而形成了第一个范式并带来了众多实践者的追随。这些实践者形成了一个共同体，他们遵照共同的范式行动。范式的形成标志着进入了常规科学时期，在常规科学时期，共同体成员使用范式进行解谜，解谜过程中遇到反常导致新的发现，新的发现会引起范式的变化。从旧范式到新范式的转换是革命性的转变，这种转变是世界观的转变，由于新范式的出现克服了危机，从而使新范式的共同体逐渐壮大，于是一些人转向新范式从事常规科学研究，新的循环再次从常规科学开始。[3]

拉卡托斯提出了科学研究纲领进化模式，该模式体现在《科学研究纲领方法论》一书中。他的科学研究纲领是一组由理论硬核、假说保护带、正反面启发法三部分构成的严密理论体系。最重要概念和定律构成理论体系的硬核，辅助假说围绕在硬核周围形成保护带，启发法包括反面启发法和正面启发法两种。“一些规则告诉我们要避免哪些研究道路（反面启发法），另一些告诉我们要寻求哪些道路（正面启发法）”。[4]科学研究纲领有进化和退化之分，“只要它继续不断地相当成功地预测新颖的事实（进步的问题转换），就可以说它是进步的；如果它的理论增长落后于经验增长，即它只能对偶然的发现或竞争的纲领所预见和发现的事实进行事后的说明（退化的问题转换），这个纲领就是停滞的”。[4]

接下来让我们提出软件开发中的一个基础性问题，然后把科学发展的过程与软件开发的过程相对照，透过科学发展模式来看软件开发活动的本质，将科学哲学的思想精髓映射到软件开发活动中，照亮问题的内部细节并分析问题形成的根本原因，从而可得出妥善解决问题的方法。

3 关于软件开发方案评价标准的问题

什么样的软件开发方法是好的方法？什么样的软件架构是好的架构？什么样的软件开发语言和工具是最好的语言和工具？当被问到类似这样的问题时，未免让一些软件从业者略显尴尬，这些问题就像问一位哲学家“什么是哲学？”一样难以回答。

针对此类问题的回答即使是工作经验丰富的软件工程师也往往各持己见，有些人此时坚持这种观点彼时却又转向了观点的反面，或是转向另一种观点。最初他们认为理论上介绍的方法和架构等都是好的，但是在实践过程中他们发现某些理论在应用时会遇到各种麻烦，许多过程性的细节被过滤掉了，有些理论仅仅是阐述了要达到的原则和目标，但如何遵照所指出的原则行事以及如何达到这些目标，不同的人在不同环境下会做出不同的选择。而“选择”这种决定性判断是由人通过主观意识来决定的，这样在选择方案的界定标准上就会存在不同的见解。看似风格迥异的不同选择通过不同途径都能达到预期的目标，或者是基于相同的理论基础实践后的结果却各有成败，这些都为好的标准的界定增添了神秘色彩。

正是因为理论与实际应用不完全相符产生的迷惑，使实际应用的方案制定和选择呈现出多样性。有观点认为，只要方案能够获得实际效果、能够达到期望目标，就可称之为好的方案——但是如果把作为目标要素的软件生命周期长度的期望值加重，软件的可扩展性、稳定性就显得更重要，此时这种观点就会显得不妥。另有观点认为，只要方案完全符合理论的原则标准，就可称之为好的方案——但是如果把实现目标所需的成本以及方案的可行性产生影响的权值加重，理论标准就会变成僵硬的教条而束缚了方案变通的灵活性。如果为了强行符合所谓的标准而不惜一切代价，最终带来的将是团队被所要实现目标的异化，以致违背了以人为本的原则，甚至造成成本严重超支导致财政出现问题。

可见软件开发中“什么样的……是好的？”既是复杂的问题也是不可回避的问题。各种时空环境的差异及不同因素的制约导致好方案的相对性，只有识别出特定时空环境下起决定性作用的因素，才能明确相对的好方案准则。至此以上问题已经转化为：特定时空环境下起决定性作用的因素是什么？在特定的时空环境和因素的制约下，如何确定好方案的评价标准？而这样的问题只有诉诸于科技哲学才能得到解答。

4 新视角下对软件方案标准的探求

在软件开发的各种经典的教科书中，针对软件开发各个阶段和过程都给出了理论性的指标、实现方法以及典型的范例，但是在实际应用中存在误用的情况。随着用户需求日新月异的不断提出，随着开发者经验阅历的不断丰富和认识的不断深入，随着面临要解决的问题日益复杂化或不确定性日益增加，许多人便陷入了——“对好的开发模式和理论体系的向往”与“不知道好的标准是什么”之间的矛盾中。这些人又往往存在几种倾向——最新流行的开发模式就是好的；大型公司的所应用的开发模式就是好的；拥有完整的流程体系的开发模式就是好的。这就造成处理问题的方法也各具特色，因此对于好的标准很难形成统一的共识。

4.1 库恩思想对软件开发过程的启示

面对一个软件项目或产品的开发不同的开发团队通常会给出不同的方案，这是因为他们作为不同的共同体都有各自遵循的一套范式。即使是没有实战经验的新团队也会按照教科书中的指导，或者参考其他人的开发经验制定出一套临时的范式作为标准，因为他们都深知“不以规矩，不能成方圆”[5]的道理。

4.1.1 每个开发单位的团队都是一个共同体

对于那些有诸多项目经验的研发团队而言，特别是做过的大型项目的团队，他们的范式标准随着所接触的项目规模从小到大、需求从简单到复杂，逐渐由简单的设计走向复杂的设计，以此适应新的情境和新的变化。直到这种范式标准发展到他们认为的——所研究的领域内任何用户的需求都可以在现有项目经验上做局部调整就可以构建出目标产物，这种范式标准便被他们作为最优的标准。

值得注意的是，他们认为这样的一个范式标准在应对一个新的需求时所做出的反应是快速的，主要原因有：理论体系足够完整，可以覆盖大多数用户没有提出的预想，以做到未雨绸缪；经验积累足够丰富，可以提供对比借鉴以做参照；有了共同遵循的范式标准，会消除共识上的一些分歧。新问题在他们面前就如同常规科学的解谜活动一样，进入了一种常规模式的研究状态。那么按照这样的标准来处理新问题真的能够快速吗？事实未必如此。这样一个标准只有在应对相同规模量级、相同复杂度体系的需求时，才会显现出构建效率上的优势。如果构建的目标规模量级比现有的规模量级小，那就要在现有的完整体系上裁剪掉一部分，这无疑是在削足适履。原有体系由于过于复杂，与裁掉的部分的相关联的属性、方法及其它部分的逻辑设计势必都会受到影响，所以需要做更详细的检查和验证才能保证万无一失。如果构建的目标规模量级与现有规模量级仅仅存在部分交集，则不仅要裁剪掉一部分，还要考虑到继续完善现有体系，以囊括那些交集之外的部分。那么一旦这样做了，复杂度又会有所提升，规模量级又会朝着新的级别发展。

4.1.2 每种编程语言的追随者都是一个共同体

对于使用不同编程语言开发者，他们都坚信自己所掌握的编程语言是最好的语言，他们在行业中会遵从一套基础范式标准。基础范式标准通常是软件开发工具的供应商提供的基础措施，后来经过庞大的开发者群体在实践中不断研究探索，从而研发出各种版本的分支范式标准。他们通过在相关论坛中交流经验使各种分支范式标准在行业中形成共识与普及。

不同编程语言的共同体之所以强调自己所使用的编程语言和开发工具最好，一般被认为它所能做的工作其它编程语言和开发工具做不到或做的不够好。事实上两者的比较本身缺乏一定的合理性。“尺有所短，寸有所长”，[6]这些开发语言和开发工具所诞生的环境和目标是不完全一致的。例如：JAVA和ASP.NET都可以做Web项目的开发，如果说JAVA的优势在于其插件和框架资源丰富、在不同的操作系统上具有可移植性占有优势，那么ASP.NET则使开发工作快捷高效、在服务器管理简单方便上占据一定优势。虽然随着智能移动设备时代的发展JAVA语言在移动设备应用的开发中发挥出重大作用，但ASP.NET的插件资源和跨平台的解决方案在经历演变之后也变得并不逊色。

如果从用户对项目需求的角度来考虑，则无论何种编程语言和开发工具都表现出单凭自身无法满足用户需求的特点，必须结合各种技术框架和设计思想综合运用，才能达到满足用户需求的目标。

4.1.3 每一种具体流程标准的追随者都是一个共同体

对软件工程做深入研究会发现其中包含着丰富的思想和流程标准。从软件过程模型来看，各种文献中提供了“规定性的”和“描述性的”模型若干种，其中典型的模型有瀑布模型、原型化模型、敏捷开发等；[7]从开发方法来看，典型的方法有面向对象的开发方法、可视化开发方法等；[8]从项目管理方面来看，则有PMBOK（项目管理知识体系）这样整套的管理技术与方法；在开发过程的指导和开发能力的评估方面，则有CMMI这样的软件能力成熟度模型。面对汇聚而成的如此浩瀚的标准海洋，每种支流都有其庞大的追随者。项目开发中原型化法与敏捷开发的运用难分伯仲，面向问题的分析方法PAM、面向对象的开发方法、可视化开发方法更是呈三足鼎立之势，管理方式上和开发过程的流程也都在向PMBOK和CMMI靠拢，这似乎形成了一股潮流，形成了对范式的一种尊崇。

尊崇敏捷开发的共同体在软件项目开发过程中迅速响应用户方面的优势明显，但如果是做软件产品开发，其所有神圣的宣言将会失去神圣色彩，这是由软件项目与软件产品的区别决定的。CMMI虽然是为了提高软件企业的开发效率和软件产品的质量而设计的措施，但是如果企业所采用能力成熟度级别措施没有与所开发的项目或产品的规模和复杂度相匹配，要么是累赘的流程会拖延开发进程，要么是不够成熟的体系掌控不了全局。

由此可见，同一个软件项目或产品的开发活动中不同共同体按照各自的范式标准虽然都有可能达成目标——这也是为什么共同体成员对其所遵循的范式所深信不疑的原因——但是其各自遵循的范式标准是否是最好的？显而易见并不一定是。不同共同体的成员拥有不同的世界观，这种世界观在最初形成范式的过程中或接受学习某一范式的过程中就已经发挥着作用。由于此后共同体成员的大部分精力集中在如何利用现有的范式标准从事解谜活动，他们的关注点聚焦在了如何达成既定目标，因此束缚了他们最初的那种开创新事物或接受新事物的能力。而且一旦解谜成功，他们就信心倍增，更加坚信其范式的优越性。他们通常没有或者很少去考察“开发同一个项目或产品究竟使用何种范式标准更优”，一是因为时间和精力有限，况且这个对比验证的过程工作量巨大，存在很多难度与挑战；二是因为人们遵循某种范式后形成了某种思维惯性，习惯于用自己所熟悉的方式来处理问题，这样就会逐渐失去客观的评判能力。如果一旦解谜活动失败，开始有人持怀疑态度，伴随着这种问题长期得不到妥善解决，特别是此后的解谜活动失败和反常现象屡次频发，就会撼动范式在共同体成员心目中的地位。此时共同体中的一些成员就会把视线转移到其它范式，以期望能够找到解决问题的办法。特别值得注意的是，此时共同体中如果有新成员的加入，尤其是对其它范式有开发实践研究经验的人，便会对共同体成员思想的转变起到催化剂的作用。伴随着引入新范式解谜成功导致使危机产生，并逐步走向范式转换的革命之路。范式的革命性转变也意味着一个软件的生命周期结束。

软件开发共同体范式的转变是共同体成员世界观的转变，起初是从一种信仰转为另一种信仰，但是当经历过几次软件生命周期和范式的变革之后，他们也会意识到范式标准的相对性，没有绝对好的范式标准而只有相对好的范式标准，好的范式标准唯一不变的特性只有变化本身。而在软件开发过程中做出何种选择，完全出于共同体主体的实践理性。

4.2 拉卡托斯思想对软件开发过程的启示

4.2.1 软件开发中的硬核研究

无论是科学理论还是技术理论，一个最基本的标准是要有硬核，硬核作为其理论体系的核心部分，体现了其理论体系的本质特征，不同科学技术理论的硬核不同，它们是在不断地实践中沉淀的思想结晶。

软件开发过程中，无论是选择现存的思想、架构、语言、工具，还是在开发活动中形成的经验积累，都应该具有作为硬核部分的核心理论体系。如果没有硬核，说明软件知识形态还处于初期的形成阶段，对于这种未成熟的软件知识形态还要观察其发展态势，因此还谈不上对其优劣做出评判。那么硬核的具体体现是什么样的？拿编程语言和开发工具举例，各种编程语言的语法规则、语言特性和其所遵照的编程思想原则就是其硬核，而对于开发工具来说，.Net Framework是Visual Studio开发.NET程序的硬核，JDK是开发Java程序的硬核。拿软件工程过程举例，软件过程模型方法策略是建模阶段的硬核，软件项目管理计划和管理方法是项目管理过程的硬核，软件需求分析的方法策略是获取需求阶段的硬核，软件体系结构设计方法策略是概要设计阶段的硬核，软件的模块设计方法和原则规范是详细设计阶段的硬核，软件测试计划和原则方法则是软件测试阶段的硬核。

对于一个软件开发团队而言，至少要形成两种硬核：一种是所研发出的软件产品具备的功能硬核，它决定了软件产品在市场中的核心竞争力，是其价值彰显的根本所在；另一种是软件开发团队自身的开发经验积累。只有至少具备了两种硬核，才算具备了参与好坏优劣的评判基础。

4.2.2 软件开发中的保护带研究

硬核理论并不是孤立存在的，在它周围有保护带保护硬核免受伤害，保护带在科学理论中体现为一系列科学假说、初始条件和背景知识，在技术理论中则体现为应用条件、环境限制以及辅助说明。

在软件开发过程中，如果遇到重大需求变更对项目管理过程造成威胁时，则通过建立项目需求变更流程机制来处理，避免项目管理流程体系的科学性遭到冲击；如果需要变更的内容对原有软件设计体系造成威胁，则采取构建子系统、服务程序、扩充接口和模块的方式与现有主体系统进行交互，避免主体设计体系遭到破坏；如果针对某一具体的程序功能提出扩展需求时，则采取扩充功能类及功能类中的方法，并在方法调用处使用“反射+配置文件”或“适配器模式”避免原有程序逻辑的整洁性和清晰性遭到破坏。这些都可以看作是保护硬核体系的保护带，而且保护带一旦起到进步性的作用，也会逐渐演化为硬核的一部分。对于一些程序配置的设计、软件设计模式的使用、程序逻辑分层的设计、分布式的程序设计、项目集群的设计，这些以提高灵活性、避免修改原有程序、提高程序可复用性和扩展性、以高内聚低耦合为目标原则的设计，实际上也都是为了保护各种理论硬核而采取的保护带措施。甚至在软件提交时，如果仍然存在已知但是尚未解决的问题，通常会在软件操作手册中做出特殊说明，以免软件的可用性遭到质疑，例如我们在使用某些Web站点的功能时，经常被要求使用特定的浏览器，或者要开启兼容模式才能访问。

4.2.3 软件开发中的启发法研究

理论体系在正面启发法的作用下完善保护带以提供新的预测功能，在反面启发法的作用下保护硬核不受反驳而提供问题的转化和解决功能，从而使自身不断在进化与退化中发展演化。

在软件开发过程中，正面启发法的例子体现在发布新版本带来的兼容性升级或扩展性升级。例如：VS2019既能提供VS2017的兼容又有了新的功能改进；VS2017与以往的VS版本相比，增加了.Net Core为跨平台的操作提供了解决方案，提供了开发IOS和Android项目的开发方案等。反面启发法的例子则体现在发布升级补丁包带来的功能优化或漏洞修复。例如：开发工具和软件根据搜集的用户反馈信息发布功能优化补丁；为应对黑客的漏洞攻击所作的有针对性漏洞安全修复补丁。正面启发法是主动的、有预见性的解决新问题，反面启发法是被动的、防御性的解决带有威胁性的问题。在正面启发法的作用下解决了更多的问题，有了更多的预见性，则该软件理论体系就是进步性的纲领，而一旦发生越来越多的解决不了的问题或一味采取防御性的修补措施，伴随着预见性的渐渐失去该软件理论体系就逐渐沦为退步的纲领。例如：VS2017相比之前版本解决了跨平台的问题以及IOS和Android项目的开发问题是进步的体现；而多年前的VB6、Delphi7不能针对Web应用开发提供解决方案，以及无法满足用户的多元化需求最终逐渐走向没落则是退步的体现。

由此可见，硬核、保护带和启发法所构成的研究纲领理论体系可作为成熟理论体系的一个评价参考尺度。软件开发过程中在选择第三方的理论或工具时，有必要考察被选择对象是否是具备这三者的成熟理论体系，尤其要关注其硬核是否可以解决软件开发中的难点和重点以生产出具有核心竞争力的软件。软件开发团队自身则要在不断的项目实践活动中历练，逐渐形成具备这三者的理论体系作为经验积累以铸造具备核心竞争力的团队。这样便具备了作为衡量发展进步尺度的双重科学标准。

但是更进一步分析，如果多个软件开发企业团队、多个不同的软件项目或产品都已形成或具备了这样的理论体系，将他们放在一起比较则依旧很难分出好坏优劣，这是因为研究纲领理论体系是衡量科学性的标准，而好坏优劣是从技术的功利性角度来衡量的，即满足目标的有用性和有效性。因此在遵照科学研究纲领方法论的基础前提下开展的软件开发活动，结合团队自身特点和能力范围运用方法并且如期达成了功利性目标，将之综合考量才可以确定是否是一种好的方案。这样的好方案同样具有相对性，相对性的跨度既取决于科学研究纲领进步的持续过程的跨度，又取决于开发团队的主体性因素。

5 软件开发的相对评价标准及其影响因素

在做出问题分析的结论之前，我们再来看最后一个例子。

众所周知淘宝网已成为我们今天生活中所离不开的购物平台之一，凭借其先进的技术理念和平台的稳定性带给用户的体验足以被视为互联网开发的成功典范，像这种级别的互联网平台设计及其技术理论体系都顶着成功企业的耀眼光环。然而，如果考察过淘宝网的发展历史便会发现，这样一个高大的形象也并不是一次性树立起来的，而是经历了漫长的历史演变过程。它最初是由工程师基于3000美元购买的PHP程序代码上进行技术改进后形成的基础技术架构，[9]从规模上看那时的它和今天的小型网站并无区别，甚至从技术体系成熟度来看比今天的小型网站还要逊色，因为经过时代的变迁，如今的小型网站架构体系中已经融合了各种新技术和新思想。正是这样一个小型网站的架构在经过体系的不断革新之后，才形成了今天如此有影响力的大平台。

至此结论已经不言自明了，好的软件项目和产品都是在不断的开发实践过程中演变而来的，既没有一步到位方法更没有一劳永逸方案。衡量软件方案的标准也只能是相对性的标准和阶段性的标准。开发过程中形成一定的范式，并遵从范式在解谜活动中取得成功，是相对的好；突破原有范式使之发生革命性的转变，从而解决老范式不能解决的问题，是相对的好；形成理论硬核并在各种辅助性措施下不断砥砺前行，不断的预见和解决新的问题，不断完善自身体系的不足，不断的朝着进步的方向演变，也是相对的好。

相对的评判标准取决四个方面：目标问题是否得到妥善解决；物质资源的利用率是否达到最优；人力资源的能力是否发挥最优；使用的方法策略是否最合理。如果把这样的情况用函数的方式描述，那么特定阶段的时空就是软件开发活动的作用域。可以把目标问题域看作是值域，时空中的物质资源一旦确定下来就可看作是阶段性的常量，使用的方法策略可看作是函数表达式，而作为主体的人处理问题的能力可看作是自变量，人处理问题的能力范围则构成了定义域。人的主体选择性和创造性等相关能力决定了方法策略的函数表达式的形式，人处理问题的能力范围（即自变量的取值范围）决定了目标问题域（即值域）的取值范围。

由此得出“影响评判标准的因素”可归为时空环境因素、人的世界观、人的能力因素。其中能力因素中的主体选择能力和创造能力受世界观的影响，两者又决定了做出的何种方法策略；人处理问题的能力以及在能力范围内的波动与方法策略的共同作用决定了目标问题的效果。时空因素在一般情况下是处于稳定状态的因素，但是人的创造力会使其发生革命性突变，一旦突变发生人的世界观就要重新形成，从而引起评判标准和其相关因素的新变化。所以，起决定性作用的因素并不是什么单一的因素，而是时空和人的综合性因素。认清共同体成员自身的能力范围，认清所处的时空环境，认清人的能力之间的协调性与作用边界，方能做出通往需求目标的最适合的方法策略，这样所达成目标的方案才能是相对标准范围内的好方案。这样的方案将使未来面临的风险降到最低，面临的不确定性得以妥善应对，真正做到以审时度势的方式科学应对问题。

6 结束语

在软件开发这个神奇的领域，哲学不但没有死，相反有着旺盛的生命力和巨大的活力。每一次的思辨，带来的都会是质的飞跃，可能是编程语言的诞生、开发工具的改进、架构体系的革新、设计模式的调整、软件代码的重构、新算法的融合，抑或是管理流程的优化。软件开发中固然也存在种种问题，而且许多问题目前尚未很好地得到解决，但恰恰是问题给了哲学存在的价值和空间。即使暂时在丛林中走错了路，只要哲学的思辨还在进行，只要方法还在不断地革新，那么迷失是暂时的，重见光明是必然的，问题迟早会得到解决。

科学在发展的道路上固然要与哲学各有分工、相互配合，这种分工与配合的活动需要人来完成，而人是具有流动性的思维载体，不可能永恒全部固守在某一个特定的领域，因此造成各个领域的发展会呈现出不均衡的态势。由于在不同的领域中，呈现出的问题日益复杂化，处于不同发展阶段的问题又各有其特点，人们在处理问题时又因主次之别而各有侧重，解决问题的方法日益多元化，组织结构的特点日益多样化，因此解决问题的效果也会良莠不齐。对于这两种状况，我们只要翻越思维的屏障，重新审视就会发现：发展的不均衡态势是作为科学与哲学两种思维载体的人没有均匀融合造成的；解决问题的良莠不齐是方法运用的不合理造成的。此时创新便显得极为重要，创新的思维模式与创新的方法可以打破固有的思想藩篱，解放僵化的思维模式，使哲学思维和科学思维重新调和溶解，使运用的方法重新得到优化和配置，在创新的指引下一切被动的受困都会变成主动的牵引。