成都網(wǎng)站建設(shè)：演化架構(gòu)和緊急設(shè)計經(jīng)驗談

導(dǎo)讀：Neal Ford是全球IT咨詢公司ThoughtWorks的軟件架構(gòu)師。除了常規(guī)工作，他做的事情還包括設(shè)計和開發(fā)應(yīng)用程序、教學(xué)材料、雜志文章、課件和視頻/DVD演示，同時還是各種技術(shù)書籍的作者或者編輯，其中包括最近的新書The Productive Programmer。他專注于設(shè)計和開發(fā)大規(guī)模企業(yè)應(yīng)用程序，同時，他也是世界開發(fā)人員會議的國際知名演說家。關(guān)于他的更多介紹，請查看他的個人站點。

在演化架構(gòu)與緊急設(shè)計系列文章中，Neal Ford通過介紹幫助用戶在演化架構(gòu)和緊急設(shè)計中的靈活實踐，解釋演化架構(gòu)和緊急設(shè)計的基本原則。他還對各種項目緊急設(shè)計的適用性，怎么確定何時制定決策以及與此相關(guān)的一些要點做出了自己的總結(jié)。

ThoughtWorks架構(gòu)師Neal Ford

他在文中開頭引用了美國前國防部長Donald Rumsfeld的詩：世界上有已知的未知，也就是說我們知道我們還不知道的那些事情。但是，還有未知的未知，那些我們不知道我們不知道的事情。

未知的未知數(shù)

標簽：成都網(wǎng)站建設(shè)

Rumsfeld對未知進行區(qū)分，有些知道存在但是人們找不到，但是他也承認還有一些存在是超出人們的知識和經(jīng)驗的，人們甚至不知道要去尋找：這就是“未知的未知”。

Rumsfeld討論的是戰(zhàn)爭的不確定性，但也是在說軟件。如果某人曾編寫過一些重要軟件，可能涉及過未知之未知問題——軟件設(shè)計中大的一個問題。那么大家對解決方案實現(xiàn)過程中所遇到的問題都有一個很好的理解，但是不可避免還是會出現(xiàn)一些不可預(yù)料的問題。同一個開源框架交互不是大家想的那么簡單，問題可能比原來所預(yù)計的更細微，需要更加精細縝密。

關(guān)鍵詞：成都網(wǎng)站制作

不可預(yù)期的設(shè)計問題會不斷出現(xiàn)，因為軟件的容錯能力很低——比物理系統(tǒng)低很多。例如，以大家身邊的建筑物為例，構(gòu)建一個大樓是一個多人數(shù)月（甚至數(shù)年）的項目。現(xiàn)在考慮類似時間段上的一個多人軟件項目。這些項目有類似的規(guī)模，但是物理建筑往往更加寬容結(jié)構(gòu)缺陷。如果一個開關(guān)不能完全掩蓋墻上安裝電線的洞，整個大樓不會倒塌。但是軟件中的一個小問題可能會導(dǎo)致系統(tǒng)崩潰。將其比作原子，位元的容錯都是不可原諒的。當然，軟件易于修復(fù)：大家可以在洞上抹墻粉（修復(fù)bug）立即改造房子。

如果一個機翼脫落了，工程師首先會查看機翼連接的位置：在物理系統(tǒng)上，錯誤和功能的臨近度通常很高。但是在軟件中，執(zhí)行一行可能導(dǎo)致不穩(wěn)定的代碼，通常會使數(shù)百行甚至幾千行似乎不相關(guān)的代碼出現(xiàn)問題。

軟件預(yù)先設(shè)計（Design up front）比較困難，因為各個部分之間以無數(shù)種、甚至不可預(yù)期的方式相互作用。預(yù)測這些交互的實現(xiàn)目前不在能力范圍之內(nèi)，緊急設(shè)計包含這些不可避免的令人驚訝的復(fù)雜性，試著減少變化的破壞。

設(shè)計波譜

標簽：成都精品網(wǎng)站設(shè)計

緊急設(shè)計不是一個二元狀態(tài)。不能肯定地說某人的設(shè)計是100％敏捷的或是0敏捷的；有圖1所示的這樣一個波譜：

圖1.設(shè)計波譜

在圖1的最左邊，有傳統(tǒng)的Big Design Up Front（BDUF），具體反映在很多常見開發(fā)技術(shù)中。BDUF以其優(yōu)秀的稻草人（straw-man）形式體現(xiàn)了象牙塔架構(gòu)，創(chuàng)建設(shè)計工件，不作任何更改直接交給開發(fā)人員來進行實現(xiàn)。在nonparody格式中，該設(shè)計方法努力嘗試在編碼之前找出所感興趣的一切。這是一個預(yù)測模型，設(shè)計軟件的預(yù)測模型。

圖1右邊顯示了某人在中學(xué)時期所做的各種編碼：可以進行修改使之運行，然后繼續(xù)改進。這在小范圍內(nèi)可以很好地運行（基本上，只要這個問題小到用腦子想想就可以解決），但是不能超出太多。

緊急設(shè)計通常在兩個極端情況下失效，但是和左邊比起來更趨向于右邊。緊急設(shè)計是一個響應(yīng)式的、被動的軟件設(shè)計方法。

面對這么多的失敗和不被看好的項目，還有這么多組織機構(gòu)繼續(xù)使用BDUF，真的很令人費解！并不是說某人不能成功地使用BDUF。（事實上，他曾做過很多這類項目。）但是數(shù)十年間關(guān)于這個開發(fā)技術(shù)的記錄很少。Fred Brooks的重要著作Mythical Man Month探討了以該模式構(gòu)建軟件存在的問題，于1975年發(fā)布（見參考資料）。

團隊想使用這種風(fēng)格進行開發(fā)并不奇怪，因為這更符合設(shè)計在傳統(tǒng)工程中的工作方式。如果開發(fā)者正在設(shè)計小部件或iPods，必須進行所有的預(yù)先設(shè)計，因為開發(fā)者不能重構(gòu)原子?？纯丛嫉腎ntel Pentium處理器。在它發(fā)布之后，在浮點數(shù)據(jù)單元中發(fā)現(xiàn)了一個bug，需要每個操作系統(tǒng)創(chuàng)建者來編寫特定代碼解決這個問題。一旦操作完成，就不能對硬件進行更改。軟件截然相反：軟件項目的多數(shù)生命周期是在原始版本發(fā)布之后發(fā)生，通過增強、bug修復(fù)、以及其他“維護”活動。開發(fā)者處理位元而不是原子，位元的可塑性是無限的。

多少預(yù)先設(shè)計？

敏捷設(shè)計并不是要在項目開始階段忽略設(shè)計。對問題的本質(zhì)知道得越少，在此過程的早期所能做的就越少。他常常會問，“如何決定在一個項目開始階段進行多少設(shè)計合適？”不同項目有不同的準則，它們在種類和復(fù)雜程度上的變化比多數(shù)非技術(shù)人員所意識到的要多很多。大致上說，需要平衡兩件事：如果開發(fā)者的早期決策足夠精準可以避免日后進行更改，那么要考慮預(yù)先設(shè)計。如果后期修改成本太大，就要考慮收益問題。因此，需要對早期階段以及開發(fā)技術(shù)（可能會是后期更改代價昂貴）有一個很好的了解。敏捷設(shè)計反對這個觀點，因為人們傾向于過高地估計他們在早期制定精確決策的能力，因而他們將遭受不斷擴大的后果。

這里是一些項目示例，了解一下開發(fā)者應(yīng)該為哪些項目做更多的預(yù)先設(shè)計：

有嚴格的穩(wěn)定性需求，數(shù)年之內(nèi)沒有更改計劃的項目。高度隔離的環(huán)境（比如太空傲游，水底探險），出于安全性考慮的項目。所編寫的項目與之前的軟件完全相同、同一組人、沒有范圍變化。（對該項目有一個極度精確的評估。）對環(huán)境高度約束的項目，比如，嵌入式系統(tǒng)，確保考慮到了環(huán)境約束條件。（他仍然會盡量使行為功能性盡可能多地出現(xiàn)。）

不需要進行太多預(yù)先設(shè)計的項目有：

有高度可變性、項目需求不斷變化的項目（幾個月或幾周），像多數(shù)商業(yè)應(yīng)用程序。需要響應(yīng)外部因素（比如，市場條件）的項目。還不能確定技術(shù)或業(yè)務(wù)細節(jié)的項目，注意這實際上包括每個項目，又回到Rumsfeld的“未知之未知”理論上了。從訂閱到部署都可以從中收益的項目，而不是那些人為地區(qū)分為“已完成的”項目。沒有軟件項目是徹底完成的，因此開發(fā)者總是需要購買一個訂閱，越早認識到這一點，就表現(xiàn)的越像。

選擇正確的時間制定決策比較困難，但很重要。所有項目都是獨一無二的，給出具體建議無用。但是，這有一些通用的指導(dǎo)方針：

注意當“最簡單的工作”已經(jīng)工作一段時間之后，需要解決的問題變得更重要更復(fù)雜，例如，假設(shè)開發(fā)者正在使用一個數(shù)據(jù)庫作為基礎(chǔ)后臺、異步活動的一個簡單消息傳遞隊列。然而現(xiàn)在，在性能變差的同時將兩個新需求添加到各種異步活動中了?，F(xiàn)在是重新訪問“最簡單事情”決策的時間，因為解決方案不能匹配該準則。在查看問題的整體規(guī)模時，試著隔離將趨向緊急設(shè)計技術(shù)的數(shù)據(jù)包。例如，假設(shè)開發(fā)者正在處理一個需要地理編碼支持的應(yīng)用程序，開發(fā)者不可能在此之前就使用一個地理編碼庫。應(yīng)該執(zhí)行一些spikes（簡單直接的研究與開發(fā)項目）來確?？梢岳斫庠u估目的。盡量避免在不完全理解的基礎(chǔ)上制定架構(gòu)決策（后期很難改變），重新訪問應(yīng)用程序其余部分和這個隔離部分之間的接口點，看看是否能在更好理解的基礎(chǔ)上進行改進。試著保留應(yīng)用程序之間的交互作用點。Simple Object Access Protocol (SOAP) 這類協(xié)議的一個副作用是在剛性結(jié)構(gòu)和強類型（strong types）上的持久性。靈活性的秘密是特異性少，這種認識推進了Representational State Transfer (REST)和相關(guān)技術(shù)的廣泛應(yīng)用。構(gòu)建一個API時，試著接受最通用的合理性，這也將應(yīng)用于集成。

演化架構(gòu)與緊急設(shè)計系列總結(jié)

他將對這18期中的主要主題做出了總結(jié)：

代碼作為設(shè)計

回到“演化架構(gòu)和緊急設(shè)計：利用可重用代碼，第1部分”，他引用Jack Reeves的這篇文章，他認為軟件設(shè)計是由一個項目的全部源代碼構(gòu)成，而不僅僅是開發(fā)者通常所認為的工件（白板圖（white-board diagrams）、Unified Modeling Language，等等）。他將源代碼和工程的規(guī)劃進行了比較，工程師的規(guī)劃指出了生產(chǎn)團隊將設(shè)計轉(zhuǎn)換成原子所需的一切。開發(fā)者的規(guī)劃是源代碼，編輯器將其轉(zhuǎn)換成位元。如果對代碼進行設(shè)計，那么所用的計算機語言和架構(gòu)就定義了開發(fā)者可以設(shè)計的原始資料。

功能強大的語言的影響優(yōu)勢抵消了對其先進功能的恐懼。盡管選擇和標準化有10多年歷史的語言很不錯，因為有足夠充足的低成本開發(fā)人員，但是必須接受這個事實，不能趕上競爭對手，因為他們有更現(xiàn)代的語言和工具。很多機構(gòu)過分強調(diào)標準化，甚至以創(chuàng)新和穩(wěn)鍵為代價。他曾見過很多被迫使用標準框架的項目，這很可笑也不利于問題發(fā)現(xiàn)，這會妨礙任何類型的設(shè)計問題發(fā)現(xiàn)，因為會被意外噪音所干擾。

這并不意味著就允許每個開發(fā)人員都選擇使用自己的工具堆棧。這意味著開發(fā)者要密切關(guān)注標準化所提供的真正價值，然后考慮合理方案。例如，或許開發(fā)者想繼續(xù)使用Java技術(shù)開發(fā)項目，可以使用更高級的工具進行構(gòu)建、測試和其他開發(fā)任務(wù)。軟件項目中代碼似乎無處不在，這一切都體現(xiàn)在設(shè)計中，不管是有意識還是無意識的。

接受不確定性

許多方法都想要避免不確定性。如果開發(fā)者使用原子方式進行構(gòu)建，不確定性很糟糕，因為一旦原子被強制形成一定形狀再更改其配置代價極為昂貴。但是，如果使用位元進行構(gòu)建，更改十分容易且十分必要。在軟件中避免更改很困難且沒有必要。

敏捷方法想要找到一種方法使得修改更為容易，使用諸如單元測試、重構(gòu)、持續(xù)集成和交互開發(fā)之類技術(shù)。緊急設(shè)計體現(xiàn)在設(shè)計的敏捷哲學(xué)中，當出現(xiàn)設(shè)計決策時，問自己：

現(xiàn)在需要制定這個決策嗎？可以安全地推遲這一決策嗎？能做些什么使決策可逆？

如果開發(fā)者是在這樣一個易于重構(gòu)代碼的環(huán)境中，臨時制定一個非決策并不可怕，因為可以輕松地進行修復(fù)。如果設(shè)置項目以適應(yīng)變化，推遲決策不會發(fā)生故障，因為可以實時優(yōu)化。接受修改需要有能力客觀對待決策以及更改那些使事情糟糕的決策。

收獲慣用模式

緊急設(shè)計的另一方面是能夠看見代碼中的有用設(shè)計元素，然后作為慣用模式進行保存，這是他在“演化架構(gòu)和緊急設(shè)計：利用可重用代碼，第1部分”中作為已有問題的有效解決方案定義的。這些已發(fā)現(xiàn)模式就像是某公司皇冠上的珠寶，因為它們是實現(xiàn)公司運行方式的設(shè)計元素。令人擔憂的是，開發(fā)者所編寫的少量代碼囊括了惟一值：余下的大部分只是拖放到數(shù)據(jù)庫、構(gòu)建HTML，等等。慣用模式比在Joint Application Design(JAD)或象牙塔設(shè)計中編造的模式要更有價值，因為它們已經(jīng)達到了實用的關(guān)鍵條件之一：它們已經(jīng)被用來解決了一個實際問題。

開發(fā)者可以通過各種方法收獲慣用模式?？梢詣?chuàng)建一個API，這只是很簡單并沒有什么特別的—看起來和所使用的其他API沒什么兩樣。也可以捕獲一些使用元程序和屬性的慣用模式（見“演化架構(gòu)和緊急設(shè)計：利用可重用代碼，第2部分”）。在“演化架構(gòu)和緊急設(shè)計：使用DSL”、“演化架構(gòu)和緊急設(shè)計：連貫接口”、“演化架構(gòu)和緊急設(shè)計：使用Groovy構(gòu)建DSL”和“演化架構(gòu)和緊急設(shè)計：使用JRuby構(gòu)建DSL”中，他也討論了使用特定域語言捕獲慣用模式。

總是想要識別有用設(shè)計元素，避免制定人工難以執(zhí)行的決策。例如，當這些元素被添加到代碼基中，在沒有使用它們時向應(yīng)用程序（比如，可擴展層或面向服務(wù)架構(gòu)的服務(wù)）中添加架構(gòu)元素使代碼更為復(fù)雜。務(wù)必確保在正確的時間添加復(fù)雜性，因為在使用它之前，它都是偶發(fā)復(fù)雜性。

分享文章：成都網(wǎng)站建設(shè)：演化架構(gòu)和緊急設(shè)計經(jīng)驗談
分享路徑：http://www.muchs.cn/news17/184067.html

網(wǎng)站建設(shè)、網(wǎng)絡(luò)推廣公司-創(chuàng)新互聯(lián)，是專注品牌與效果的網(wǎng)站制作，網(wǎng)絡(luò)營銷seo公司；服務(wù)項目有網(wǎng)站建設(shè)等

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)