情境上下文对微服务开发的影响

探索情境上下文的影响——一个针对微服务架构的软件开发过程的案例研究

摘要

近年来，人们提出了各种软件开发过程，每种过程都有其自身的优缺点。然而，普遍认为并不存在一种适用于所有场景的完美过程，因此软件过程应根据其情境上下文的需求进行调整。在之前的研究中，我们整合了大量相关研究成果，形成了一个影响软件开发过程的情境因素参考框架。从业者可以参考该框架来描述自身所处的上下文，这是实现有效软件过程决策的必要步骤。本文报告了一项案例研究的结果，该研究涉及一家规模较小但成功且不断发展的软件开发公司中的过程发现。在这家专注于持续软件演进与交付的组织中，我们也应用了情境因素参考框架，发现上下文是软件过程决策中一个复杂且关键的影响因素。此类研究突显了情境上下文在软件过程定义与演进中的作用，不仅提高了人们对情境上下文重要性的认识，也揭示了软件过程上下文所涉及的复杂性，而这种复杂性在所有软件开发环境中可能尚未得到充分重视。

CCS概念

• 软件及其工程 ➝ 软件创建与管理 ➝ 软件开发过程管理 ➝ 软件开发方法。

关键词

软件开发过程；软件开发上下文；敏捷；精益；过程选择

1. 引言

鉴于多年来提出的各种软件开发模型、方法与标准不断涌现，这并非令人惊讶的是，人们还对各种软件开发方法的有效性展开了大量争论。普遍认为没有一种单一的软件开发流程并不完全适用于所有软件开发环境[1]，且没有任何环境是一成不变的[2]。因此，必须进行一定程度的过程适应与情境定制[3]，才能使流程适用于特定的情境上下文。正如文献中所指出的，软件过程是一个持续性的而非静态的问题[4]，因此我们应致力于识别能够增进对软件过程与其情境上下文之间相互作用理解的技术[5]。因此，最优的软件开发过程可被视为依赖于各个软件开发环境的具体情境特征。这些特征包括正在开发的应用的性质、团队规模、需求波动性以及人员经验。

在当前软件开发商业环境的某些领域，持续变化的情境上下文正推动着客户对软件产品快速演进的需求。如今，相较于软件生产行业历史上的任何时期，软件开发组织都面临着巨大压力，需要通过在越来越短的时间周期内发布有价值的软件，来实现软件密集型系统的演进。过去，软件发布可能每年仅进行一到两次，而在当前竞争市场的机遇下，这一周期已缩短至每周、每天甚至每小时。因此，组织必须以更快的并行周期（以天甚至小时计）进行创新和软件发布，这也促使业界采用了一些新实践。本文报告了一项针对此类组织的案例研究结果，该组织实施并逐步完善了一种持续软件演进与交付模型，以应对情境上下文的需求。本研究表明，尽管情境上下文是一个复杂的概念，但它对软件过程选择与设计具有关键指导作用。

本文的结构如下：第2节概述了情境因素框架；第3节介绍了所研究公司的概况，包括其软件开发过程；第4节探讨了情境上下文的作用；最后，第5节进行了讨论和总结。

2. 情境因素

在软件过程决策中，上下文的重要性已被认可一段时间[6]。尽管文献指出，“组织的流程是在应被理解的业务上下文中运行的”[7]，并且“生命周期模型⋯⋯[应]适合项目的范围、规模、复杂性、变化的需求和机会”[8]，关于软件过程上下文空间的文献尚且不足。软件开发必然发生在开发上下文中，该上下文包含大量关注点和因素[9, 10]，正是这种情境化有助于更好地理解什么方法在何时、何地、对谁以及为何有效[11]。为了支持理解情境因素影响的重要性，诸如迪巴[12]等学者指出，任何研究都可能依赖大量上下文变量，这正是软件工程如此困难的重要原因。

尽管文献中经常提到情境上下文的重要性，但由于明显缺乏一个全面的软件开发情境因素框架，促使其中两位作者提出并发表了一个初步的参考框架[5]，该框架本身融合了来自风险、估算等多个领域的早期研究成果。

表1. 情境因素分类

分类	描述
人员	参与软件开发工作的管理人员和开发人员的构成与特征。
需求	需求的特征。
应用	所涉及应用的特征。
技术	用于软件开发工作的技术。
组织	组织概况。
操作	运行考虑因素和约束条件。
管理	开发管理团队的构成和特征。
商业	战略和战术性的商业考量。

该框架包含44个独立因素（参见图1），这些因素通过8个分类进行归类（参见表1），并基于170个基础子因素。一个示例人员分类中的子因素列于表2中。

表2. 人员因素与子因素

因素	子因素
人员流动率	人员流动率
团队规模	（相对）团队规模
文化	团队文化/对变革的抵制
经验	团队总体经验 / 多样性 / 理解新信息系统对人的影响的能力 / 团队与管理层合作的能力 / 应用经验 / 分析师经验 / 程序员经验 / 测试员经验 / 经验 with 开发方法论 / 平台经验。
凝聚力	总体凝聚力 / 尚未 worked for you / 过去未曾共事的团队 / 团队成功完成任务的能力 / 团队处理未定义元素和不确定目标的能力 / 过度依赖团队成员 / 分布式团队 / 地理上分散的团队
技能	操作知识 / 团队专长（任务） / 团队处理未定义元素和不确定目标的能力 / 培训发展。
生产力	团队快速执行任务的能力 / 总体生产力。
承诺	团队成员对项目的投入。
不和谐	人际冲突。
可变性	范围蔓延 / 持续变化系统 / 需求不明确 / 项目目标 gold 镀金 / 模糊的系统需求

情境因素参考框架在作者看来，是迈向更深入理解软件开发环境复杂性的重要一步，其创建过程中采用的严谨方法源自大量不同来源，从而形成了一个被作者认为能够为软件开发社区提供广泛参考依据的框架[13]。在一项案例研究中，该框架被用于实际考察影响软件过程的情境因素，相关细节将在接下来的章节中介绍。

3. 案例研究公司

案例研究公司NearForm有限公司是一家在美欧均设有分支机构的软件开发公司，通过持续向全球一些最大型企业（包括蓝筹金融机构）交付高质量软件而实现了显著增长。价值是NearForm生命周期中的核心关注点，强调对客户需求（无论是新功能还是缺陷修复）的高度响应能力。该组织采用定期的5天迭代进行软件开发，并通过标准功能包每周（有时每日）部署可运行软件。尽管定期迭代从一开始就具有可预测性，但通过对价值流的持续分析，确保了每次迭代均可实时重新规划，从而从组织能力中实现尽可能高的价值交付（参见图2）。

尽管人们承认工具会影响软件过程的设计[14]，但技术对塑造软件过程的影响在此案例中是深远的，甚至可能与敏捷宣言中“个体和互动高于流程和工具”的价值观相悖。在 NearForm，通过积极采用当代且 predominantly 为开源的软件工具，实现了软件的持续演进和交付。虽然快速交付创新功能是获得竞争优势的关键推动力，但只有在伴随可靠且高质量的部署时才有效。

3.1 JavaScript 和 Node.js

曾经被许多开发者视为“玩具”语言的 [15], Java‐script，如今已成为全栈企业级开发的理想语言 [16]。Node.js 与其配套的包管理系统 npm 相结合，提供了一个精益高效的平台，使开发者能够高效地进行开发。当这一平台再结合一个有效的前端框架（例如 angular 或 react）时，便形成了一个功能强大且开发迅速的平台，使得同一语言可用于所有层级。

Node.js 的快速采用在图3中得到了印证，该图显示了各个流行的开源平台可用的开源模块数量（Node.js 位于最上方）。截至 2016年1月，Node.js 可用的模块已超过 225,000 个，模块下载量超过 25 亿次。每月[17]，这显然是一个强有力的指标，表明该技术栈背后具有显著的发展势头。

3.2 微服务架构

微服务架构这一术语指的是将系统分解为多个小型协作组件的开发风格 [18]。通常，这些组件通过直接的点对点接口（例如 http）进行交互。与其他架构风格一样，微服务也有其优缺点。主要优点包括：高度模块化和松耦合的系统，相较于传统的类层次结构更易于维护；能够快速将服务部署到生产系统——由于服务是独立的实体，只需对相关服务进行严格测试，系统其余部分无需更改；最后，微服务是高度内聚的代码单元，能够更清晰地单独推理和管理，这往往减轻了开发者的负担，如果实现得当，还能得到缺陷更少、更简洁的代码。

作为这些优势的推论，微服务系统需要更复杂的DevOps基础设施[19]，通常需要构建服务部署流水线。云和容器技术的使用使得此类流水线的构建成为可能，正是这一技术推动因素促进了这些超敏捷、精益流程的采用。它是拼图的最后一块，使技术栈变得如此强大。

3.3 软件容器技术

软件容器提供了一种在隔离的进程空间内封装功能的方法，即单个操作系统级进程仅处理特定的小块可执行代码。软件容器的概念起源于20世纪70年代末，当时向BSD Unix操作系统添加了chroot系统调用。该功能在很长一段时间内未被广泛使用，直到2000年FreeBSD jails的引入。随后是2004年的Solaris zones。2008年，Linux内核中出现了更主流的用户态实现，即LXC-容器。然而，这项技术直到2013年通过Docker项目才开始获得广泛采用，使得开发人员能够以比传统软件开发和部署模型更低的风险，定期向运行中的系统注入新的、易于消化的功能。

容器技术可能成为某些类型软件开发的主流，特别是随着诸如 Kubernetes、Docker Swarm和AWS container services等容器管理和编排系统的发展。

4. 应用情境因素参考框架

两位研究人员与NearForm的工程总监合作，对公司的情境因素进行了详细分析，主要结果如表3所示。

表3. 案例研究中识别的情境因素

分类	因素与描述
人员	凝聚力：该公司具有地理上的分布式结构，团队有效性通过采用工具（尤其是GitHub）得以支持。 Culture：团队文化对变革的抵触较低，变化实际上被推崇为一种非常理想的状态，并通过本文中确定的各种工具和技术实现； 经验、技能与生产力：人员的经验、技能和生产力均处于较高水平，有时被称为“高级版人”。员工群体 tends to be of high 核心技术能力从很低到非常高，个体可以动态且高效地运作，无需大量培训或提升技能； 人员流动率：人员流动率较低（尤其是关键技术人员），从而保证了技术的连续性和高水平的专业知识，因此减少了对相关文档化工件的需求（如产品架构和流程描述）。
需求	可变性：需求频繁变化，突然且重大的变化，是在一个快速变化且高度创新的市场中运营的现实情况。因此，一个精益/敏捷软件开发方法（例如在第3节中所述）在此环境下更为可取。
应用	质量：产品运行质量要求较高，且所采用的技术（包括持续集成系统）在实现产品质量目标方面起到极大帮助； 类型：正在开发和演进的应用程序（尽管需要高质量）不需要达到安全关键软件的水平，也不直接受到市场监管的影响。因此，采用精益流程，通过技术和开发堆栈，适合该组织的需求。
技术	新兴的：该技术是新兴的和创新的，因此新技术的采用程度很高，以及支持流程举措的工具。快速采用支持性技术产品意味着流程本身会因技术的优点和局限性而发生变化。这也是上下文降低了精确性、详细的流程描述的可取性的原因之一，因为这些描述将由于快速变化的步伐而需要不断重新审视。
组织	大小：组织规模较小——导致信息交换和通信可以通过视频会议、电话或面对面会议高效地进行，从而实现更敏捷/精益的软件开发方法； 终端用户：软件的操作型终端用户对需求变化和快速演进持开放态度。事实上，终端用户在这种情况下要求其软件供应商具备此类能力，以在快速发展的市场中追求竞争优势。这一事实对于塑造流程设计至关重要——能够支持按时工时材料支付模型并适应快速变化的需求变更。
管理	专业知识与成就：管理在关键市场和产品方面的专业知识和成就很高，意味着商业可以灵活调整方向，与新兴技术和谐共存，且无风险。商业和技术战略方向正在带来便利。
商业	上市时间：该公司处于一个快速发展的环境中，快速交付需求至关重要（平稳、定期且快速的交付通过采用微服务架构以及Docker等部署基础设施实现）； 业务驱动因素：该公司的业务驱动因素是利用关键开源领域的先锋活动和新兴技术——技术卓越和高创新水平是实现差异化和商业成功的关键； 付款安排：付款条款往往是时间和材料合同模式，支持近实时类型的客户互动，通过微服务架构实现的与客户对功能的深入探讨。

5. 讨论

在软件开发过程中，并不存在一种适用于所有情况的固定模式或风格。流程形式和内容由影响软件开发的情境因素这一复杂混合体所决定，这些情境因素对于每个开发团队而言可能都是独特的，且这些因素本身也处于持续变化之中。影响软件开发的一般领域的情境因素流程可能被视为对软件开发的未来具有战略重要性。作者认为，应鼓励开展揭示流程与其上下文之间相互关系本质的研究，即使这是一项复杂的任务，也应谨慎对待。本文所报告的案例研究是深入理解流程与其上下文之间相互作用的一小步，同时也突显了软件过程关注点的连续性——因为本研究所发现并在本文中描述的NearForm过程，作为一种当代真实世界中有效的软件过程，对于早期几代软件开发者而言几乎是无法想象的。

作者指出，可能是技术与工具方面的新兴发展，使得本文所识别的流程成为可能；这一观察结果或许与敏捷宣言中“个体和互动高于流程和工具”的价值观不相一致。

我们的案例研究不仅展示了特定情境因素与软件过程决策之间的关系，还提供了关于流程与其上下文之间相互作用复杂性的证据。尽管我们的研究仍在进行中，并且存在一些局限性和有效性威胁（由于篇幅限制此处无法详述），但已经明确的是，在所考察公司的案例中，至少有17个独立的情境因素是影响软件开发过程的关键因素。这些因素涉及情境上下文的各个类别，从基本的业务因素、技术因素，到应用和产品因素、组织考虑、需求特征，以及操作终端用户需求。这些都是广泛的关切点，必须通过适当的流程来满足。

因此，软件过程决策是多层次且复杂的，其复杂程度可能超出了所有方面的预期。这种与上下文相互作用的复杂且动态的软件过程决策链条，或许可以解释为何尚未出现一种完全适用于所有场景的通用软件过程方法——简单来说，正是因为软件开发上下文的巨大多样性迷惑并削弱了构建普适的过程模型的努力。