大多数设计良好的软件架构都趋向于支持系统的可扩展性、可维护性和可靠性。遗憾的是，对质量问题的疏忽极可能使软件架构师的努力白费。在追求代码质量 系列的这一期文章中，质量专家 Andrew Glover 解释如何持续地监视并纠正会影响软件架构的长期生存能力的代码质量方面。
上一期文章中，我展示了如何使用代码度量来评估代码质量。尽管在那一期介绍的圈复杂度针对低级细节，如方法中执行路径的数量，但其他类型的度量针对的是代码的更高级方面。在本期文章中，我将展示如何使用各种耦合度量 来分析和支持软件架构。
我将从两个比较有趣的耦合度量开始，即传入耦合 和传出耦合。这些基于整数的度量表示几个相关对象（即相互协调以产生行为的对象）。任一度量中高数值表示架构的维护问题：高传入耦合表示对象具有太多职责，而高传出耦合表示对象不够独立。在本期文章中，我将介绍每个这样的问题及其解决的方法。
具有太多职责并非什么坏事。例如，组件（或包）通常试图用于整个架构中，这就会给它们带来高传入耦合值。核心框架（如 Strut）、登录包（如 log4j）之类的实用工具以及异常层次结构通常具有高传入耦合。
在图 1 中，可以看到一个包 com.acme.ascp.exception 具有一个值为 4 的传入耦合。这并不奇怪，因为 web、dao、util 和 frmwrk 包都希望利用一个公共的异常框架。
图 1. 传入耦合的符号
如图 1 所示，exception 包具有一个值为 4 的传入耦合（或者叫做 Ca），这并非是件坏事。异常层次结构很少会出现很大的改变。监视 exception 包的传入耦合是个好主意，然而，由于彻底改变了这个包中的行为或契约，所以将引起它的四个依赖包全都出现连锁反应。
  |
|
通过进一步检查 exception 包并注意抽象到具体类的比率，可以派生出另一个度量：抽象性。在本例中，exception 包具有零抽象性，因为它的所有类都是具体的。这与我前面的观察是一致的：exception 包中的高度具体性表示对 exception 作出的任何更改将影响所有相关包，即 com.acme.ascp.frmwrk、com.acme.ascp.util、com.acme.ascp.dao 和 com.acme.ascp.web。
通过理解传入耦合表示组件的职责，并持续监视这个度量，可以防止软件架构出现熵（entropy），即使在大多数设计良好的系统中也很容易出现熵。
很多架构设计在利用第三方包时都考虑到了灵活性。获得灵活性最好是通过使用接口来防止架构在第三方包中发生更改。例如，系统设计师可以创建一个内部接口包 来利用第三方记帐代码，但是只对这些使用记帐代码的包公开接口。顺便说一下，这与 JDBC 的工作原理类似。
图 2. 通过设计获得灵活性
如图 2 所示，acme.ascp 应用程序通过 com.acme.ascp.billing 包与第三方记帐包相耦合。这创建了一定级别的灵活性：如果有了另一个第三方记帐包更加有利用价值，那么应该只有一个包会受到变更的影响。此外，com.acme.ascp.billing 的抽象性值是 0.8，这表明它可以通过接口和抽象类来防止被修改。
如果要转换到第三方实现，只需要对 com.acme.ascp.billing 包进行重构。更好的方法是：通过在设计中考虑灵活性以及了解变更的隐含意义，可以通过开发人员测试来防止修改所造成的任何损害。
在对内部记帐包作出变更前，您可以分析代码覆盖率报告，以确定是否有任何测试真正 测试了这个包。找到一些级别的覆盖率后，您可以更仔细地检查这些测试案例来验证它们是否足够了。如果未找到覆盖率，您将会知道，关闭并插入新库的努力将更具风险性并可能花费更长的时间。
使用代码度量收集所有这些似乎正确的信息非常容易。另一方面，如果您根本不了解与测试覆盖率相关的包耦合的知识，那么为替换第三方库确定的时间最多就是个猜测！
文章来源于领测软件测试网 https://www.ltesting.net/
