讓開發自動化: 斷言架構可靠性

我在曾經從事的很多軟件開發項目中觀察到，軟件開發中一直存在這樣一種現象：您實際擁有的架構往往與想象中的不同。

通過分析代碼的度量報告，比如由 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.kjueaiud.com