上一篇：拥抱质量：代码质量 之 魔鬼数字
老太太的裹脚布 – 又臭又长！
看代码的时候遇到几屏翻不到头的方法，那是非常痛苦的。
质量问题：超长的方法和超大的类。
出现频率： 三 颗星
杀伤力： 四颗星
预防难度： 四 颗星
为什么将该问题的预防难度定的比较高？
因为将一个复杂逻辑拆车小的方法和小的类，并且能够合理的组织调用关系，需要较高的设计能力。 只是简单的将代码切分，是没有意义的。 实际上，降低单体方法的长度，并不仅仅是为了阅读的方便，更重要的是为了使得流程更加清晰。
超长/ 超大的定义：
这个标准不太统一，通常认为，一个单一的方法长度超过两屏（30-50 行），就需要留意。 一个类，如果总行数超过1000 行，也通常要考虑是不是需要将其功能进行拆分。当然，对于一个类或者方法是否超长，不能机械的用数字来切分，还应该结合其业务逻辑进行分析，但代码中普遍存在过长的方法，是不正常的。
超长/ 超大的危害：
1、 超长方法一般都有多层 if/for/while 嵌套构成，业务逻辑复杂，要进行一个很小的修改都要瞻前顾后
2、 超长方法阅读困难，因为很有可能在 3 页之前定义了一个变量，中间经过 N 次赋值，才到当前位置，很难推测这个变量的当前状态
3、 超大的类，通常预示着这个类承载了本不该由他来实现的逻辑（往往是逐渐追加代码造成的）
解决方案：
重构。
1 、分析一个方法所实现的功能，先考虑是否可以先从功能角度进行分离。 比如，某个方法，根据数据类型，决定将数据存放到数据库还是文件，这种情况，可以拆成三个方法：入库和写文件各一个方法，而另一个方法负责根据数据调用前两个方法。
2 、分析一个方法实现某一功能的步骤，将每一步都抽象成一个方法来实现，拆分后的某一步如果仍然很复杂，则继续向下拆分。
3 、分析业务逻辑，提取公共代码，缩减代码量。通常我们可以在超长的方法中，在不同的逻辑分支见到非常类似的代码， 这样的代码应该提取出来，形成独立的方法供调用。
4、 乾坤大挪移。产生超长方法的另一个原因是写代码的人偷懒，把本来不应该在当前类中处理的逻辑也写了进来， 这种情况下，应该将涉及的业务逻辑代码，移动到合适的类上去。
5 、在重构方法的同时，往往需要同时重构类。
现实中的裹脚布：
方法长度是一个直接指标，经过静态代码分析工具的计算，会被折合成一个循环复杂度指标。 通常循环复杂度超过 10 的方法，建议必须重构。
如下的代码结构，抽取自一个循环复杂度 超过 70 的方法（只留下了结构），方法长度 大于300 行：
要读懂这样的代码，需要什么样的耐心和天才啊。
扫一扫
121
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
