研究思考丨关于软件复杂度的困局

作者：王洋(古训)

前言

大型体系的本质问题是杂乱性问题。互联网软件，是典型的大型体系，如下图所示，数百个甚至更多的微服务彼此调用/依靠，组成一个组件数量大、行为杂乱、时刻在变动（发布、配置改变）当中的动态的、杂乱的体系。而且，软件工程师们常常自嘲，“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》：

www.amazon.com/-/zh/dp/173…

《Clean Architecture》：

detail.tmall.com/item.htm?sp…