赣榆做网站,制作服务网站,建设通网站查询单位,linode搭wordpress本文属于 dotnet 代码优化系列博客。相信大家都对圈复杂度这个概念很是熟悉#xff0c;本文来和大家聊聊逻辑的圈复杂度。代码优化里面#xff0c;一个关注的重点在于代码的逻辑复杂度。一段代码的逻辑复杂度越高#xff0c;那么维护起来的难度也就越大。衡量代码的逻辑复杂…本文属于 dotnet 代码优化系列博客。相信大家都对圈复杂度这个概念很是熟悉本文来和大家聊聊逻辑的圈复杂度。代码优化里面一个关注的重点在于代码的逻辑复杂度。一段代码的逻辑复杂度越高那么维护起来的难度也就越大。衡量代码的逻辑复杂度的一个维度是通过逻辑圈复杂度进行衡量。本文将告诉大家如何判断代码的逻辑圈复杂度以及一些降低圈复杂度的套路让大家了解如何写出更好维护的代码回顾一下代码设计的目标其中一个很重要的点就是解决 复杂的代码逻辑 和 人类有限的智商 的矛盾。假设人类的智商非常的高无论再复杂的代码逻辑都能理解且人类写出的逻辑也不存在漏洞那其实很多代码设计都是不需要的。现实刚好不是一个稍微复杂的项目就已经不是人类轻而易举能够掌控的。即使是自己编写的代码也会随着时间逐渐遗忘代码里面当初的实现逻辑。何况在团队协作中可能会遇到需要阅读其他开发者留下的代码的时候假设前辈们没有好好的进行编写和设计自然可能是给后来者挖了一个大坑逻辑的圈复杂度属于一个度量代码复杂度的维度但稍微特别的是当逻辑的圈复杂度比较低时能意味着代码复杂度比较低比较好维护。但反过来不成立比较好维护的代码不一定是逻辑的圈复杂度比较低的代码。代码的可维护是需要综合考虑多个维度的虽然说降低逻辑的圈复杂度基本上都是属于正确的事情但由于实际项目遇到的情况比较特殊还请识别主次矛盾不要强行优化逻辑的圈复杂度是指在代码执行过程中逻辑上形成的圈的数量更多的是指在面向对象设计里面的类和方法之间的关系。至于方法内的循环判断等只属于代码圈复杂度Cyclomatic complexity而不是逻辑圈复杂度学术的定义相信大家都不感兴趣下面来举一个例子相信大家看完很快就懂了例子依然是老套的图书管理系统的故事假定书籍有 人文、哲学、物理、数学、计算机 等类型的书籍在图书管理系统里面需要有一定的业务逻辑对其进行处理。其工序有些是所有类型共用的有些是需要根据类型而来的假定每个工序都能用一个代码方法完成。原始的逻辑设计抽象起来如下图从逻辑上看以上的逻辑设计是存在很多个圈圈的相当于不停的拆分、聚合每一次都是在增加逻辑圈复杂度这样的逻辑设计对应到代码里面大概就是一堆 if 或者 switch 判断控制其后续走向或者是面向对象的继承关系让调用穿插在基类和子类之间。假定以上的逻辑设计属于使用了 一堆 if 或者 switch 判断的方式那自然在区分输入类型和工序1里面都会存在判断书籍类型以调用后续逻辑的代码伪代码如下void 区分输入类型()
{if (书籍类型 人文){人文_工序0();}else if (书籍类型 哲学){哲学_工序0();}else if(...){...}
}void 人文_工序0()
{// 工序的逻辑...不分图书类型的_工序1();
}void 哲学_工序0()
{// 工序的逻辑...不分图书类型的_工序1();
}void 不分图书类型的_工序1()
{// 工序的逻辑...if (书籍类型 人文){人文_工序2();}else if (书籍类型 哲学){哲学_工序2();}else if(...){...}
}...从以上的伪代码也可以看到在 区分输入类型 和 不分图书类型的_工序1 之间存在逻辑比较相似的代码那就是拆分书籍类型然后调用不同的方法。当书籍的类型足够多的时候这个逻辑维护起来就开始令人烦躁起来了当工序同样多起来的时候那就更加不好玩咯来数数逻辑的圈圈数量猜猜有多少个圈圈如下图标记出来的只有 4 个圈圈对不其实没有那么简单。嗯不严谨的算上面的逻辑设计图至少有 9 个圈圈如果列出更多的书籍类型以及更多的工序那这个圈的数量能够更加庞大大家也可以想想看每加一个书籍类型会加多少个圈圈世界上还有一群专家也在研究加一个模块或一个功能时圈复杂度的增加速率。在某些时候的设计上会导致加一个模块或加一个功能时增加的圈圈数量会越来越多。例如上面的逻辑设计图在两个书籍类型也就是两个模块时只有三个圈圈但是在有三个模块时就有 9 个圈圈了。也可以看到随着书籍类型的数量也就是模块的数量不断增加的时候每加一个时增加的圈圈数量会越来越多这也就表示了逻辑复杂度每次增加都会越来越多换一句话说如果按照上面的逻辑设计图的方式进行开发会发现越开发越复杂。即使开发者有着很好的编写代码的能力也会逐渐发现整个项目越来越难以掌控。在设计上存在将会导致必然出现的代码逻辑圈复杂度时会导致项目在开发过程中是上帝和程序猿才能看懂代码开发一定时间之后就只有上帝才能看懂代码了在了解基础的知识之后大家也许会问那如何改造降低圈复杂度呢一个套路方法就是在区分类型之后让数据的走向被具体类型进行控制这也是面向对象里多态的一个用法。具体来做就是在 区分输入类型 的类型之后进入某个类型的书籍的总处理方法在某个类型的总处理方法里面可以愉快的从工序的开始执行到工序的结束再来数一下逻辑的圈复杂度是不是一个圈也数不到了对应的代码大概如下可以看到每个总工序里面处理的逻辑一目了然void 人文_总工序()
{人文_工序0();工序1();人文_工序2();工序3();
}void 哲学_总工序()
{哲学_工序0();工序1();哲学_工序2();工序3();
}啥都不用说对比代码量就知道看代码的清晰程度也能看起来降低圈复杂度之后的优化那这时也许有伙伴说如果各个总工序都十分相似是不是也可以再抽一下是的但是也需要看情况如果少部分的重复逻辑可以带来更多的代码清晰度那这部分的逻辑留着也是可以接受的。但如果在抽一下基础类型之后发现逻辑依然清晰那就开干吧毕竟重复的逻辑也不是什么好的事情定义一个书籍处理的抽象基类然后在此基类里面放总工序接着各个具体的书籍处理类型继承基类编写实现方法伪代码如下abstract class 书籍管理基类
{public void 总工序(){工序0();工序1();工序2();工序3();}protected abstract void 工序0();private void 工序1(){// ...}protected abstract void 工序2();private void 工序3(){// ...}
}class 人文书籍管理 : 书籍管理基类
{protected override void 工序0(){人文_工序0();}private void 人文_工序0(){// ...}protected override void 工序2(){人文_工序2();}private void 人文_工序2(){// ...}
}class 哲学书籍管理 : 书籍管理基类
{protected override void 工序0(){哲学_工序0();}private void 哲学_工序0(){// ...}protected override void 工序2(){哲学_工序2();}private void 哲学_工序2(){// ...}
}可以看到这大概也就是一个超级简单的框架了具备了一定的扩展性也就是后续如果还需要加上新的书籍类型也是非常方便的只需要定义多一个类型即可同时逻辑上也相对来说比较清真没有那么复杂以上是借助 C# 里面的抽象类实现的这个套路需要不断让子类型进行重写方法导致逻辑上可能部分是在基类部分是在子类。不过以上的代码写法是没有问题的因为继承关系才只有两层但如果继承关系更多了呢假设有三层甚至更高呢这时执行逻辑可能需要跨越多个类型那逻辑复杂度也会上来假定有如下图的逻辑需要按照顺序或者是执行时间分别调用方法1到6来完成业务端的任务。当存在让子类型层层继承的基类有三个的时候如果调用方法散落在这个基类里面那逻辑复杂度将会是非常高的很多时候静态阅读代码都非常有难度如上图假设以上没有画出来图而是写成代码那想要静态阅读代码了解其中的执行逻辑预计看了一会开始乱了不知道对应的方法应该在哪个类型里面哪个文件里面。好在 C# 里面禁用了多类型继承否则能写出连示意图画出来都能劝退人的代码。可是 C# 里面也有一个叫虚方法的定义允许在基类里面定义虚方法看子类的心情去进行重写有重写就使用子类的没重写就采用基类的上图里面的方法 6 是一个虚方法在基类 2 里面定义但是在 基类 3 被重写。这时将会发现静态阅读的代码不见得就是实际运行的代码。例如阅读到基类 2 里面定义了方法 6 的逻辑然而实际运行的时候执行的是基类 3 的逻辑这里需要补充一点的是静态阅读代码指的是和调试阅读代码相对的阅读代码方式指的是在不开始进行调试的方式进行阅读代码可以在 IDE 的辅助下例如在 VisualStudio 这样的 IDE 辅助下阅读代码。好维护的代码是需要考虑静态阅读代码的因为很多时候调试的时候能跑的路径不会特别全也不会特别多甚至有些逻辑是存在很多前置条件的仅靠调试来了解执行方式可能了解到不全面这也是某些开发老司机会说的“组合由于继承”的其中一点原因大量的继承将会导致逻辑散落在各地不够“内聚”导致逻辑复杂度上升。值得一提是 “组合由于继承” 这句话是具备大量前提的还请不要将这句话作为开发的规范那什么时候应该选择什么方法其实十分主观我的推荐是多试试看写多了然后将自己坑多了自然就知道了。主动去看自己之前写过的复杂逻辑最好别去看别人的否则心态可能会炸看看是否会感觉自己无法理解逻辑如果会的话再想想可以使用什么方式如果再写一次的话可以更加方便阅读代码理清逻辑回顾一下本文告诉了大家什么是代码逻辑圈复杂度以及降低逻辑圈复杂度的套路方法。同时也告诉了大家这个套路也不是万能的做的不好也可以提升代码复杂度.
