无码乱肉视频免费大全合集,亚洲第一A在线观看网站,黄网站色视频免费无风险,免费国产黄网在线观看

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

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

ThoughtWorks架構師Neal Ford

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

未知的未知數(shù)

標簽：杭州網(wǎng)站建設

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

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

關鍵詞：杭州網(wǎng)站制作

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

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

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

設計波譜

標簽：杭州精品網(wǎng)站設計

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

 圖1.設計波譜

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

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

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

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

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

多少預先設計？

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

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

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

不需要進行太多預先設計的項目有：

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

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

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

演化架構與緊急設計系列總結

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

代碼作為設計

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

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

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

接受不確定性

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

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

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

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

收獲慣用模式

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

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

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