演進(jìn)式架構(gòu).jpg

演進(jìn)式架構(gòu)

第1章 軟件架構(gòu)

1. 向高度動(dòng)態(tài)的（生態(tài)）系統(tǒng)中引入變化，可能會(huì)產(chǎn)生無(wú)法預(yù)料的結(jié)果。P3
2. 軟件開發(fā)體系由所有工具、框架、庫(kù)以及最佳實(shí)踐（軟件開發(fā)領(lǐng)域的技術(shù)積累）構(gòu)成。和生態(tài)一樣，軟件開發(fā)體系實(shí)現(xiàn)了平衡，開發(fā)人員能夠理解這個(gè)體系并未其添磚加瓦。然后，這種平衡是動(dòng)態(tài)的，隨著新事物的不斷出現(xiàn)，平衡不斷被打破和重建。P3
3. 有一種不幸的退化叫做架構(gòu)比特衰減。架構(gòu)師選擇特定的架構(gòu)模式來(lái)滿足也無(wú)需求及讓系統(tǒng)具備某些能力，但這些特征常常意外地隨著時(shí)間推移而退化。P4
4. 定義了那些重要的架構(gòu)特征后，架構(gòu)師如何保護(hù)這些特征不磨損呢？答案是添加演進(jìn)呢你作為新的架構(gòu)特征，使其在系統(tǒng)演進(jìn)時(shí)保護(hù)其他特征。P5
5. 持續(xù)架構(gòu)值構(gòu)建架構(gòu)的過(guò)程沒(méi)有最終狀態(tài)，它會(huì)隨著軟件開發(fā)體系的不斷變化而演進(jìn)，并保護(hù)重要的架構(gòu)特征。我們不會(huì)嘗試定義整個(gè)軟件架構(gòu)，因?yàn)橐呀?jīng)存在很多定義了。我們通過(guò)引入時(shí)間和變化作為頭等架構(gòu)元素來(lái)擴(kuò)展當(dāng)前的定義。P5
6. 增量變更描述了軟件架構(gòu)的兩個(gè)方面：如何增量地構(gòu)建軟件和如何部署軟件。P5
7. 適應(yīng)度函數(shù)，該函數(shù)是一種目標(biāo)函數(shù)，用于計(jì)算潛在的解決方案與既定目標(biāo)的差距。在演化計(jì)算中，適應(yīng)度函數(shù)決定一個(gè)算法是否在持續(xù)提升。換句話說(shuō)，隨著每個(gè)算法變體的產(chǎn)生，基于設(shè)計(jì)者對(duì)算法“適應(yīng)度”的定義，適應(yīng)度決定每個(gè)變體的“適應(yīng)程度”。P6
8. 對(duì)于演進(jìn)式架構(gòu)，隨著架構(gòu)的演進(jìn)，我們有著類似的需求。我們需要評(píng)估機(jī)制，來(lái)評(píng)估變化對(duì)架構(gòu)重要特征的影響，并防止這些特征隨著時(shí)間的推移而退化。適應(yīng)度函數(shù)的隱喻涵蓋多種機(jī)制，包括度量、測(cè)試和其他驗(yàn)證工具。我們采用這些機(jī)制來(lái)確保架構(gòu)不會(huì)以不良方式變更。當(dāng)架構(gòu)師確定了需要保護(hù)的架構(gòu)特征時(shí)，他們會(huì)定義一個(gè)或多個(gè)適應(yīng)度函數(shù)來(lái)提供保護(hù)。P6
9. 康威提出：社會(huì)結(jié)構(gòu)，特別是人與人之間的溝通途徑，將不可避免地影響最終的產(chǎn)品設(shè)計(jì)。P8
10. 持續(xù)式、敏捷式和應(yīng)急式都表達(dá)了隨時(shí)間不斷變化的概念，這確實(shí)是演進(jìn)式架構(gòu)的關(guān)鍵特征，但是這些術(shù)語(yǔ)都沒(méi)能準(zhǔn)確地表達(dá)出架構(gòu)將如何變化，或者說(shuō)期望的架構(gòu)最終是什么樣子的。雖然這些術(shù)語(yǔ)都隱含著環(huán)境變化，但是都沒(méi)能涵蓋架構(gòu)應(yīng)有的樣子。而在演進(jìn)式架構(gòu)的定義中，引導(dǎo)的含義反映了我們想實(shí)現(xiàn)的架構(gòu)，即我們的最終目標(biāo)。P10
11. 演進(jìn)式架構(gòu)主要由三方面構(gòu)成：增量變化、適應(yīng)度函數(shù)和適當(dāng)?shù)鸟詈稀11

第2章 適應(yīng)度函數(shù)

1. 演進(jìn)式架構(gòu)是支持跨多個(gè)維度進(jìn)行引導(dǎo)性增量變更的架構(gòu)。P13
2. 引導(dǎo)性這個(gè)詞表示架構(gòu)應(yīng)該朝著某個(gè)目標(biāo)變更或者體現(xiàn)目標(biāo)。本書借用了進(jìn)化計(jì)算中的一個(gè)概念——適應(yīng)度函數(shù)，遺傳算法設(shè)計(jì)用它定義成功。進(jìn)化計(jì)算有多種機(jī)制，通過(guò)對(duì)每一代軟件進(jìn)行小的變更使方案逐漸成形。工程師會(huì)評(píng)估每一代解決方案的當(dāng)前狀態(tài)，來(lái)判斷當(dāng)前方案與最終目標(biāo)的舉例。P13
3. 架構(gòu)的適應(yīng)度函數(shù)為某些架構(gòu)特征提供了客觀的完整性評(píng)估。P13
4. 我們也可以將全系統(tǒng)適應(yīng)度函數(shù)看作適應(yīng)度函數(shù)的集合，其中每個(gè)適應(yīng)度函數(shù)對(duì)應(yīng)架構(gòu)的一個(gè)或多個(gè)維度。當(dāng)適應(yīng)度函數(shù)所對(duì)應(yīng)的維度間存在沖突是，使用全系統(tǒng)適應(yīng)度函數(shù)有助于我們做出必要的權(quán)衡。P13
5. 系統(tǒng)絕不是其組成部分的總和，而是各部分相互作用的產(chǎn)物。P14
6. 原子適應(yīng)度函數(shù)對(duì)單一的上下文執(zhí)行，用來(lái)校驗(yàn)架構(gòu)的某一維度，比如某個(gè)用來(lái)驗(yàn)證模塊間耦合的單元測(cè)試。P16
7. 整體適應(yīng)度函數(shù)在共享的上下文中運(yùn)行，綜合校驗(yàn)架構(gòu)的多個(gè)維度，比如安全性和伸縮性。P16
8. 適應(yīng)度函數(shù)間的另一個(gè)區(qū)別是執(zhí)行頻率。觸發(fā)式適應(yīng)度函數(shù)基于特定的事件執(zhí)行，比如開發(fā)人員執(zhí)行單元測(cè)試、部署流水線執(zhí)行單元測(cè)試或質(zhì)量保障人員執(zhí)行探索性測(cè)試。16
9. 持續(xù)式測(cè)試不是按計(jì)劃執(zhí)行，而是持續(xù)不斷地驗(yàn)證架構(gòu)的某些方面，比如事務(wù)處理速度。P17
10. 靜態(tài)適應(yīng)度函數(shù)的結(jié)果是固定的，比如單元測(cè)試的二進(jìn)制結(jié)果——成功或失敗。P18
11. 動(dòng)態(tài)適應(yīng)度函數(shù)依賴基于額外上下文變化的因素。某些值會(huì)視具體情況而定，比如在大規(guī)模運(yùn)行的情況下，大多數(shù)架構(gòu)師會(huì)采用較低的性能指標(biāo)。P17
12. 團(tuán)隊(duì)?wèi)?yīng)該盡早確定適應(yīng)度函數(shù)，將其作為初步理解全局架構(gòu)關(guān)注點(diǎn)的一部分。團(tuán)隊(duì)還應(yīng)該盡早確定系統(tǒng)適應(yīng)度函數(shù)，來(lái)幫助他們確定想實(shí)現(xiàn)的變更。比較實(shí)現(xiàn)不同架構(gòu)特征的價(jià)值和難度，有助于更早地設(shè)置高風(fēng)險(xiǎn)工作的優(yōu)先級(jí)，從而做出能夠應(yīng)對(duì)變化的設(shè)計(jì)。P18
13. 沒(méi)能確定適應(yīng)度函數(shù)的團(tuán)隊(duì)講面臨如下風(fēng)險(xiǎn)：P18
    • 做出錯(cuò)誤的設(shè)計(jì)選型，最終導(dǎo)致軟件構(gòu)建失敗。
    • 做出的設(shè)計(jì)選型在時(shí)間和成本上出現(xiàn)不必要的浪費(fèi)。
    • 系統(tǒng)無(wú)法輕松應(yīng)對(duì)日后的環(huán)境變化。

第3章 實(shí)施增量變更

1. 演進(jìn)式架構(gòu)的定義暗含了增量變更，這意味著這種架構(gòu)更容易實(shí)現(xiàn)小的增量變更。P21
2. 持續(xù)交付描述了部署流水線機(jī)制。和持續(xù)集成服務(wù)器類似，部署流水線在“監(jiān)聽(tīng)”到變化后執(zhí)行一些列驗(yàn)證步驟，每一步都更加復(fù)雜。持續(xù)交付實(shí)踐鼓勵(lì)使用部署流水線將常規(guī)項(xiàng)目任務(wù)自動(dòng)化，例如測(cè)試、服務(wù)器準(zhǔn)備和部署等。P26
3. 將項(xiàng)目的架構(gòu)關(guān)注點(diǎn)（包括演進(jìn)能力）轉(zhuǎn)換為適應(yīng)度函數(shù)能帶來(lái)很多好處。P30
   • 適應(yīng)度函數(shù)的結(jié)果客觀且可量化。
   • 捕捉所有關(guān)注點(diǎn)作為適應(yīng)度函數(shù)，創(chuàng)造了一致的執(zhí)行機(jī)制。
   • 適應(yīng)度函數(shù)列表便于開發(fā)人員設(shè)計(jì)部署流水線。

第4章 架構(gòu)耦合

1. 演進(jìn)式架構(gòu)注重適當(dāng)?shù)鸟詈?，即如何確定哪些架構(gòu)維度間應(yīng)該相互耦合來(lái)以最小的開銷和成本最大程度地獲益。P39
2. 架構(gòu)量子則是具有高功能內(nèi)聚并可以獨(dú)立部署的組件，它包括了支持系統(tǒng)正常工作的所有結(jié)構(gòu)性元素。在單體架構(gòu)中，量子就是整個(gè)應(yīng)用架構(gòu)，每個(gè)部署都高度耦合，因此開發(fā)人員必須對(duì)其進(jìn)行整體部署。相比之下，微服務(wù)架構(gòu)在架構(gòu)元素之間定義了物理限界上下文，封裝了所有可能變化的部分。這種架構(gòu)就是為了增量變更而設(shè)計(jì)的。在微服務(wù)架構(gòu)中，限界上下文作為量子邊界，包含了服務(wù)所依賴的組件。P40
3. 分層架構(gòu)的主要涉及準(zhǔn)則是將不同的技術(shù)能力分隔到不同的層，每層職責(zé)各異。這種架構(gòu)的主要優(yōu)點(diǎn)是關(guān)注點(diǎn)獨(dú)立且分離。每一層相對(duì)于其它層都是獨(dú)立的，但能通過(guò)明確定義的接口互相訪問(wèn)。這使得對(duì)某一層的變更不會(huì)影響其他層，同時(shí)將相似的代碼組織到一起，為該層的專業(yè)化和分離提供了空間。P45
4. 微核架構(gòu)定義了一個(gè)核心系統(tǒng)，核心系統(tǒng)對(duì)外提供API來(lái)通過(guò)插件豐富其功能。在這種架構(gòu)中架構(gòu)量子大小有兩種：一種來(lái)自核心系統(tǒng)，另一種來(lái)自插件。P48
5. 微服務(wù)架構(gòu)通常遵循以下七個(gè)原則：P57
   • 圍繞業(yè)務(wù)領(lǐng)域建模：微服務(wù)設(shè)計(jì)的重點(diǎn)是基于業(yè)務(wù)領(lǐng)域，而不是基于技術(shù)架構(gòu)。因此架構(gòu)量子反映了限界上下文。一些開發(fā)人員錯(cuò)誤地認(rèn)為限界上下代表某個(gè)單獨(dú)的實(shí)體，例如客戶。相反，它代表某個(gè)業(yè)務(wù)上下文或工作流，例如商品結(jié)賬。微服務(wù)的目標(biāo)是創(chuàng)建有用的限界上下文，而不是讓開發(fā)人員構(gòu)建更小的服務(wù)。
   • 隱藏實(shí)現(xiàn)細(xì)節(jié)：微服務(wù)的技術(shù)架構(gòu)封裝在基于業(yè)務(wù)領(lǐng)域的服務(wù)邊界中。每個(gè)領(lǐng)域形成一個(gè)物理限界上下文。服務(wù)間通過(guò)傳遞消息或資源來(lái)集成，而不是通過(guò)暴露實(shí)現(xiàn)細(xì)節(jié)集成，例如數(shù)據(jù)庫(kù)模式。
   • 自動(dòng)化文化：微服務(wù)架構(gòu)支持持續(xù)交付，它使用部署流水線嚴(yán)格地測(cè)試代碼，并將一些任務(wù)自動(dòng)化。
   • 高度去中心化：微服務(wù)形成了一種無(wú)共享架構(gòu)，其目標(biāo)是盡可能地減少耦合。
   • 獨(dú)立部署：開發(fā)人員和運(yùn)維人員希望可以獨(dú)立部署每個(gè)服務(wù)，反映了服務(wù)間的物理限界上下文。
   • 隔離失敗：每個(gè)服務(wù)都應(yīng)該處理合理的錯(cuò)誤場(chǎng)景并在可能的情況下將其恢復(fù)。很多DevOps的最佳實(shí)踐通常在這種架構(gòu)中出現(xiàn)，例如熔斷器模式、艙壁模式等。
   • 高度可觀察：在微服務(wù)架構(gòu)中監(jiān)控和日志成立首要問(wèn)題。如果運(yùn)維人員無(wú)法監(jiān)控某個(gè)服務(wù)，那么它相當(dāng)于不存在了。
6. 微服務(wù)的主要目標(biāo)是通過(guò)物理限界上下文來(lái)隔離領(lǐng)域及理解問(wèn)題領(lǐng)域。P58
7. 架構(gòu)師通常將微服務(wù)成為“無(wú)共享”架構(gòu)。這種架構(gòu)的主要優(yōu)勢(shì)是在技術(shù)架構(gòu)層面完全解耦。但是對(duì)耦合不滿的人通常會(huì)提到“不當(dāng)?shù)鸟詈稀?。畢竟，一個(gè)沒(méi)有耦合的軟件系統(tǒng)也強(qiáng)不到哪里去。這里的“無(wú)共享”實(shí)際上是指“沒(méi)有混亂的耦合點(diǎn)”。P59
8. 雖然FaaS（功能即服務(wù)）能處理彈性的水平擴(kuò)展，但是調(diào)用方必須處理所有的事務(wù)行為和其他復(fù)雜的協(xié)調(diào)工作。在傳統(tǒng)應(yīng)用中，通常由后端處理事務(wù)協(xié)調(diào)。然后如果BaaS（后端即服務(wù)）不支持該行為，那么協(xié)調(diào)工作就必然回轉(zhuǎn)嫁給用戶接口（服務(wù)請(qǐng)求者）。P63
9. 架構(gòu)演進(jìn)的結(jié)構(gòu)限制取決于開發(fā)人員處理耦合和功能內(nèi)聚的水平。P64

第5章 演進(jìn)式數(shù)據(jù)

1. 當(dāng)耦合的應(yīng)用需要通過(guò)數(shù)據(jù)庫(kù)模式變更來(lái)演進(jìn)時(shí)會(huì)發(fā)生什么？如果應(yīng)用A修改了護(hù)具庫(kù)模式，可能破壞其他兩個(gè)應(yīng)用。幸運(yùn)的是，正如《數(shù)據(jù)庫(kù)重構(gòu)》一書所討論的，常用擴(kuò)展/收縮重構(gòu)模式來(lái)化解這種耦合。P70

第6章 構(gòu)建可演進(jìn)的架構(gòu)

1. 賦予現(xiàn)有架構(gòu)演進(jìn)能力取決于三個(gè)因素：組件耦合度、工程實(shí)踐成熟度，以及開發(fā)人員構(gòu)建適應(yīng)度函數(shù)的難易程度。P81
2. 架構(gòu)師無(wú)法對(duì)“元工作比工作更有趣”綜合征免疫，這種綜合征變現(xiàn)為采用時(shí)髦但并不合適的架構(gòu)，例如微服務(wù)。P84
3. 團(tuán)隊(duì)可以通過(guò)多種劃分方式將單體應(yīng)用分解成服務(wù)：P85
   • 業(yè)務(wù)功能分組：企業(yè)可能有清晰的業(yè)務(wù)劃分直接對(duì)應(yīng)與IT能力。模仿當(dāng)前業(yè)務(wù)溝通等級(jí)構(gòu)建的軟件無(wú)疑應(yīng)驗(yàn)了康威定律。
   • 事務(wù)邊界：許多業(yè)務(wù)需要依附于大量事務(wù)邊界。當(dāng)分解單體應(yīng)用時(shí)，架構(gòu)師經(jīng)常發(fā)現(xiàn)事務(wù)耦合是最難解開的。
   • 部署目標(biāo)：增量變更使得開發(fā)人員可以按照不同的計(jì)劃有選擇地發(fā)布代碼。
4. 計(jì)算機(jī)科學(xué)領(lǐng)域的任何問(wèn)題都可以通過(guò)增加一個(gè)間接的中間層來(lái)解決，除非該問(wèn)題是由間接層太多導(dǎo)致的。P88
5. 開發(fā)人員熟悉工具的好處，缺忽視所要做出的權(quán)衡。P93
6. 服務(wù)模板是保證一致性的常見(jiàn)方案。其中包含一系列預(yù)配置的公共基礎(chǔ)設(shè)施庫(kù)，例如服務(wù)發(fā)現(xiàn)、監(jiān)控、日志、度量、認(rèn)證/授權(quán)等。
7. 可犧牲架構(gòu)的定義是：在概念驗(yàn)證成功后即被拋棄的架構(gòu)。因此，在管理上，不應(yīng)該詢問(wèn)是否該構(gòu)件一個(gè)試驗(yàn)型的系統(tǒng)然后將其拋棄。因?yàn)槟阋欢〞?huì)那樣做。因?此，做好拋棄它的計(jì)劃，因?yàn)槟憬K將如此。P94
8. 在Fred Brooks提到第二系統(tǒng)綜合征時(shí)，他指出技術(shù)債會(huì)影響很多在初期很成功的項(xiàng)目。由于期望膨脹，小的、優(yōu)雅的、成功的系統(tǒng)往往會(huì)演進(jìn)成為塞滿各種功能的龐然大物。業(yè)務(wù)人員不愿拋棄還在運(yùn)行的代碼，因此架構(gòu)走向了一直做加法，但從不做減法的不歸路。P95

第7章 演進(jìn)式架構(gòu)的陷阱和反模式

1. 反模式：供應(yīng)商為王反模式。一種完全圍繞供應(yīng)商產(chǎn)品構(gòu)建的架構(gòu)，將組織和工具病態(tài)地耦合。購(gòu)買了供應(yīng)商軟件的公司計(jì)劃通過(guò)插件擴(kuò)充軟件包，以豐富供應(yīng)商軟件的核心功能來(lái)匹配其業(yè)務(wù)。然而，很多時(shí)候無(wú)法將ERP定制到滿足所有需求，開發(fā)人員發(fā)現(xiàn)他們受到了ERP的制約。P103
2. 與其淪為供應(yīng)商為王反模式的受害者，我們不如將供應(yīng)商產(chǎn)品視為集成點(diǎn)。開發(fā)人員可以在集成點(diǎn)間構(gòu)建防腐層，從而避免架構(gòu)受到供應(yīng)商工具變更的影響。p104
3. 復(fù)用軟件更像是器官移植而不是拼裝樂(lè)高積木。P108
4. 代碼復(fù)用性越高，其可用性越低。換句話說(shuō)，代碼的易用性和復(fù)用性往往成反比。當(dāng)開發(fā)人員構(gòu)建可復(fù)用的代碼時(shí)，他們必然會(huì)為了將來(lái)開發(fā)人員以各種方式使用該代碼添加特性。所有針對(duì)未來(lái)的特性都使得開發(fā)人員更難將代碼用于單一目的。P109
5. 微服務(wù)避免代碼復(fù)用，遵循重復(fù)優(yōu)于耦合的理念。該理念認(rèn)為復(fù)用意味著耦合，因此微服務(wù)架構(gòu)是極度解耦的。然后微服務(wù)的目標(biāo)并不是追求沖否，而是隔離領(lǐng)域內(nèi)的實(shí)體。那些共享通用類的服務(wù)不再獨(dú)立。在微服務(wù)架構(gòu)中，Checkout和Shipping應(yīng)該各自擁有其Customer的內(nèi)部呈現(xiàn)。復(fù)用所帶來(lái)的好處是虛幻的，除了其自身缺陷，它還會(huì)引入耦合。因此，雖然架構(gòu)師了解重復(fù)的缺點(diǎn)，但他們利用重復(fù)抵消了耦合過(guò)多對(duì)架構(gòu)的局部損害。P109
6. 當(dāng)耦合點(diǎn)妨礙了演進(jìn)或其他重要的架構(gòu)特征時(shí)，通過(guò)分叉或重復(fù)來(lái)打破耦合點(diǎn)。P110
7. 不要為了架構(gòu)而構(gòu)建架構(gòu)，構(gòu)建架構(gòu)是為了解決問(wèn)題。P110
8. 幾十年來(lái)，編寫軟件的目標(biāo)沒(méi)有考慮敏捷性，而是圍繞著降低成本、共享資源和其他一些外部約束。因此，很多組織缺乏能夠支持演進(jìn)式架構(gòu)的基礎(chǔ)。P111
9. 更快的生產(chǎn)周期意味著架構(gòu)可以更快地演進(jìn)。因此一個(gè)項(xiàng)目的生產(chǎn)周期決定了架構(gòu)的研究速度。換句話說(shuō)，演進(jìn)速度和生產(chǎn)周期成正比。P113

第8章 實(shí)踐演進(jìn)式架構(gòu)

1. 全功能團(tuán)隊(duì)的目標(biāo)之一便是消除協(xié)調(diào)摩擦。創(chuàng)痛的團(tuán)隊(duì)彼此獨(dú)立，開發(fā)人員通常需要等DBA做出變更或運(yùn)維人員提供資源。同一個(gè)團(tuán)隊(duì)包含各種角色能消除不同團(tuán)隊(duì)協(xié)調(diào)所產(chǎn)生的偶然摩擦。P120
2. 按照業(yè)務(wù)能力而非職能來(lái)組織團(tuán)隊(duì)。P121
3. 亞馬遜的“兩個(gè)披薩團(tuán)隊(duì)”模仿了靈長(zhǎng)類動(dòng)物群體的行為。P122
4. 團(tuán)隊(duì)成員間的連接數(shù)n(n-1)/2，構(gòu)建小型團(tuán)隊(duì)是為了減少溝通連接。并且，為了消除不同團(tuán)隊(duì)間協(xié)作所產(chǎn)生的認(rèn)為摩擦，這些小型團(tuán)隊(duì)需要是全功能團(tuán)隊(duì)。P124
5. 文化：特定人群和社會(huì)的想法、習(xí)俗及社會(huì)行為。P124
6. 架構(gòu)師能通過(guò)提以下問(wèn)題了解團(tuán)隊(duì)的工程文化：P124
   • 是否團(tuán)隊(duì)所有人都知道什么是適應(yīng)度函數(shù)，并考慮了解新工具或產(chǎn)品選型對(duì)演進(jìn)新適應(yīng)度函數(shù)的影響？
   • 團(tuán)隊(duì)是否衡量了系統(tǒng)與所定義的適應(yīng)度函數(shù)的匹配程度？
   • 工程師是否理解內(nèi)聚和耦合？
   • 是否討論了什么領(lǐng)域和技術(shù)概念該整合到一起？
   • 團(tuán)隊(duì)是基于變更能力還是基于他們想學(xué)習(xí)的技術(shù)來(lái)選擇解決方案的？
   • 團(tuán)隊(duì)對(duì)業(yè)務(wù)變更如何做出反應(yīng)？他們是否難于完成小的變更，或在小的業(yè)務(wù)變更上花費(fèi)了太多時(shí)間？
7. 試驗(yàn)文化：成功的演進(jìn)離不開試驗(yàn)，但有些公司因?yàn)槊τ诮桓抖鵁o(wú)暇進(jìn)行試驗(yàn)。成功的試驗(yàn)是經(jīng)常進(jìn)行一些小型活動(dòng)來(lái)嘗試新的想法并將成功的試驗(yàn)集成到現(xiàn)有系統(tǒng)中。P125
   • 衡量成功的真正標(biāo)準(zhǔn)是在24小時(shí)內(nèi)能完成的試驗(yàn)數(shù)量。
8. 組織可以通過(guò)如下幾種方式鼓勵(lì)試驗(yàn)：P126
   • 從外部吸收想法：很多公司派員工參加展會(huì)，并鼓勵(lì)他們尋求新的技術(shù)、工具和能更好地解決問(wèn)題的方法。還有公司將外部建議或顧問(wèn)作為新想法的來(lái)源。
   • 鼓勵(lì)明確的改進(jìn)：豐田公司因其持續(xù)改善文化而聞名。期望每個(gè)人能不斷地尋求持續(xù)改善，特別是那些最了解問(wèn)題并負(fù)責(zé)解決問(wèn)題的人。
   • 進(jìn)行探針試驗(yàn)并穩(wěn)定下來(lái)：探針試驗(yàn)是極限編程實(shí)踐，讓團(tuán)隊(duì)構(gòu)建一個(gè)臨時(shí)方案以快速了解某個(gè)棘手的技術(shù)問(wèn)題、探索某個(gè)不熟悉的領(lǐng)域，或是提升估算的信心。
   • 創(chuàng)造創(chuàng)新時(shí)間：谷歌因其“20%的時(shí)間”聞名于世，其員工可以將其20%的工作時(shí)間用于任意項(xiàng)目。其他公司組織黑個(gè)馬拉松并允許團(tuán)隊(duì)探索新產(chǎn)品或改進(jìn)現(xiàn)有產(chǎn)品。Atlassian定期召開24小時(shí)會(huì)議，并稱其為Shiplt。
   • 采用基于集合的開發(fā)方式：基于集合的開發(fā)專注于探索多種方法。咋一看，由于額外的工作，多個(gè)可選項(xiàng)很費(fèi)功夫，但在探索多個(gè)選項(xiàng)的同時(shí)，團(tuán)隊(duì)最終能更好地理解問(wèn)題，并通過(guò)工具和方法找到真正的約束。
   • 連接工程師和最終用戶：只有當(dāng)團(tuán)隊(duì)清楚試驗(yàn)的影響，試驗(yàn)才會(huì)成功。A/B測(cè)試是企業(yè)應(yīng)用這種試驗(yàn)思維的實(shí)踐。企業(yè)的另一種實(shí)踐是派團(tuán)隊(duì)和工程師觀察用戶是如何與軟件交互來(lái)完成某項(xiàng)任務(wù)的。
9. 公司不愿拋棄任何具有感知價(jià)值的東西，但通常，返工比重寫的成本更高。將現(xiàn)有架構(gòu)轉(zhuǎn)變?yōu)榭裳葸M(jìn)的架構(gòu)的第一步是模塊化。因此，開發(fā)人員的首要任務(wù)是研究當(dāng)前項(xiàng)目是否具有模塊性，并圍繞這些發(fā)現(xiàn)重建架構(gòu)。一旦架構(gòu)變得不那么雜亂，架構(gòu)師便能輕松地了解底層結(jié)構(gòu)并為重建做出合理的決策。P135
10. Martin Fowler將犧牲架構(gòu)定義為“可拋棄的架構(gòu)”。很多公司需要在開始時(shí)構(gòu)建簡(jiǎn)單版本來(lái)進(jìn)行市場(chǎng)調(diào)查或驗(yàn)證可行性。一旦驗(yàn)證成功，他們可以構(gòu)建真正的架構(gòu)來(lái)支持已經(jīng)顯現(xiàn)的架構(gòu)特征。P135
11. 與其嘗試說(shuō)服組織中的保守人群，不如展示這些想法對(duì)其實(shí)踐的改進(jìn)。P136
12. 咨詢?nèi)岬溃喝岬雷鳛橐环N武術(shù)，有很多技巧是利用對(duì)手的重量進(jìn)行對(duì)抗。咨詢?nèi)岬绖t需要找到一個(gè)特性的痛點(diǎn)，并將解決該痛點(diǎn)作為案例。P136
13. 未來(lái)已來(lái)，只是尚未流行。P136
14. 任何校驗(yàn)架構(gòu)的東西都是適應(yīng)度函數(shù)，同等對(duì)待這些驗(yàn)證機(jī)制使得自動(dòng)化和驗(yàn)證更加容易。我們希望架構(gòu)師開始將架構(gòu)特征視為可評(píng)估的事物，而非突發(fā)奇想，這樣他們能構(gòu)建出更具回彈性的架構(gòu)。P138