總的來(lái)說(shuō)這本書(shū)還不錯(cuò)，我在豆瓣筆記上說(shuō)是程序員架構(gòu)入門的最佳實(shí)踐。本書(shū)最后的幾個(gè)例子都充分證明這一點(diǎn)，做什么該如何做為何這么做是否必要這么做等等問(wèn)題擴(kuò)展開(kāi)來(lái)談。 
下面是kindle里的筆記。

你之所以時(shí)時(shí)在尋求跨界，其實(shí)是源自你假設(shè)了“存在界線”，這就如同全棧的含義其實(shí)是“沒(méi)有?！保?dāng)有人信心滿滿地要“成為全棧工程師”時(shí)，他的眼里便又有個(gè)“這個(gè)棧”的存在。

架構(gòu)師需要超越自己與別人的所見(jiàn)，因?yàn)槟阌^察與架構(gòu)的對(duì)象稱為“系統(tǒng)”，你看到系統(tǒng)多少的真相，決定了你用怎樣的影像去表現(xiàn)它，并進(jìn)而推進(jìn)與實(shí)現(xiàn)這種影像，亦即是架構(gòu)。

所以架構(gòu)中最難超越的并不是某個(gè)大師或前輩，而是你以及你為自己所作的設(shè)定。

你的軟件系統(tǒng)有良好定義的結(jié)構(gòu)嗎？ 團(tuán)隊(duì)里每個(gè)人都以一致的方式實(shí)現(xiàn)特性嗎？ 代碼庫(kù)的質(zhì)量水平一致嗎？ 對(duì)于如何構(gòu)建軟件，團(tuán)隊(duì)有共同的愿景嗎？ 團(tuán)隊(duì)里每個(gè)人都得到了足夠的技術(shù)指導(dǎo)嗎？ 有適當(dāng)?shù)募夹g(shù)領(lǐng)導(dǎo)力嗎？

技術(shù)選擇其實(shí)就是風(fēng)險(xiǎn)管理，當(dāng)復(fù)雜度或不確定性高的時(shí)候降低風(fēng)險(xiǎn)，有利可圖時(shí)再冒點(diǎn)險(xiǎn)。所有的技術(shù)決策，在做出選擇時(shí)都要把全部因素考慮在內(nèi)，這些技術(shù)決策也需要評(píng)審和評(píng)估。這可能包括一個(gè)軟件系統(tǒng)所有的主要結(jié)構(gòu)單元，下至在開(kāi)發(fā)過(guò)程中引入的庫(kù)和框架。

不要把全部時(shí)間都用于編碼

因?yàn)榧夹g(shù)不是一個(gè)實(shí)現(xiàn)細(xì)節(jié)，你需要理解為自己的決定所做的取舍。

軟件架構(gòu)師應(yīng)該寫(xiě)代碼嗎？我直截了當(dāng)?shù)鼗卮穑骸袄碚撋?，是的?！备暾拇鸢缚梢栽谶@本書(shū)里面找到。為什么？因?yàn)榧夹g(shù)不是一個(gè)實(shí)現(xiàn)細(xì)節(jié)，你需要理解為自己的決定所做的取舍。

軟件架構(gòu)師被看作是首席設(shè)計(jì)師，是把項(xiàng)目的每件事凝聚在一起的人。

我們生活在“互聯(lián)網(wǎng)時(shí)代”。除非我們這個(gè)行業(yè)發(fā)展到軟件的構(gòu)建方式和預(yù)測(cè)工程項(xiàng)目相同，否則團(tuán)隊(duì)中有人一直跟隨技術(shù)的發(fā)展，有能力做出如何設(shè)計(jì)軟件的正確決策，還是很重要的。

和其他可選技術(shù)相比，我們所選的是否最合適？ 對(duì)該系統(tǒng)的設(shè)計(jì)和構(gòu)建，還有哪些選擇？ 是否應(yīng)該采用一種通用的架構(gòu)模式？ 我們是否明白所做決策的利弊？ 我們照顧到了品質(zhì)屬性的需求嗎？ 如何證明這種架構(gòu)行之有效？

作為領(lǐng)導(dǎo)，讓團(tuán)隊(duì)保持積極是你的責(zé)任，你的角色在整個(gè)團(tuán)隊(duì)中不應(yīng)被低估。

99.9%（“三個(gè)9”）的正常運(yùn)行時(shí)間意味著留給計(jì)劃維護(hù)、升級(jí)和意外故障的時(shí)間每天只有1分多鐘。

編碼標(biāo)準(zhǔn)和規(guī)范：“我們將采用內(nèi)部的[Java|C#|其他]語(yǔ)言編碼規(guī)范，這可以在我們公司wiki找到。” 自動(dòng)化單元測(cè)試：“我們的目標(biāo)是核心庫(kù)的自動(dòng)化單元測(cè)試達(dá)到80%的代碼覆蓋率，無(wú)論代碼開(kāi)發(fā)是先測(cè)試還是后測(cè)試。” 靜態(tài)分析工具：“所有的生產(chǎn)和測(cè)試代碼在提交到源代碼管理之前，必須通過(guò)[Checkstyle|FxCop|其他]定義的規(guī)則?！?/p>

一天結(jié)束時(shí)，不論是否與性能、可伸縮性、可維護(hù)性、找到有合適經(jīng)驗(yàn)的人的能力等方面相關(guān)，你做出的每一個(gè)技術(shù)決策都有權(quán)衡。

如果你不明白選擇X技術(shù)而非Y的權(quán)衡，那就不應(yīng)該做決策。設(shè)計(jì)軟件系統(tǒng)的人要懂技術(shù)，這很重要。這就是為什么軟件架構(gòu)師應(yīng)該是建造大師。

但如果要向別人解釋系統(tǒng)如何工作，你會(huì)一來(lái)就說(shuō)代碼嗎？

非正規(guī)的框線草圖提供靈活性的代價(jià)就是一致性，因?yàn)槟銊?chuàng)造了你自己的標(biāo)記，而不是使用UML等的標(biāo)準(zhǔn)。

忘了昂貴的工具吧。很多時(shí)候，你需要的只是一張白紙、掛圖或白板，特別是當(dāng)你有一組人想要以協(xié)作的方式承擔(dān)設(shè)計(jì)過(guò)程。

代碼會(huì)講故事，但不會(huì)講述完整的故事。

代碼庫(kù)也沒(méi)有什么不同。盡管我們可以花很長(zhǎng)一段時(shí)間繪圖和描述每一段代碼，但這樣做真的價(jià)值不大。我們真正需要的是列出興趣點(diǎn)，這樣就能集中精力去理解軟件的主要元素而無(wú)需陷入所有的細(xì)節(jié)。

把這個(gè)輔助文檔當(dāng)作一個(gè)指南，它應(yīng)該給人們上手提供足夠的信息，幫助他們加快探索的過(guò)程。

能講述產(chǎn)品如何工作、如何演化。

系統(tǒng)實(shí)際上做什么是否清楚？ 哪些特性、功能、用例、用戶故事等對(duì)架構(gòu)是重要的，原因是否清楚？ 重要的用戶是誰(shuí)（角色、參與者、人物等）以及系統(tǒng)如何滿足他們的需求是否清楚？ 上述已用于塑造和定義架構(gòu)是否清楚？

概括來(lái)說(shuō)，架構(gòu)就是結(jié)構(gòu)和愿景，這個(gè)過(guò)程的關(guān)鍵在于理解重要設(shè)計(jì)決策。

敏捷和架構(gòu)并不沖突。與其盲目聽(tīng)從別人的指點(diǎn)，軟件團(tuán)隊(duì)更應(yīng)剔除炒作，理解技術(shù)領(lǐng)導(dǎo)力的方式，在其獨(dú)特的環(huán)境下量化所需的預(yù)先設(shè)計(jì)。

對(duì)于預(yù)先架構(gòu)和設(shè)計(jì)，我的方法是要做到“恰如其分”。

在我看來(lái)，軟件架構(gòu)最大的問(wèn)題是它在與軟件行業(yè)每天創(chuàng)造的新事物競(jìng)爭(zhēng)。

人們用于學(xué)習(xí)的時(shí)間和精力有限，但沒(méi)時(shí)間通常不是團(tuán)隊(duì)不理解軟件架構(gòu)是什么的原因。