让开发自动化: 断言架构可靠性

我在曾经从事的很多软件开发项目中观察到，软件开发中一直存在这样一种现象：您实际拥有的架构往往与想象中的不同。

通过分析代码的度量报告，比如由 JDepend （参阅 Resources）工具生成的报告，您可以有效地判定代码是否实现了确定的架构。有些团队对代码做反向设计，得到对应的 UML 图表，也能够达到上述效果，还有一些团队甚至在编程时使用 IDE 生成相同的工件 —— 即实时反向设计。可是，所有的这些方法都还是反应式（reactive）的。您必须手工审视并分析报告或图表，确定架构是否存在偏离，而有时这种偏离可能很久之后才被发现。

设想每当某部分代码与期望的 架构有所违背时，您就得到一个提示 —— 比如一个 Ant 构建脚本失败 —— 如清单 1 所示：

清单 1. 违背架构导致构建失败
...
BUILD FAILED
...
build.xml:35 Test ArchitecturalRulesTest failed

Total time: 20 seconds
 

 关于本系列
作为开发人员，我们的工作就是为终端用户实现过程自动化；然而，很多开发人员却忽略了将自己的开发过程自动化的机会。为此，我编写了 让开发自动化 这个系列的文章，专门探讨软件开发过程自动化的实际应用，并教您何时 以及如何 成功地应用自动化。 
 
本文所提及的技术能够使您通过实现构建自动化主动分析软件架构。除此之外，本文的示例还演示了如何基于规则触发构建过程失败，您可以使用 JDepend 的 API 和 JUnit 定义这些规则。

当然，最重要的是，通过构建自动化，您和您的团队能够在开发周期的前期 发现源代码与确定架构之间的偏离。这就是我所说的掌控架构！

反应式地设置开发阶段

图 1 说明了在构建 Web 应用时一种常见的架构模式。 presentation 层（代表一组相关的包）依赖于 controller 层，controller 层依赖于 domain 和 business 层，最后，business 层依赖于 data 和 domain 层。

图 1. 典型 web 应用的一个架构分层图
 

原文转自：http://www.ltesting.net