追求代码质量 - 驯服复杂的冗长代码

我毫不惭愧地承认，在看到复杂的代码块时，我也会感到恐惧和心里发毛。事实上，我敢说您在遇到大量方法和乱七八糟四处蔓延的类时，也会 有些心里 发毛的。不能说在这些情况下寻求退路的人不是完人，这只是优秀开发人员的一 种本能。过于复杂的代码难以测试和维护，这通常还意味着更高的出错率。

我在 本系列前面的文章 中已经解释了圈复杂性，它是令人讨厌的代码的一 种先兆。具有高圈复杂度值的测试方法几乎总是把事情弄得一团糟，无法轻易收 场。上一个月，我向您展示了如何使用 Extract Method 模式重构您的代码，从 而将您带出迷宫。降低方法的复杂度可以使代码更易于测试和维护，如图 1 所 示：

图 1. 降低复杂度可以使代码更易于维护和测试

不过，圈复杂性并不是确定高风险代码的惟一复杂性度量。您还可以利用类 长度、方法长度和内部类耦合。这些度量之间存在着错综复杂的关联，但是很容 易发现这些关联。这个月，我将解释它们为什么那么重要，以及如何使用 PMD 和 JavaNCSS 跟踪它们。

代码太多了！

了解简单代码和流畅代码之间的区别非常重要。简单代码不必过分简单或易 于编写，只需易于理解 即可。您可以使用 C++ 编写简单代码，就像使用 Visual Basic 编写它们那样。不过，用任何语言反简化 代码的最快方式都是一 次编写大量的代码。

考虑一下如何将此规则应用于方法和类。大多数人对记住信用卡号感到头疼 的一个简单原因是，我们一次只能管理 7(±2) 片数据。了解了这一点，就会明 白过多的条件会给以后带来麻烦，使测试和维护变得很困难。相同的原理也可以 应用于逻辑块。

所有给定代码主体通常包含已分组的语句，它们拥有共同的目标，比如创建 一个集合，将数据项添加到该集合中。但是，在一个长方法（long method）中 分组数量众多的逻辑块可能会让人很快忘记该方法的总体意图，因为很少有人可 以有效处理这样一个大的数据集。恰恰是这个缺点带来了代码基中的维护问题。冗长的方法是缺陷的避风港，因为很少有人可以有效地分析它们。长方法不仅完 成太多的工作，也需要人们费很大的劲去理解！

就像长方法会让开发人 员讨厌一样，长类（long class）也会令开发人员讨厌。相同的讨论也可以应用 于总体代码，冗长的类可能会做太多的工作，并承担太多的责任。

什么 样才算太长？

当然了，长方法或类的划分有点主观。有一个很有帮助的 经验法则，您可以说非代码注释行超过 100 行的方法是长方法。不过，实际的 数值是根据谈论的人而变化的。就我而言，截止点（cutoff point）大约是 50 行代码，但有些开发人员会说，如果某一方法需要您向下滚动整整一天才能看完 ，那么该方法太长了。截止点的定义取决于您自己。

类似地，您必须有 自己的确定正确类大小的良好判断。许多人所提倡的一条经验法则是，类的代码 行超过 1,000 行就可以说该类太长了。而另一些人则认为最好不要超过 500 行 代码。

内部类耦合

对于一对象与其他对象之间的关系，复杂模式 会不断重复其自身。对于导入许多外部依赖项或者拥有许多 public 方法的类， 不但理解起来有些困难，而且所带来的责任重担的增加也会导致某种脆弱。

我将从依赖项开始。如果某一对象导入的外部类超过 80 个（不包括普 通的 Java™ 系统库），那么就可以说该类具有高度输出耦合，这意味着 更改导入的类可能会影响该类本身。在最糟糕的情况下，如果导入的是具体的类 ，并且它们的行为发生更改，那么执行导入的类可能会中断！

观察对象导入的数量就很容易预测脆弱性，但如果使用 .* 符号（例如 com.acme.user.*）导入整个包，则很可能产生误导。为了更精确起见，可能需 要注

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!