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天前
|
设计模式 关系型数据库 测试技术
代码之美:在简洁与复杂之间寻找平衡
【4月更文挑战第27天】 在软件开发的世界中,代码不仅是实现功能的工具,也是艺术表达的媒介。本文探讨了如何在编写代码时寻找简洁性与功能性之间的平衡点,以及如何通过这种平衡提升代码的可读性、可维护性和扩展性。我们将深入分析几个关键的编程原则和实践方法,并展示它们如何帮助开发者在构建复杂系统时保持清晰和控制力。
|
6月前
|
自然语言处理 Java 机器人
从细节出发:提高你的代码可读性
在编程的世界中,我们总是不断追求更高的性能,更优雅的设计,以及更复杂的特性。然而,我们不应忽视一个基本且重要的原则——代码的可读性。那么究竟何谓代码的可读性?顾名思义,代码可读性是指代码可理解的程度,是代码作者通过代码这个媒介,将需要表达的信息输出到读者脑中的能力。所以有的人说好的代码必然有清晰完整的注释,也有人说代码即注释,是代码简洁之道的最高境界,后者的观点飞哥持保留意见,毕竟真正能够做到代码即注释的有几人呢?
|
10月前
项目实战典型案例14——代码结构混乱 逻辑边界不清晰 页面美观设计不足
项目实战典型案例14——代码结构混乱 逻辑边界不清晰 页面美观设计不足
69 0
|
11月前
|
程序员 测试技术
《重构2》第十章-简化条件逻辑
《重构2》第十章-简化条件逻辑
305 0
|
算法 程序员
常见代码复杂度解析
代码质量评价维度,很多都是些主观性的评价维度,需要有专门的人员去查看评判代码,对于审核的人员代码能力要求比较高,而且有时候往往不同的人审核会得出不同的结论,会有争议。然而也有些对代码客观的分析方式可以帮助我们识别代码质量,节省大量人力去分析代码。比如代码复杂度的分析。
2222 0
|
PHP
tp3.2.3框架多层嵌套if的bug
tp3.2.3框架多层嵌套if的bug
107 0
tp3.2.3框架多层嵌套if的bug
|
敏捷开发 人工智能 开发者
Code Smell 重构你的日常代码-圈复杂度高多层嵌套
圈复杂度(Cyclomatic complexity)[1]是一种代码复杂度的衡量标准,在1976年由Thomas J. McCabe, Sr. 提出。条件分支越多,圈复杂度越高,测试越难覆盖,也越难维护。随着业务的不断演进,代码的不断新增与调整,如果只在原逻辑下加入自己的新逻辑,就会长出一个超高嵌套的“气功波”代码。
Code Smell 重构你的日常代码-圈复杂度高多层嵌套
|
SQL 缓存 安全
如何避免写重复代码:善用抽象和组合
通过抽象和组合,我们可以编写出更加简洁、易于理解和稳定的代码;类似于金字塔的建筑过程,我们总是可以在一层抽象之上再叠加一层,从而达到自己的目标。但是在日常的开发工作中,我们如何进行实践呢?本文将以笔者在Akka项目中的一段社区贡献作为引子分享笔者的一点心得。
141 0
如何避免写重复代码:善用抽象和组合
|
敏捷开发 人工智能
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%
307 0
Code Smell 拯救你的祖传代码第1期-圈复杂度高多层嵌套
|
C语言
逻辑正确的重要性
源自近一个月的项目,在程序逻辑方面犯了错误,原地打转拖延了进度,也由此深刻认识到逻辑对于程序的重要性。
135 0
逻辑正确的重要性