敏捷思維－ 架構設計中的方法學(3)源自需求

      注：我們把中間產物定義為為了實現跨邊界的溝通而制定的文檔、模型、代碼。例如設計文檔、數據模型等。參考RUP的Artifact。

      評判軟件成功的標準有很多，對于敏捷方法論來說，成功的標準首先在于交付可用的軟件。為了保證軟件的可用性，最重要的就是做好需求。做好需求的方法有很多（參見拙作需求的實踐），但這并不是我們討論的主題。對于我們要開始的架構設計的工作來說，從需求出發來設計架構，這就是保證軟件可用性的一個基本的保證。

      Context

      我們如何開始我們的架構設計工作？

      Problem

      我們在進行架構設計的時候，往往主要考慮的都是平臺、語言、開發環境、數據庫等一些基本問題，可是對于和客戶的具體情況密切相關的一些問題卻很少系統的考慮。甚至還存在一種誤區，認為架構設計無非就是寫一些空話，套話。這樣子做出來架構設計，如何用于指導軟件的實現呢？

      IT界的技術層出不窮，面對著如此之多的技術、平臺、框架、函數庫，我們如何選擇一組適合軟件的技術？

      每 一個客戶的軟件都有自身的特點，如何才能夠設計出符合客戶利益的架構？

      軟件中往往都充斥著眾多的問題，在一開始就把所有的問題都想清楚往往很難做到，但是如果不解決問題，風險又居高不下。

      Solution

      針對需求設計架構。

      架構設計就是鋪設軟件的主管道（例1）。我們根據什么來制定主管道的粗細、路徑等因素呢？很明顯，是根據城市的人口、地理位置、水源等因素來決定的。對應到軟件設計也是一樣的。城市的各因素就是軟件中的各種需求：功能需求、非功能需求、變化案例等等。

       一般來說，功能需求決定業務架構、非功能需求決定技術架構，變化案例決定架構的范圍。需求方面的知識告訴我們，功能需求定義了軟件能夠做些什么。我們需要根據業務上的需求來設計業務架構，以使得未來的軟件能夠滿足客戶的需要。非功能需求定義了一些性能、效率上的一些約束、規則。而我們的技術架構要能夠滿足這些約束和規則。變化案例是對未來可能發生的變化的一個估計，結合功能需求和非功能需求，我們就可以確定一個需求的范圍，進而確定一個架構的范圍。

      從例2中，我們看到自已字處理軟件的幾種需求的范例。真正的字處理軟件要復雜的多。而我們最主要的就是必須認識到，架構是來自于需求的。有什么樣的需求就有什么樣的架構。試想一下，如果我們沒有對速度的要求，我們還需要考慮這方面的設計嗎？我們上面提到了幾種類型的需求對架構的影響，其實還有一個很重要的需求，就是環境的需求。這并不是一個很重要的需求，但是對于部署（deployment）架構設計來說就特別重要。畢竟，我們開發出的軟件是要上"戰場"的，充分的考慮部署問題是非常有必要的。

      例1：城市中自來水管的架設是一項非常的復雜的工程。為了需要滿足每家每戶的需要，自來水管組成了一個龐大的網絡。在這樣一個復雜的網絡中，如何完成鋪設的任務呢。一般的做法是，先找出問題的根源，也就是水的源頭。從水源鋪設一條管道通至城市，然后根據城市的區域劃分，設計出主管道，剩下的就是使用的問題了，每家每戶的管道最終都是連到主管道上的。因此，雖然自來水網絡龐大復雜。但是真正的主管道的非常簡單的。

       例2：我們打算開發一個字處理軟件，功能需求可以簡單概括為格式化用戶輸入的文字，非功能需求可能是格式化大小為1000K的一段文字的處理速度不能低于10S，變化案例可能是推出多種語言版本。那么我們在設計業務架構的時候，我們會集中于如何表示文字、圖象、媒體等要素，我們該需要有另外的技術架構來處理速度問題，比如緩沖技術，對于變化案例，我們也要考慮相應的架構，比如把字體獨立于程序包的設計。

      從需求到架構

      在需求階段，我們可以得到一些代表需求調研成果的中間產物。比如說，CRC卡片、基本用例模型、用戶素材、界面原型、界面原型流程圖、非功能需求、變化案例等。我們在架構設計階段的主要工作就是要把這些需求階段的中間產物轉換為架構設計階段的中間產物。

      其實，架構設計就是要完成兩項工作，一是分析，二是設計。分析是分析需求，設計則是設計軟件的大致結構。很多的方法論把分析和設計兩種活動分開來，但其實這兩者是很難區分的，做分析的時候會想到如何設計，而思考如何設計反過來又會影響分析的效果�？梢哉f，他們兩者之間是相互聯系和不斷迭代的。這種形態我們將會在后面的迭代設計模式中詳細的討論。

      在敏捷方法論中，需求最好是迭代進行的，也就是說一點一點的作需求。這種做法在那些需求變化快的項目中尤其適用。由于我們采用的流程是一種迭代式的流程，這里我們將會面臨著如何對待上一次迭代的中間產物的問題。如果我們每一次迭代都需要修改已存在的中間產物，那么這種維護的成本未免過大。因此，敏捷方法論的基本做法是，扔掉那些已經沒有用處的中間產物。還記得在第一章的時候，我們強調說軟件要比文檔重要。我們生成中間產物的目的都是為了生成最終的程序，對于這些已經完成作用的模型，沒有必要付出額外的維護成本。

      不要斷章取義的采用拋棄模型的做法。因為，拋棄模型的做法需要一個適合環境的支持。后面會針對這個話題開展大范圍的討論。這里我們簡單的做一個了解：

      簡單化：簡單的模型和簡單的程序。模型和程序越復雜，就需要更多的精力來處理它們。因此，我們盡可能的簡化它們，為的是更容易的處理它們。

      高效的溝通渠道：通過增強溝通的效果來減少對中間產物的需要。試想一下，如果我隨時能夠從客戶那里得到需求的細節資料，那前期的需求調研就沒有必要做的太細致。

      角色的交叉輪換：開發人員之間建立起交換角色的機制，這樣，能夠盡量的避免各子系統諸侯割據的局面。

       清晰的流程：或者我們可以稱之為明確的過程。過程在方法論中向來都是一個重點，敏捷方法論也不例外。開發人員能夠清楚的知道，今天做什么，明天做什么。過程不是給別人看的，而是給自己用的。

      工具：好用的工具能夠節省大量的時間，這里的工具并不僅僅指CASE工具，還包括了版本控制工具、自動化測試工具、畫圖工具、文檔制作和管理工具。使用工具要注意成本和效益的問題。

      標準和風格：語言不通是溝通的一個很大的障礙。語言從某個角度來看屬于一種標準、一種風格。因此，一個團隊如果采用同樣的編碼標準、文檔標準、注釋風格、制圖風格，那么這個團隊的溝通效率一定非常的高。

      如果上述的環境你都不具備，或是欠缺好幾項，那你的文檔的模型還是留著的好。

      僅針對需求設計架構