英文原文：Agile and Architecture Conflict

　　實(shí)施敏捷方法和設(shè)計(jì)企業(yè)架構(gòu)之間總是存在某種沖突。敏捷開發(fā)強(qiáng)調(diào)隨著對業(yè)務(wù)領(lǐng)域的深入理解，逐步調(diào)整設(shè)計(jì)和計(jì)劃。架構(gòu)設(shè)計(jì)則要求建立起技術(shù)架構(gòu)（technology stack）。它可以滿足質(zhì)量屬性（quality attributes），也可以向感興趣的利益關(guān)系人進(jìn)行展示，作為一種溝通的途徑。當(dāng)使用敏捷方法來引領(lǐng)所需的架構(gòu)設(shè)計(jì)的時(shí)候，兩者強(qiáng)強(qiáng)聯(lián)手將會是雙贏。

　　Tom Graves認(rèn)為敏捷需要一個(gè)脊柱來支撐。而軟件架構(gòu)提供了這個(gè)脊柱。

敏捷通常需要一個(gè)脊柱來指引方向——根據(jù)這個(gè)方向，推動一些工作的進(jìn)行。這樣做，相對于隨意出牌，可以完成更多的工作。通常，這是個(gè)平衡問題——要在堅(jiān)實(shí)的脊柱和敏捷之間有個(gè)良好的平衡。

　　Jan Van Til贊同Tom的觀點(diǎn)，他認(rèn)為沒有后臺的脊柱，前端也很難看得出有多敏捷。

我們當(dāng)然需要一個(gè)相對進(jìn)展“緩慢”的“后臺”，這樣才能讓我們看清我們有多敏捷（“前端”）。如果所有的東西都很時(shí)尚...我們還能從中識別出哪個(gè)是時(shí)尚嗎？我們當(dāng)然需要一個(gè)有點(diǎn)“緩慢”的“后臺”，這樣才能讓我們看清時(shí)尚（“前端”）。換句話說，我們需要傳統(tǒng)的東西，沒有傳統(tǒng)的東西，也就沒有了時(shí)尚。

　　Simon Brown覺得，甚至“絕大部分的敏捷項(xiàng)目”可能都有或大或小的架構(gòu)方面的問題。我們需要在項(xiàng)目早期迭代中解決它們。Simon認(rèn)為，敏捷和架構(gòu)的沖突可以歸結(jié)為是通過短迭代來交付商業(yè)價(jià)值，還是做一個(gè)龐大的預(yù)先設(shè)計(jì)。這里的關(guān)鍵點(diǎn)是設(shè)計(jì)要“剛剛好”（just enough）。準(zhǔn)備好一個(gè)初步的結(jié)構(gòu)是很重要的，但這不意味著就要畫出無數(shù)的詳細(xì)類圖。

　　John Bauer則提到，在對幾個(gè)項(xiàng)目觀察了一段時(shí)間以后，他發(fā)現(xiàn)了一個(gè)有趣的模式。

敏捷以及那些類似敏捷的方法有個(gè)好處，對于產(chǎn)品來說，它能減少那些架構(gòu)設(shè)計(jì)過度的軟件解決方案（over architect-ed software solutions）的產(chǎn)生。架構(gòu)設(shè)計(jì)過度的解決方案會強(qiáng)調(diào)軟件應(yīng)用項(xiàng)目的交付，也會使得軟件開發(fā)和維護(hù)的成本上升，通常來說，是跟交付商業(yè)價(jià)值背道而馳的。

　　James Coplien和Kevlin Henney 給我們介紹了一種從項(xiàng)目開始的時(shí)候就進(jìn)行“剛剛好”的架構(gòu)設(shè)計(jì)，并且確保項(xiàng)目成功的有效方法。

　　但是，這一切在現(xiàn)實(shí)世界里又是怎么實(shí)現(xiàn)的呢？

　　Simon Brown在他的博文中提出了一個(gè)有趣的挑戰(zhàn)：他要求在4個(gè)月左右的時(shí)間內(nèi)，重新開發(fā)一個(gè)程序來取代老邁的在線銀行系統(tǒng) 。他要求大家仍然使用敏捷方法，但最終還是能夠交付。博文中提到了大家提出的一些方案，包括Kero和John Bauer的。你可以查詢到更多的方案，也可以提出你自己的想法。

　　這樣看來，架構(gòu)設(shè)計(jì)和敏捷需要共存。不是有你沒我，而且相互合作。這里的關(guān)鍵點(diǎn)就是做“剛剛好”的設(shè)計(jì)。 Simon 定義了“剛剛好”：

做一個(gè)“剛剛好”的架構(gòu)，可以讓你條理清晰，明確愿景。換句話說，“剛剛好”讓你知道了你的目標(biāo)是什么，你怎么去完成這個(gè)目標(biāo)。背后的關(guān)鍵就是架構(gòu)是一個(gè)重大的決定，而“重大”是由進(jìn)行改變所需要的成本來衡量的。換而言之，這就是架構(gòu)，想要修改真的會很貴，而且你真的必須盡早做出正確的決定。舉個(gè)例子，質(zhì)量屬性，比如高性能，高擴(kuò)展性，高安全性以及高可用性，通常都需要在早期就把這些考慮在基礎(chǔ)框架內(nèi)，因?yàn)橄胍诤笃谥匦滦薷默F(xiàn)有的基礎(chǔ)代碼庫會很難。這也就是架構(gòu)，你不可能在某個(gè)下午很簡單地就進(jìn)行重構(gòu)，比如核心技術(shù)選擇、架構(gòu)模式、核心框架等。

it知識庫：敏捷和架構(gòu)的沖突，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。