业务复杂度治理方法论--十年系统设计经验总结

一、复杂度综述

1、什么是复杂度

软件设计的核心在于降低复杂性。

--《软件设计的哲学》

业界对于复杂度并没有统一的定义，斯坦福教授John Ousterhout从认知负担和工作量方面给出了一个复杂度量公式





子模块的复杂度cp乘以该模块对应的开发时间权重值tp，累加后得到系统的整体复杂度C

这里的子模块复杂度cp是一个经验值

需要注意：如果一个子系统特别复杂，但是很少使用及修改，也不会对整体复杂度造成太大影响。例：spring框架内部代码较为复杂，但由于几乎不需要我们去变动，所以对系统的整体复杂度影响并不大

2、复杂度分类







本文主要面向业务复杂度的治理

3、业务复杂度高的影响

（1）研发成本高。需要花费更多的时间去理解、维护代码；同样的需求，可能需要要修改更多的工程和类

（2）稳定性差。过高的业务复杂度，会导致系统难以理解甚至理解出现错漏，改动代码后极易出现“按下葫芦起了瓢”的问题

二、业务系统复杂度高的常见原因

1、业务系统模块多，关系复杂，互相依赖





比如一个电商业务，会包含商品、订单、采购、库存、财务等多个系统，系统之间有各种各样的依赖关系关系，如订单系统依赖库存充足才可以正常下单，采购依赖商品必须创建才可以发起采购；而系统内部又可以划分为多个子系统，如订单系统可以包含接单、营销、会员等各个子系统

2、代码晦涩，从代码中很难找到关键信息

如下边的业务处理代码，不点进具体的方法，根本不知道做了什么：

    /**
     * 处理业务逻辑
     */
    public void handleBiz(){
        step1();
        step2();
        step3();
    }

再比如下边的业务处理代码，做了方法定义外的操作，开发者很容易遗漏重要信息

    /**
     * 转换对象方法
     */
    public Po convert(Dto dto){
        Po po=new Po();
        po.field=dto.filed;
        //更新操作，不应该放到转换方法里
        mapper.update(po);
        //调用rpc服务，不应该放到转换方法里
        XXGateway.update(dto);
        return po;
    }