关于阿里云:研究思考丨关于软件复杂度的困局

作者：王洋(古训)

前言

大型零碎的实质问题是复杂性问题。互联网软件，是典型的大型零碎，如下图所示，数百个甚至更多的微服务互相调用 / 依赖，组成一个组件数量大、行为简单、时刻在变动（公布、配置变更）当中的动静的、简单的零碎。而且，软件工程师们经常自嘲，“when things work, nobody knows why”。

本文将重点围绕软件复杂度进行分析，心愿可能帮忙读者对软件复杂度成因和度量形式有所理解，同时，联合本身的实践经验谈谈咱们在理论的开发工作中如何尽力防止软件复杂性问题。

导致软件复杂度的起因

导致软件复杂度的起因是多种多样的。

宏观层面讲，软件简单是随同着需要的一直迭代与日俱增的必然产物，次要起因可能是：

1. 对代码腐化的让步与始终让步。

2. 不足欠缺的代码品质保障机制。如严格的 CodeReview、性能评审等等。

3. 不足常识传递的机制。如无无效的设计文档等作为常识传递。

4. 需要的复杂性导致系统的复杂度一直叠加。比方：业务要求明天 A 这类用户权利一个图标展现为✳️，过了一段时间，从 A 中切分了一部分客户要展现🌟。

对于前三点我感觉能够通过日常的工程师文化建设来尽量避免，然而随着业务的一直演变以及人员的流动、常识传递的缺失，长期的叠加之下必然会使得零碎越发的简单。此时，我感觉还须要进行零碎的重构。

从软件开发宏观层面讲，导致软件简单的起因概括起来次要是两个：依赖（dependencies）和费解（obscurity）。

依赖会使得批改过程牵一发而动全身，当你批改模块一的时候，也会牵扯到模块二、模块三等等的批改，进而容易导致系统 bug。而费解会让零碎难于保护和了解，甚至于在呈现问题时难于定位问题的根因，要花费大量的工夫在了解和浏览历史代码下面。

软件的复杂性往往随同着如下几种表现形式：

批改扩散

批改时有连锁反应，通常是因为模块之间耦合过重，相互依赖太多导致的。比方，在咱们认证零碎中已经有一个判断权利的接口，在零碎中被援用的到处都是，这种状况会导致一个重大问题，往年这个接口正好面临降级，如果过后没有抽取到一个适配器中去，那整个零碎会有很多中央面临批改扩散的问题，而这样的变更比拟抽取到适配器的批改老本是更高更危险的。

@Override
public boolean isAllowed(Long accountId, Long personId, String featureName) {
    boolean isPrivilegeCheckedPass = privilegeCheckService.isAllowed(accountId, personId, featureName);
    return isPrivilegeCheckedPass;
}

认知累赘

当咱们说一个模块费解、难以了解时，它就有过重的认知累赘，开发人员须要较长的工夫来了解功能模块。比方，提供一个没有正文的计算接口，传入两个整数失去一个计算结果。从函数自身咱们很难判断这个接口是什么性能，所以此时就不得不去浏览外部的实现以了解其接口的性能。

int calculate(int v1, int v2);

不可知（Unknown Unknowns）

相比于前两种症状，不可知危险更大，在开发需要时，不可知的改变点往往是导致重大问题的次要起因，经常是因为一些费解的依赖导致的，在开发完一个需要之后感觉心里很没谱，隐约感觉本人的代码哪里有问题，但又不分明问题在哪，只能祷告在测试阶段可能裸露进去。

软件复杂度度量

Manny Lehman 传授在软件演进法令中首次系统性提出了软件复杂度：

软件 (程序) 复杂度是软件的一组特色，它由软件外部的互相关联引起。随着软件的实体（模块）的减少，软件外部的互相关联会指数式增长，直至无奈被全副把握和了解。

软件的高复杂度，会导致在批改软件时引入非主观用意的变更的概率回升，最终在做变更的时候更容易引入缺点。在更极其的状况下，软件简单到简直无奈批改。

在软件的演化过程中，不断涌现了诸多实践用于对软件复杂度进行度量，比方，Halstead 复杂度、圈复杂度、John Ousterhout 复杂度等等。

Halstead 复杂度

Halstead 复杂度（霍尔斯特德简单度量测）(Maurice H. Halstead, 1977) 是软件迷信提出的第一个计算机软件的剖析“定律”，用以确定计算机软件开发中的一些定量法则。Halstead 复杂度依据程序中语句行的操作符和操作数的数量计算程序复杂性。针对特定的演算法，首先需计算以下的数值：

上述的运算子包含传统的运算子及保留字，运算元包含变数及常数。

依上述数值，能够计算以下的量测量：

举一个🌰，这是一段咱们以后利用中接入 AB 试验的适配代码：

try {DiversionRequest diversionRequest = new DiversionRequest();
    diversionRequest.setDiversionKey(diversionKey);

    if (MapUtils.isNotEmpty(params)) {DiversionCondition condition = new DiversionCondition();
        condition.setCustomConditions(params);
        diversionRequest.setCondition(condition);
    }
    ABResult result = xsABTestClient.ab(testKey, diversionRequest);
    if (result == null || !result.getSuccess()) {return null;}

    return result.getDiversionResult();} catch (Exception ex) {log.error("abTest error, testKey:{}, diversionKey:{}", testKey, diversionKey, ex);
    throw ex;
}

咱们梳理这段代码中的估算子和运算元以及别离统计出其个数：

依据统计下面统计失去的对应的数据咱们进行计算：

Halstead 办法长处

1. 不须要对程序进行深层次的剖析，就可能预测错误率，预测保护工作量；

2. 有利于我的项目布局，掂量所有程序的复杂度；

3. 计算方法简略；

4. 与所用的高级程序设计语言类型无关。

Halstead 办法的毛病

1. 仅仅思考程序数据量和程序体积，不思考程序控制流的状况；

2. 不能从根本上反映程序复杂性。给我的直观感触是他可能对软件复杂性进行度量，然而很难讲清楚每一部分代码是好还是坏。

圈复杂度

圈复杂度 (Cyclomatic complexity) 是一种代码复杂度的衡量标准，在 1976 年由 Thomas J. McCabe, Sr. 提出。

在软件测试的概念里，圈复杂度用来掂量一个模块断定构造的复杂程度，数量上体现为线性无关的门路条数，即正当的预防谬误所需测试的起码门路条数。圈复杂度大阐明程序代码可能品质低且难于测试和保护，依据教训，程序的可能谬误和高的圈复杂度有着很大关系，一般来说，圈复杂度大于 10 的办法存在很大的出错危险。

计算方法：

计算公式 1：V(G)=e-n+2。其中，e 示意控制流图中边的数量，n 示意控制流图中节点的数量。

计算公式 2：V(G)= 区域数 = 断定节点数 +1。圈复杂度所反映的是“断定条件”的数量，所以圈复杂度实际上就是等于断定节点的数量再加上 1，也即控制流图的区域数。

计算公式 3：V(G)=R。其中 R 代表立体被控制流图划分成的区域数。

举个🌰，以后面 AB 试验的代码片段为例子，画出流程图如下，通过计算得出其圈复杂度为 4：

流程图

John Ousterhout 的复杂度定义

John Ousterhout（约翰欧斯特霍特），在他的著述《A Philosophy of Software Design》中提出，软件设计的外围在于升高复杂性。他抉择从认知的累赘和开发工作量的角度来定义软件的复杂性，并且给出了一个简单度量公式：

子模块的复杂度乘以该模块对应的开发工夫权重值，累加后失去零碎的整体复杂度 C。零碎整体的复杂度并不简略等于所有子模块复杂度的累加，还要思考开发保护该模块所破费的工夫在整体工夫中的占比（对应权重值）。也就是说，即便某个模块非常复杂，如果很少应用或批改，也不会对系统的整体复杂度造成大的影响。

如何防止复杂度问题

软件复杂度问题能够完全避免么？我感觉不可能，然而这并不能成为咱们漠视软件复杂度的理由，有很多措施能够帮忙咱们尽量避免本身的需要开发或工作中引入问题代码而导致软件简单。这里联合日常的开发了解谈一下本人的认知：

1. 开发前：咱们能够通过需要梳理积淀需要剖析、架构设计等文档作为常识传递的载体。

2. 开发中：咱们须要强化零碎架构了解，策略优先于战术，零碎分层架构清晰对立，开发中接口设计要做到高内聚和低耦合同时保持良好代码正文的习惯。

3. 维护阶段：咱们能够进行代码重构，针对之前存在设计问题的代码，以新的思维和架构实现计划进行重构使得代码越来越清晰。

策略先于战术

在战术编程中，开发者次要关注点是可能 work，比方修复一个 bug 或者减少一段兼容逻辑。乍一看，代码可能 work，性能也失去了修复，然而，战术编程曾经为零碎设计埋下了坏的滋味，只是还没人觉察，当雷同的代码交接给前人的时候，常常会听到一句“屎山一样的代码”，这就是以战术编程长期累积的后果，是短视的，不足宏观设计导致系统一直的引入复杂性问题以至于代码很容易变得费解。

成为一名优良的软件设计师的第一步是意识到仅仅为了实现工作编写代码是不够的。为了更快地实现以后的工作而引入不必要的复杂性是不可承受的。最重要的是这个零碎的长期构造。–John Ousterhout（约翰欧斯特霍特），《A Philosophy of Software Design》

目前咱们所保护的零碎往往都是在前人代码的根底上进行降级和扩大，日常需要开发工作中，一个重要的工作是借助需要开发的契机，推动需要所波及到坏滋味的设计可能面向未来扩大，而非仅仅着眼于实现以后的需要，这就是我了解的 策略编程。

举一个🌰，有一个音讯监听的解决逻辑，依据不同的业务执行对应的业务解决，其中一部分要害代码如下，能够猜测依照战术编程的思路当前会还会有有数的 else if 在前面进行拼接实现，而这里齐全能够通过策略模式的形式进行简略的重构，使得后续业务接入时更加清晰和简略。

 public void receiveMessage(Message message, MessageStatus status) {
    // .....
    if(StringUtils.equals(authType, OnetouchChangeTypeParam.IC_INFO_CHANGE.getType()) 
                 || StringUtils.equals(authType, OnetouchChangeTypeParam.SUB_COMPANY_CHANGE.getType())){if(StringUtils.equals("success", authStatus)){oneTouchDomainContext.getOneTouchDomain().getOnetouchEnableChangeDomainService().notifySuccess(userId.toString(), authRequestId);
             }
         } else if(StringUtils.equals(authType,AUTH_TYPE_INTL_CGS_ONSITE)){// XXXXXX} else if(StringUtils.equals(authType,AUTH_TYPE_INTL_CGS_ONSITE_CHANGE)) {// XXXXXX} else if (AUTH_TYPE_VIDEO_SHOOTING.equals(authType)) {if (AUTH_STATUS_SUCCESS.equals(authStatus)) {// XXXXXX} else if (AUTH_STATUS_PASS.equals(authStatus)) {// XXXXXX} else if (AUTH_STATUS_SUBMIT.equals(authStatus)) {// XXXXXX}
         }
         // .....
 }

短期来看策略编程的老本会高于战术编程，然而从下面的案例长期来看，这样的老本是值得的，他可能无效的升高零碎的复杂度，从而长期来看最终能升高后续投入的老本。开发同学在需要迭代的过程中应该先通过策略编程的思维进行设计和思考，而后再进行战术实现，所以我的观点是策略设计要优先于战术实现。

高内聚低耦合设计

高内聚低耦合，是判断软件设计好坏的规范，次要用于程序的面向对象的设计，次要看类的内聚性是否高，耦合度是否低。目标是使程序模块的可重用性、移植性大大加强。通常程序结构中各模块的内聚水平越高，模块间的耦合水平就越低，当模块内聚高耦合低的状况下，其外部的腐化问题不容易扩散，从而带给零碎自身的益处就是复杂度的升高。

内聚是从性能角度来度量模块内的分割，好的内聚模块该当做好一件事件，它形容了模块外部的性能分割；而耦合是软件结构中各模块之间相互连接的一种度量，耦合强弱取决于模块间接口的依赖水平，如调用一个模块的点以及通过接口的数据等。那么如何实现一个高内聚低耦合的接口呢？

简化接口设计

简略的接口往往意味着调用者应用更加不便，如果咱们为了实现简略，提供一个简单的接口给内部使用者，此时往往带来的是耦合度增大，内聚升高，继而当该接口呈现降级等场景时会产生批改扩散的问题，进而影响面产生扩散，带来肯定的隐患。

因而，在模块设计的时候，要尽量恪守 把简略留给他人，把简单留给本人的准则。

比方这样一个例子，上面两段代码实现的是同样的逻辑，办法一的设计显著要因为办法二，为什么？办法一更简略，而办法二显著违反了把简略留给他人，把简单留给本人的准则。如果你是接口的使用者当你应用办法二的时候，你肯定会遇到的两个问题：第一，须要传递哪些参数要靠问办法的提供方，或者要看办法的外部实现；第二，你须要在取到返回值后从返回值中解析本人想要的后果。这些问题无疑会让零碎复杂度晋升。

所以，咱们要简化接口设计，把简略留给他人，把简单留给本人，从而保障接口的高内聚和低耦合，进而升高零碎的复杂度。

@Override
public boolean createProcess(StartProcessDto startProcessDto) {// XXXXXXX}

@Override
public HashMap createProcess(HashMap dataMap) {// XXXXXXX}

暗藏实现细节

暗藏细节指的就是只给调用者裸露重要的信息，把不重要的细节暗藏起来。接口设计时，咱们要通过接口通知使用者咱们须要哪些信息，同时也要通过接口通知使用者我会给到你哪些信息，至于外部如何实现使用者不须要关怀的。

还是以下面的接口的实现为例子，办法一对外部实现细节达到了屏蔽，使得以后接口具备更好的内聚性，当外部实现的服务须要调整时只须要批改外部的实现即可，而办法二则不然。通过这个案例也可能理论领会到，把外部的实现细节暗藏在实现方的外部可能无效的晋升接口的内聚性升高零碎耦合，随之带来的是零碎复杂度的升高。

@Override
public boolean createProcess(StartProcessDto startProcessDto) {Validate.notNull(startProcessDto);
    try {HashMap<String, Object> dataMap = new HashMap<>(8);
        dataMap.put(MEMBER_ID, startProcessDto.getMemberId());
        dataMap.put(CUSTOMER_NAME, startProcessDto.getCustomerName());
        dataMap.put(GLOBAL_ID, startProcessDto.getGlobalId());
        dataMap.put(REQUEST_ID, startProcessDto.getAvRequestId());
        String authType = startProcessDto.getAuthType();
        String taskCode = getTaskCode(authType);

        HashMap resultMap = esbCommonTaskService.createProcess(AV_ORIGIN_AV, taskCode, dataMap);
        return (MapUtils.isNotEmpty(resultMap) && TRUE.equals(resultMap.get(IS_SUCCESSED)));
    } catch (Exception e) {LOGGER.error("createProcess error. startProcessDto:{}",
                JSON.toJSONString(startProcessDto), e);
        throw e;
    }
}

@Override
public HashMap createProcess(HashMap dataMap) {Validate.notNull(dataMap);
    try {HashMap process = esbCommonTaskService.createProcess(ORIGIN_AV, TASK_CODE, dataMap);
        return process;
    } catch (Exception e) {LOGGER.error("createProcess error. dataMap:{}", JSON.toJSONString(dataMap), e);
        throw e;
    }
}

通用接口设计

通用接口设计并不是说所有的场景都为了通用而设计，而是针对具备同样能力的多套实现代码而言，咱们能够抽取成通用的接口设计，通过业务类型等标识辨别实现一个接口实现。

举一个例子，有一个需要是同时实现多种会员的权利列表性能，因为不同会员的权利并不完全相同，所以刚开始的想法是离开设计不同的接口来承接不同会员的权利内容的获取，然而实质上实现的是同样的内容：查问会员权利，所以最终通过对畛域模型的重构抽取了对立的模型从而实现了通用的权利查问的接口。

public List<RightE> getRights(RightQueryParam rightQueryParam) {
    // 参数校验
    checkParam(rightQueryParam);
    Locale locale = LocaleUtil.getLocale(rightQueryParam.getLocale());
    // 查问商家权利
    RightHandler rightHandler = rightHandlerConfig.getRightHandler(rightQueryParam.getMemberType());
    if (rightHandler == null) {log.error("getRightHandler error, not found handler, rightQueryParam:{}", rightQueryParam);
        throw new BizException(ErrorCode.NOT_EXIST);
    }
    List<RightE> rightEList = rightHandler.getRights(rightQueryParam.getAliId(), locale);
    return rightEList;
}

分层架构

从经典的三层架构到畛域驱动设计都有波及到分层架构，分层架构的外围其实我了解是隔离，将不同职责的对象划分到不同的层中实现，良好的分层可能实现软件外部复杂度问题的隔离，升高“洪泛”效应。

端口适配器架构将零碎划分为外部（业务逻辑）和内部（客户申请 / 基础设施层 / 内部零碎）。被动适配器（Driving adapters）承接了内部申请，零碎外部业务逻辑能对其进行被动适配，独立于不同的调用形式提供通用的接口。被动适配器（Driven adapters）承接了外部业务逻辑调用内部零碎的诉求，为了防止内部零碎净化外部业务逻辑，通过适配屏蔽内部零碎的底层细节，有利于外部业务逻辑的独立性。在简单软件的开发过程中，很容易呈现分层的混同，逐步呈现分层不清晰，零碎业务逻辑和交互 UI/ 基础设施等代码逻辑逐步耦合，导致业务逻辑被净化的问题，而端口适配器正是要解决该类问题。

六边形架构

Onion Architecture（洋葱架构，于 2008 年）由杰弗里 · 帕勒莫提出，洋葱架构是建设在端口适配器架构的根底上，将畛域层放在利用的核心，内部化 UI 和基础设施层（ORM，音讯服务，搜索引擎）等，更进一步减少外部档次划分。洋葱模型将利用分层细化，抽取了应用服务层、畛域服务层、畛域模型层等，并且也明确了利用调用依赖的方向：

1. 外层依赖于内层。

2. 内层对外层无感知。

洋葱架构

正文与文档

正文与文档往往在开发过程中会被忽视，作为常识传递的载体，其实是很重要的存在，他们可能帮忙咱们更疾速的了解实现逻辑。

正文可能帮忙了解逻辑；正文是开发过程中思维逻辑最间接的体现，因为其和代码绑定在一起，绝对于文档浏览更不便，查看和了解代码时有助于了解。

文档可能帮忙了解架构设计，在团队的单干或者交接过程中，很难用几句话就可能讲清楚，此时须要通过文档帮忙合作方来更好的了解每一处细节以及整体的架构设计计划的全貌。

重构

如果日常开发过程中曾经很留神了，然而多年之后发现其实之前的实现并不是最优的，此时，就能够通过零碎重构来解决。

当你保护一个多年生长成的零碎时，肯定会发现零碎中一些不合理的中央，这是软件复杂度问题长期积累的后果，此时就须要咱们在日常的开发过程中对系统外部的实现逻辑进行适当的重构以使得系统对将来具备更好的扩展性和可维护性。

重构：对软件内部结构的一种调整，目标是在不扭转软件可察看行为的前提下，进步其可了解性，升高其批改老本。应用一系列重构手法，在不扭转软件可察看行为的前提下，调整结构。傻瓜都能写出计算机能够了解的代码。唯有能写出人类容易了解的代码的，才是优良的程序员。– Martin Fowler《重构 改善既有代码的设计》

看一个简化版本的例子，上面的代码局部是一个查问升金报告详情数据的接口，会发现两头有一大段的信息是在转换 aliId，但实际上这个行为并不是以后办法的重点，所以这里的单纯针对这一段我感觉应该独自抽取一个专用的办法进去。

public ReportDetailDto getDetail(ReportQueryParam queryParam) {if (null == queryParam) {log.error("queryParam is null");
        throw new BizException(PARAM_ERROR);
    }
    Long aliId = queryParam.getAliId();
    if (null == aliId) {if (StringUtils.isBlank(queryParam.getToken())) {log.error("aliId and token are both null. queryParam: {}",
                    JSON.toJSONString(queryParam));
            throw new BizException(PARAM_ERROR);
        }
        aliId = recommendAssistantServiceAdaptor.getAliIdByToken(queryParam.getToken());
        if (null == aliId) {log.error("cannot get aliId by token. queryParam: {}", JSON.toJSONString(queryParam));
            throw new BizException("ALIID_NULL", "aliId is null");
        }
    }

    // 获取同步数据
    // 数据结构转换
    return convertModel(itemEList);
}

总结

本文次要论述了集体对软件复杂度的思考，剖析了导致软件复杂度的起因、软件复杂度的度量形式以及论述了自我了解的如何防止软件复杂度的问题。

只有每个人在每一个需要的开发中秉持匠心，继续晋升本身架构设计的能力，先策略设计后战术实现，并针对开发过程中遇到的问题代码可能踊跃的进行重构，置信软件复杂度的问题也会一直的被咱们击溃，胜利的旗号永远属于平凡的程序员。

参考：

零碎窘境与软件复杂度，为什么咱们的零碎会如此简单

《A Philosophy of Software Design》：

https://www.amazon.com/-/zh/dp/173210221X/ref=sr_1_1?qid=1636…

《Clean Architecture》：

https://detail.tmall.com/item.htm?spm=ata.21736010.0.0.2e6375…