理解复杂性

软件系统中的复杂性是不可避免的，但并不意味着不可处理。请看 IBM 杰出工程师如何从体系结构和团队组织的角度出发，处理复杂性问题。

来自 The Rational Edge.

对于我们大多数人来说，复杂性是一种“当我看到它时就明白它了”的事物。在软件开发和交付的过程中，我们经常不加以任何达成协议的、技术上的定义来使用术语“复杂性”。这是可以理解的，因为复杂性是难以定义的。它所涉及的不同领域的技术定义或者方法非常广泛， ¹ 包括软件设计， ² 并没有一个简单的、单一的定义。

正如本文所讨论的，复杂性既是不可避免的，也是代价沉重的。实际上，基于以下所讨论的各种原因，复杂性在我们的个人和技术生活中正在逐渐地增多。我们可以说，复杂性以其多样的表现形式，成为我们这个时代的一项关键技术和业务利害。

然而，有一些通用的方法可以减少复杂性所带来的影响。这正是本文的主题。

关于复杂性的思考

通常来说，复杂的事物具有许多互相连接、互相作用的部分。基于这一思想，逐渐缩小复杂性的第一个步骤就是理解所涉及到的复杂性的程度；也就是，我们需要一种测量方法。在这里有两条实用的标准，我们能够使用它们来识别复杂性以及有关测量它的原因。这些标准应用于软件、系统、项目努力、和业务组织上面——实际上，能够应用于任何具有相互作用的部分的实体：

• 预测。难点在于从实体的当前状态或者历史中了解到未来它将如何运转。这对于项目努力和组织来说非常重要。
• 回顾。难点在于懂得实体是如何进入到当前状态的。这对于系统、软件、和系统调试非常重要，并且成为大多数系统和软件复杂性测量的基础。

上半个世纪最关键的领悟之一就是通过这些测量手段，复杂性快速的突出出来。 ³ 根据上述任何一种观点，简单的事物以简单的规则进行相互作用就会快速的变得复杂。例如：

• 一群蚂蚁或者白蚁、蜜蜂、鸟群，它们都是个体根据非常简单的、共同遵守的规则所组成的，它们的行为却不可能被预知，而且它们的历史行为不能够被重建。
• Internet 是由数百万个相关的简单结点组成的。但是它产生了完全不曾预料到的社会和业务行为。
• 一个大型的软件项目，即使具有良好的设计，也是很复杂的。

长期以来，我们总结出来的另外一条经验就是简单即理想。体系结构和设计的一个主要目标就是，找出最简单的解决方案，使得实体能够满足出资方的需要。越简单的事情通常越健壮，不易发生故障，易于修复。这一法则为业务和组织设计所把握。不幸的是，计算机科学告诉我们，没有一种实用的方法来验证我们所采用的设计是否是最简单的。

我们的格言是，只要实体具有相互作用的移动部分，就必然导致复杂性。

复杂性的来源

在我们的职业生涯中，复杂性应用于：

• 我们交付的系统和软件
• 我们参与其中的团队
• 我们所属于的业务组织

纵观所有情况，复杂性有两种来源：

• 上下文环境。实体同外部实体如何相互作用。
• 设计、体系结构。内部实体如何相互作用。

上下文环境的复杂性非常重要，这是因为我们期望预测将要同上面所列出的实体进行交互的世界的行为。如果我们懂得上下文成员的未来行为和需要，那么我们就能够：

• 满怀信心的计划和设计系统
• 创建将会为业务和雇员提供稳定性的组织

由于 Internet 或者其他一些网络技术，所有上下文中的实体彼此之间都相互连接，甚至直接的或者间接的同给定上下文之外的实体相连接。存在于这些上下文实体之间的连接创建出一个巨大的全球网络。例如，未来的开发团队越发表现得像是社会网络中的一员。问题的关键是，所有实体都将成为某一类群体中的一员，上下文复杂性是不可避免的。

驱动设计复杂性的力量是不同的。技术允许我们拥有日益正式的设备和系统，从而我们具备更具能力的、更加正式的软件。这样的设备包括商业产品中的 VHSIC (Very High Speed Integrated Circuits) Hardware Description Language (VHDL) 模块，汽车中的电子控制单元，个人计算机，企业级刀片服务器，以及大型机。我们的期望是软件将在这些设备间分布式使用，根据需要提供功能性，或者平衡处理来满足不可预知的负载。这类复杂性在面向服务的体系结构（SOA）执行的企业级软件中尤其明显，但是能够在所有分布式软件体系结构中发生。这些实体展示出复杂性的种类。因此，调试和预报这些实体的性能非常困难。

复杂性的处理

正如上面所讨论的那样，复杂性不能被避免，甚至不能被证明为最小化。然而，它却能够被处理。在提供相同服务、满足相同需要的实体的空间内部，一些实体比另外一些实体要简单些，找到更简单的系统和组织设计具有巨大的经济价值。未加验证的的复杂性将导致维护和改造方面非常昂贵的系统，这样的系统很快就会过时。这些系统较之简单系统具有更低的价值。复杂的开发组织都存在比例失调的问题；他们的大部分努力都花在了内部交流上面，而忽视了为出资方提供价值。

当您尚未战胜复杂性的时候，您还需要继续的努力。在这一小节中，我将回顾一些关键的技术。

系统和软件

目前，已经制定出两种技术来管理系统和软件的复杂性：

• 体系结构和设计
• 方针和测试

下面，我将分别对这两种技术进行讨论。

体系结构和设计

关于体系结构在工程师和开发人员思考和交流一个系统的过程中所扮演的角色，已经有了许多论述。体系结构的两种属性分别是：

• 封装——隐藏内部数据和方法
• 内聚性——被封装的实体如何相互连接

图1显示的两张图表分别表现了具有相同成分数量的两个实体。在右上方的图表中，没有封装性，具有高度的内聚性。在左下方的图表中，所有成分被封装到三个更大的成分中，并且具有相对较低的内聚性。这一实体相对不复杂。在所有域中的良好的体系结构都通过应用这一规则努力战胜复杂性。达到合适的封装性和内聚性仍然是一门艺术。过多的内聚性将使系统遭受复杂性的全部影响。过少的内聚性将使系统变得脆弱。

体系结构有助于管理复杂性的第二种方法是预期变化——也就是，设计系统必须适应变化的上下文环境。用于变化的体系结构包括两种活动：

• 设计模型，使得它包括被封装的系统以及与其交互的对象（“行动者”）。系统属性和服务被系统需求追踪。有它在手，就能够快速的分析上下文环境中变化所产生的影响。
• 有规律的体系结构的性能进行测试，从而对不可避免的变化做出反应。例如，测量体系结构中由于接口变化、添加功能、或者新的上下文实体的改变所引起的变化的数量。请注意，处理复杂性需要付出努力和投资，但是复杂性本身通常将会导致更大的代价。

图 1. 右上角和左下角的图表都表现了一个相似的复杂的实体，但是左下角图表中所描绘的体系结构显示了封装是如何减少复杂性的。

测试和仿真

对于复杂系统和上下文环境来说，不可能适当的对上下文和系统的行为和执行进行预期，我们需要对行为进行分析、仿真和测试，至少能够得到系统交付功能和性能的一个统计视图。在开发周期的前期阶段，使用仿真和分析工具。随着系统的合拢，将仿真置换为功能性并且进行性能测试。请注意，这种方法在使用迭代开发形式时达到最佳的效果。

组织

像一个系统一样，我们能够对组织如何同它的上下文交互进行建模。这就是业务建模的领域。在 SOA 实践中，出现了业务模型的一个独特的使用。SOA 将组织封装为服务提供者；它通过提供和消费服务来同其他组织进行交互。SOA 的目标就是配置服务，这些服务允许组织通过快速的对无法预料的变化做出响应的能力来处理上下文复杂性。

操作管理 ⁴ 为处理内部复杂性提供了一些方法。特别的，设置 Responsible, Accountable, Consulted 和 Informed (RACI) 架构为处理组织内聚性提供了一种方法。一种有效设置 RACI 架构的方法是，识别组织过程中的决策点，特别是当过程事物改变状态的时候。然后您在这些决策点上识别或者决定谁负责该决策，在管理链条中谁将被负责，谁必须被考虑，以及谁应该被通告。如果这一结构太过密集，那么就有过高的内聚性，并且.该组织将过于复杂以至于影响其效能。

开发团队

开发团队尤其关注复杂性。它们的上下文环境包括一组经常产生分歧的出资方（需求设置者、用户、财务控制官等）。有时设置需求的出资方更加了解俄他们的需要，并且随时更新需求；有时他们的需求是由于上下文的变化而发生改变。无论哪种情况，开发团队需要采取团队方法来预期变化。在开发过程中，期待上下文的稳定性将不会交付令人满意的系统。这就是敏捷开发的一个关键前提 ⁵ 。

同样，开发团队无论规模是大还是小，都是复杂的。团队本身的行为就将变得难以预测。 ⁶ 再者，封装性和内聚性的应用。遵从 Conway 法则， ⁷ 将团队划分以达到封装性的最佳方法就是沿着体系结构的边界。通过让团队工作于体系结构成分或者子系统上，您将在需要它的时候达到高度的内聚性，工作于紧密连接的模块上，以团队间较低的内聚性来更好的完成功能和接口。您还可以封装团队，从而讨论能够被局限在那些外部可见的被封装的成分方面，得到最佳的交流数量。请回顾图1，想象一下每一个结点就是一个人，每一个图表就是一个团队设计。哪一个团队将工作的更加出色呢？

总结 — 一个古老的但是适当的比喻

基于任何一种定义，海洋都是复杂的；在这个例子中，实体是水分子。冲浪者就是同海洋不可预知的运动进行交互。暂时，“冲浪”是一种比喻，它是指既处理复杂性又将其用作自身目标的能力。我们上网冲浪。在80年代，我们在变化的业务环境中冲浪。我们懂得未来将属于那些能够冲浪的人。他们不是同复杂性作斗争，而是乐在其中。善于处理复杂性，当您有能力的时候就尽可能的减少它，当您没有能力的时候就依附在它上面，是今天业务世界中的本质和要素。

在 The Rational Edge 的后续出版物中，我将讨论几种处理复杂性的特定的方法。所以，请放松些，耐心些，并且享受我们的学习过程。

 

¹ 尝试一个 Google 搜索 "Define: Complexity"。

² 我最喜欢的还是 McCabe measure. See McCabe, Thomas J., "A Complexity Measure," IEEE Transactions on Software Engineering, SE-2 No. 4, pp. 308-320, December 1976。

³ 在动态系统理论、混沌理论和细胞自动控制理论方面有大量的著作，请参见期刊 Complex Systems, “About Complex Systems”。

⁴ 请参见 “可运作的 IT 治理”。

⁵ 请参见 http://agilemanifesto.org/ 和 Scott Ambler 的著作 Scott W. Ambler's Home Page。

⁶ M. Cantor, Software Leadership, Addison Wesley, 2001。

⁷ 请参见 Conway's Law 页面 和 wikipedia Conway's_Law 条目。

参考资料

• 参与论坛讨论。
  
  
• 您可以参阅本文在 develperWorks 全球网站上的 英文原文。
  
  
• 一个 新论坛 是专门为 Rational Edge 文章所创建的，所以现在您能够同我们分享您的想法。了解全球各地的同事们都说了什么，提出您自己的讨论，或者加入到正在进行的讨论之中。只需点击 这里。
  
  
• 全球 Rational 用户组社区

 注释