Code Smell 重构你的日常代码-圈复杂度高多层嵌套

简介: 圈复杂度(Cyclomatic complexity)[1]是一种代码复杂度的衡量标准,在1976年由Thomas J. McCabe, Sr. 提出。条件分支越多,圈复杂度越高,测试越难覆盖,也越难维护。随着业务的不断演进,代码的不断新增与调整,如果只在原逻辑下加入自己的新逻辑,就会长出一个超高嵌套的“气功波”代码。

作者 | 聂晓龙(率鸽)

来源 | 阿里开发者公众号



前言

圈复杂度(Cyclomatic complexity)[1]是一种代码复杂度的衡量标准,在1976年由Thomas J. McCabe, Sr. 提出。条件分支越多,圈复杂度越高,测试越难覆盖,也越难维护。随着业务的不断演进,代码的不断新增与调整,如果只在原逻辑下加入自己的新逻辑,就会长出一个超高嵌套的“气功波”代码。


在我们的祖传代码中,“气功波”式代码不占少数。新增一个条件分支成本是相对低的,它可以让你在不了解原逻辑情况下,完成自己的逻辑。但会持续对系统产生负债,直到有一天,我们真的完全不知道修改的这一行代码,到底影响到了哪些~




Bad Smell

在进行一项业务需求时,接触到了这段祖传代码,通过非常高的嵌套,取其中一项值。由于数据结构非常复杂,为了保证代码的健壮性,原作者写了非常多条件判断,形成了这样一段超高复杂性的“气功波”代码。

/**
 * 解析工单ACTION数据中的【完结原因】
 * @param caseId 工单ID
 * @return
 */
private String queryResolveAction(Long caseId) {
    ActionQueryBizDTO actionQueryBizDTO = new ActionQueryBizDTO();
    actionQueryBizDTO.setBizId(caseId);   //工单id
    actionQueryBizDTO.setDataSource(1);
    ActionQueryDTO actionQueryDTO = new ActionQueryDTO();
    actionQueryDTO.setBizDTOs(Lists.newArrayList(actionQueryBizDTO));
    Result<PageWithData<ActionDTO>> result = ltppActionQueryService.queryActions(actionQueryDTO);
    log.info("query action results:{}", JSON.toJSONString(result));
    if (result.isSuccess() && result.getData() != null) {
        if (CollectionUtils.isNotEmpty(result.getData().getData())) {
            for (ActionDTO actionDTO : result.getData().getData()) {
                if (ACTION_COMPLETE_CODE.equals(actionDTO.getActionCode())) {
                    JSONObject memoObject = JSON.parseObject(actionDTO.getMemo());
                    JSONArray actionKeyMemoArray = memoObject.getJSONArray("actionKeyMemo");
                    for (Object actionKey : actionKeyMemoArray) {
                        Map<String, Object> actionKeyMap = (Map<String, Object>)actionKey;
                        if (MapUtils.isNotEmpty(actionKeyMap) && COMPLETE_REASON.equals(actionKeyMap.get("key"))) {
                            return String.valueOf(actionKeyMap.get("value"));
                        }
                    }
                }
            }
        }
    }
    log.warn("cannot find action given case id {}, the result is {}", caseId, JSON.toJSONString(result));
    return null;
}



重构思路

1.卫语句返回,减少嵌套层级

卫语句(guard clauses)[2]是一种改善嵌套代码的优化方案,将某些要害(guard)条件优先作判断,从而简化程序的流程走向。

public static String getCaseQuestionTitle(CaseTaskRelatedDO caseTask){
    Map<String, Object> extAttrs = caseTask.getExtAttrs();
    if(extAttrs == null || extAttrs.isEmpty()){
        return null;
    }
    JSONObject xform = JSON.parseObject(String.valueOf(extAttrs.get("xform")));
    if(xform == null){
        return null;
    }
    JSONObject body = xform.getJSONObject("body");
    if(body == null){
        return null;
    }
    return body.getString("question_title");
}


2.函数功能收敛,单一职责原则

单一职责原则(Single responsibility principle)[3]强调一个类应该只有一个发生变化的原因,只负责一处职责,由Robert C. Martin首次在 Agile Software Development [4]中提出,并成为面向对象五大设计原则之一。

/**
 * 查询工单Action信息
 * K,V -> ACTION_CODE,ACTION
 * @param caseId
 * @return
 */
private Map<Integer, ActionDTO> queryCaseActionMap(Long caseId){
    ActionQueryBizDTO actionQueryBizDTO = new ActionQueryBizDTO();
    actionQueryBizDTO.setBizId(caseId);
    ActionQueryDTO actionQueryDTO = new ActionQueryDTO();
    actionQueryDTO.setBizDTOs(Lists.newArrayList(actionQueryBizDTO));
    Result<PageWithData<ActionDTO>> result = ltppActionQueryService.queryActions(actionQueryDTO);
    log.info("query action results:{}", JSON.toJSONString(result));
    if(noActionResult(result)){
        return null;
    }
    List<ActionDTO> actionList = result.getData().getData();
    return actionList.stream().collect(Collectors.toMap(ActionDTO::getActionCode, action -> action));
}


3.复杂逻辑抽象,业务语义显性化

Programs are meant to be ready by humans and only icidentally for computers to execute.
-- Donald Ervin Knuth 人工智能之父
译:代码是用来让人读的,只是顺便让机器执行而已。

同样的功能语句,或许转化成汇编后是同样的代码,但对于阅读者而言,不同的表述形式,对于理解成本会有非常大的不同。

/**
 * 工单无ACTION数据
 * @param result
 * @return
 */
private boolean noActionResult(Result<PageWithData<ActionDTO>> result){
    if(result == null){
        return true;
    }
    if(!result.isSuccess()){
        return true;
    }
    if(result.getData() == null){
        return true;
    }
    if(CollectionUtils.isEmpty(result.getData().getData())){
        return true;
    }
    return false;
}


4.关注点分离,抽象解析器模型

关注点分离(Separation of concerns)[5]是将计算机程序分隔为不同部分以便分块聚焦与处理的一种设计原则。这个概念最早在1974年,Dijkstra Edsger在他的文章 On the role of scientific thought [6]中提出的。分离关注点使得解决特定领域问题的程式码从业务逻辑中独立出来,聚焦问题越小复杂程度越低,问题越易解决。

/**
 * 工单解析工具类
 * @author niexiaolong
 * @date 2022/8/24
 */
public class CaseParser {
    /**
     * 解析工单「完结」状态结论
     * @param actionDTO 工单状态集
     * @return 「完结」结论
     */
    private static String parseCompleteConsequence(ActionDTO actionDTO){
        JSONObject action = JSON.parseObject(actionDTO.getMemo());
        if(action == null){
            return null;
        }
        JSONArray actionKeyArray = action.getJSONArray(ACTION_KEY_MEMO);
        if(actionKeyArray == null || actionKeyArray.isEmpty()){
            return null;
        }
        for (int i=0; i<actionKeyArray.size(); i++){
            JSONObject actionKey = actionKeyArray.getJSONObject(i);
            if(actionKey != null && actionDataKey.equals(actionKey.getString(CaseCodeConstant.COMPLETED_DESC_CODE))) {
                return actionKey.getString(ACTION_VALUE);
            }
        }
        return null;
    }
}


5.业务逻辑统一,抽象层次一致性

抽象层次一致性原则(Single Level of Abstration Principle)[7]是 ThoughtWorks 的总监级咨询师 Neal Ford 在 The Productive Programmer [8]一书中提出来的概念。SLAP 强调每个方法中的所有代码都处于同一级抽象层次。如果高层次抽象和底层细节杂糅在一起,就会显得代码凌乱,难以理解,从而造成复杂性。

public List<XSpaceCaseDTO> queryCaseList(String aliId, int currentPage, int pageSize) {
    // 从xspace获取工单列表信息
    List<CaseTaskRelatedDO> caseTaskInfoList = queryCaseListFromXspace(aliId, currentPage, pageSize);
    // 获取每个工单的状态详情
    Map<Long, CaseActionInfo> caseId2ActionInfoMap = queryCaseId2ActionMap(caseTaskRelatedList);
    // 组装工单数据信息
    List<XSpaceCaseDTO> xSpaceCaseList = caseTaskConvertor.convert(caseTaskInfoList, caseId2ActionInfoMap);
    return xSpaceCaseList;
}



Good Smell

最终我们重构后的代码主体逻辑如下,保证程序健壮性的同时,对不同的职责领域进行划分,保持代码的可读性与可维护性,拯救我们的祖传代码~

private CaseActionInfo queryResolveAction(Long caseId) {
    // 获取工单状态集合
    Map<Integer, ActionDTO> actionMap = queryCaseActionMap(caseId);
    if(actionMap == null){
        return null;
    }
    // 优先判断「完结」状态
    if(actionMap.containsKey(CaseCodeConstant.COMPLETE_ACTION_CODE)){
        ActionDTO completeAction = actionMap.get(CaseCodeConstant.COMPLETE_ACTION_CODE);
        String completeConsequence = CaseParseUtils.getCompleteConsequence(completeAction);
        return buildCaseActionInfo(CaseCodeConstant.CASE_COMPLETED, completeAction.getOperatorNick(), completeAction.getGmtModified(), completeConsequence);
    }
    // 其次判断「联系中」状态
    if(actionMap.containsKey(CaseCodeConstant.CONTACTED_ACTION_CODE)){
        ActionDTO contactAction = actionMap.get(CaseCodeConstant.CONTACTED_ACTION_CODE);
        String contactConsequence = CaseParseUtils.getContactedConsequence(contactAction);
        return buildCaseActionInfo(CaseCodeConstant.CASE_CONTACTED, contactAction.getOperatorNick(), contactAction.getGmtModified(), contactConsequence);
    }
    return CaseActionInfo.emptyAction;
}



Smell Battle

我们来看最终的代码效果对比。代码重构不需要单独挑一个复杂的模块,挑一个完整的时间,重构应该在日常开发当中,在我们的编码习惯当中。

image.png


参考链接:

[1]https://baike.baidu.com/item/圈复杂度/828737

[2]https://deviq.com/design-patterns/guard-clause[3]https://deviq.com/design-patterns/guard-clause[4]https://baike.baidu.com/item/敏捷软件开发:原则、模式与实践/2326384[5]https://baike.baidu.com/item/关注点分离/7515217[6]https://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html
[7]https://www.techyourchance.com/single-level-of-abstraction-principle/[8]https://nealford.com/books/productiveprogrammer


相关文章
|
4月前
|
自然语言处理 Java 机器人
从细节出发:提高你的代码可读性
在编程的世界中,我们总是不断追求更高的性能,更优雅的设计,以及更复杂的特性。然而,我们不应忽视一个基本且重要的原则——代码的可读性。那么究竟何谓代码的可读性?顾名思义,代码可读性是指代码可理解的程度,是代码作者通过代码这个媒介,将需要表达的信息输出到读者脑中的能力。所以有的人说好的代码必然有清晰完整的注释,也有人说代码即注释,是代码简洁之道的最高境界,后者的观点飞哥持保留意见,毕竟真正能够做到代码即注释的有几人呢?
|
8月前
项目实战典型案例14——代码结构混乱 逻辑边界不清晰 页面美观设计不足
项目实战典型案例14——代码结构混乱 逻辑边界不清晰 页面美观设计不足
56 0
|
算法 程序员
常见代码复杂度解析
代码质量评价维度,很多都是些主观性的评价维度,需要有专门的人员去查看评判代码,对于审核的人员代码能力要求比较高,而且有时候往往不同的人审核会得出不同的结论,会有争议。然而也有些对代码客观的分析方式可以帮助我们识别代码质量,节省大量人力去分析代码。比如代码复杂度的分析。
1942 0
|
敏捷开发 人工智能 开发者
Code Smell 重构你的日常代码-圈复杂度高多层嵌套
圈复杂度(Cyclomatic complexity)[1]是一种代码复杂度的衡量标准,在1976年由Thomas J. McCabe, Sr. 提出。条件分支越多,圈复杂度越高,测试越难覆盖,也越难维护。随着业务的不断演进,代码的不断新增与调整,如果只在原逻辑下加入自己的新逻辑,就会长出一个超高嵌套的“气功波”代码。
Code Smell 重构你的日常代码-圈复杂度高多层嵌套
|
敏捷开发 人工智能
Code Smell 拯救你的祖传代码第1期-圈复杂度高多层嵌套
![](https://ata2-img.oss-cn-zhangjiakou.aliyuncs.com/neweditor/34a60c92-1d0d-4b77-9def-511a9d8686c3.png) # 前言 [圈复杂度(Cyclomatic complexity)](https://baike.baidu.com/item/%E5%9C%88%E5%A4%8D%E6%9D%82%E5%
279 0
Code Smell 拯救你的祖传代码第1期-圈复杂度高多层嵌套
|
设计模式 安全 Java
条件语句的多层嵌套问题优化,助你写出不让同事吐槽的代码
前言《阿里巴巴开发手册》中,有关于多 if-else 分支和嵌套的建议和解决方案,如下:那么本文介绍几种优化方案,给大家提供一些思路案例下面是开发中可能会遇到的典型代码:这种情况,我们如何替代多分支和分支嵌套问题呢?如何让代码变得更容易维护和拓展呢?可以先自己思考一下哈..........下面我提供几种方法吧卫语句《重构--改善既有代码的设计》 书籍中有有如下描述:如果某个条件极其罕见,就应该单独检查该条件,并在条件为真时立即从函数中返回。这样的单独检查常常被称为 “卫语句”。使用卫语句,我们可以对上面的示例修改为:先进行条件检查,然后将 if-else 逻辑转成对应的卫语句格式。枚举《Eff
|
架构师 人工智能 中间件
如何自底向上推导应用逻辑架构?+如何自顶向下构建架构?(节选)
如何自底向上推导应用逻辑架构? 一、什么是架构? 大概是在11年前左右,在土豆网做广告平台,同时也做视频CDN的相关事情,当时做一个服务,基础架构是lighttpd + squid + tomcat,将静态资源分离到httpd,get请求使用squid缓存,智能路由使用HTTP post请求,并让tomcat提供服务,当时就觉得这就是架构。
11010 0
重构-改善既有代码的设计-简化函数调用
Rename Method 函数改名 问题函数的名称未能揭示函数的用途。方法修改函数名称。动机好的函数需要有一个清晰的函数名。
971 0
|
程序员
重构-改善既有代码的设计--重构,第一个案例
什么是重构 在不改变代码外在行为的前提下,对代码做出修改以改进程序内部的结构简单地说就是在代码写好后改进它的设计 谁该阅读这本书 专业程序员(能够提高你的代码质量) 资深设计师和架构规划师(理解为什么需要重构,哪里需要重构) 阅读技巧 带着疑问去读: 如果你想要知道重构是什么。
1010 0