|
|
英文原文：Agile and Architecture Conflict
實施敏捷方法和設計企業架構之間總是存在某種沖突。敏捷開發強調隨著對業務領域的深入理解，逐步調整設計和計劃。架構設計則要求建立起技術架構（technology stack）。它可以滿足質量屬性（quality attributes），也可以向感興趣的利益關系人進行展示，作為一種溝通的途徑。當使用敏捷方法來引領所需的架構設計的時候，兩者強強聯手將會是雙贏。
Tom Graves認為敏捷需要一個脊柱來支撐。而軟件架構提供了這個脊柱。
敏捷通常需要一個脊柱來指引方向——根據這個方向，推動一些工作的進行。這樣做，相對于隨意出牌，可以完成更多的工作。通常，這是個平衡問題——要在堅實的脊柱和敏捷之間有個良好的平衡。
Jan Van Til贊同Tom的觀點，他認為沒有后臺的脊柱，前端也很難看得出有多敏捷。
我們當然需要一個相對進展“緩慢”的“后臺”，這樣才能讓我們看清我們有多敏捷（“前端”）。如果所有的東西都很時尚...我們還能從中識別出哪個是時尚嗎？我們當然需要一個有點“緩慢”的“后臺”，這樣才能讓我們看清時尚（“前端”）。換句話說，我們需要傳統的東西，沒有傳統的東西，也就沒有了時尚。
Simon Brown覺得，甚至“絕大部分的敏捷項目”可能都有或大或小的架構方面的問題。我們需要在項目早期迭代中解決它們。Simon認為，敏捷和架構的沖突可以歸結為是通過短迭代來交付商業價值，還是做一個龐大的預先設計。這里的關鍵點是設計要“剛剛好”（just enough）。準備好一個初步的結構是很重要的，但這不意味著就要畫出無數的詳細類圖。
John Bauer則提到，在對幾個項目觀察了一段時間以后，他發現了一個有趣的模式。
敏捷以及那些類似敏捷的方法有個好處，對于產品來說，它能減少那些架構設計過度的軟件解決方案（over architect-ed software solutions）的產生。架構設計過度的解決方案會強調軟件應用項目的交付，也會使得軟件開發和維護的成本上升，通常來說，是跟交付商業價值背道而馳的。
James Coplien和Kevlin Henney 給我們介紹了一種從項目開始的時候就進行“剛剛好”的架構設計，并且確保項目成功的有效方法。
但是，這一切在現實世界里又是怎么實現的呢？
Simon Brown在他的博文中提出了一個有趣的挑戰：他要求在4個月左右的時間內，重新開發一個程序來取代老邁的在線銀行系統 。他要求大家仍然使用敏捷方法，但最終還是能夠交付。博文中提到了大家提出的一些方案，包括Kero和John Bauer的。你可以查詢到更多的方案，也可以提出你自己的想法。
這樣看來，架構設計和敏捷需要共存。不是有你沒我，而且相互合作。這里的關鍵點就是做“剛剛好”的設計。 Simon 定義了“剛剛好”：
做一個“剛剛好”的架構，可以讓你條理清晰，明確愿景。換句話說，“剛剛好”讓你知道了你的目標是什么，你怎么去完成這個目標。背后的關鍵就是架構是一個重大的決定，而“重大”是由進行改變所需要的成本來衡量的。換而言之，這就是架構，想要修改真的會很貴，而且你真的必須盡早做出正確的決定。舉個例子，質量屬性，比如高性能，高擴展性，高安全性以及高可用性，通常都需要在早期就把這些考慮在基礎框架內，因為想要在后期重新修改現有的基礎代碼庫會很難。這也就是架構，你不可能在某個下午很簡單地就進行重構，比如核心技術選擇、架構模式、核心框架等。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
