總的來說這本書還不錯，我在豆瓣筆記上說是程序員架構(gòu)入門的最佳實踐。本書最后的幾個例子都充分證明這一點，做什么該如何做為何這么做是否必要這么做等等問題擴(kuò)展開來談。
下面是kindle里的筆記。
你之所以時時在尋求跨界，其實是源自你假設(shè)了“存在界線”，這就如同全棧的含義其實是“沒有棧”，而當(dāng)有人信心滿滿地要“成為全棧工程師”時，他的眼里便又有個“這個棧”的存在。
架構(gòu)師需要超越自己與別人的所見，因為你觀察與架構(gòu)的對象稱為“系統(tǒng)”，你看到系統(tǒng)多少的真相，決定了你用怎樣的影像去表現(xiàn)它，并進(jìn)而推進(jìn)與實現(xiàn)這種影像，亦即是架構(gòu)。
所以架構(gòu)中最難超越的并不是某個大師或前輩，而是你以及你為自己所作的設(shè)定。
你的軟件系統(tǒng)有良好定義的結(jié)構(gòu)嗎？ 團(tuán)隊里每個人都以一致的方式實現(xiàn)特性嗎？ 代碼庫的質(zhì)量水平一致嗎？ 對于如何構(gòu)建軟件，團(tuán)隊有共同的愿景嗎？ 團(tuán)隊里每個人都得到了足夠的技術(shù)指導(dǎo)嗎？ 有適當(dāng)?shù)募夹g(shù)領(lǐng)導(dǎo)力嗎？
技術(shù)選擇其實就是風(fēng)險管理，當(dāng)復(fù)雜度或不確定性高的時候降低風(fēng)險，有利可圖時再冒點險。所有的技術(shù)決策，在做出選擇時都要把全部因素考慮在內(nèi)，這些技術(shù)決策也需要評審和評估。這可能包括一個軟件系統(tǒng)所有的主要結(jié)構(gòu)單元，下至在開發(fā)過程中引入的庫和框架。
不要把全部時間都用于編碼
因為技術(shù)不是一個實現(xiàn)細(xì)節(jié)，你需要理解為自己的決定所做的取舍。
軟件架構(gòu)師應(yīng)該寫代碼嗎？我直截了當(dāng)?shù)鼗卮穑骸袄碚撋希堑摹！备暾拇鸢缚梢栽谶@本書里面找到。為什么？因為技術(shù)不是一個實現(xiàn)細(xì)節(jié)，你需要理解為自己的決定所做的取舍。
軟件架構(gòu)師被看作是首席設(shè)計師，是把項目的每件事凝聚在一起的人。
我們生活在“互聯(lián)網(wǎng)時代”。除非我們這個行業(yè)發(fā)展到軟件的構(gòu)建方式和預(yù)測工程項目相同，否則團(tuán)隊中有人一直跟隨技術(shù)的發(fā)展，有能力做出如何設(shè)計軟件的正確決策，還是很重要的。
和其他可選技術(shù)相比，我們所選的是否最合適？ 對該系統(tǒng)的設(shè)計和構(gòu)建，還有哪些選擇？ 是否應(yīng)該采用一種通用的架構(gòu)模式？ 我們是否明白所做決策的利弊？ 我們照顧到了品質(zhì)屬性的需求嗎？ 如何證明這種架構(gòu)行之有效？
作為領(lǐng)導(dǎo)，讓團(tuán)隊保持積極是你的責(zé)任，你的角色在整個團(tuán)隊中不應(yīng)被低估。
99.9%（“三個9”）的正常運行時間意味著留給計劃維護(hù)、升級和意外故障的時間每天只有1分多鐘。
編碼標(biāo)準(zhǔn)和規(guī)范：“我們將采用內(nèi)部的[Java|C#|其他]語言編碼規(guī)范，這可以在我們公司wiki找到。” 自動化單元測試：“我們的目標(biāo)是核心庫的自動化單元測試達(dá)到80%的代碼覆蓋率，無論代碼開發(fā)是先測試還是后測試。” 靜態(tài)分析工具：“所有的生產(chǎn)和測試代碼在提交到源代碼管理之前，必須通過[Checkstyle|FxCop|其他]定義的規(guī)則。”
一天結(jié)束時，不論是否與性能、可伸縮性、可維護(hù)性、找到有合適經(jīng)驗的人的能力等方面相關(guān)，你做出的每一個技術(shù)決策都有權(quán)衡。
如果你不明白選擇X技術(shù)而非Y的權(quán)衡，那就不應(yīng)該做決策。設(shè)計軟件系統(tǒng)的人要懂技術(shù)，這很重要。這就是為什么軟件架構(gòu)師應(yīng)該是建造大師。
但如果要向別人解釋系統(tǒng)如何工作，你會一來就說代碼嗎？
非正規(guī)的框線草圖提供靈活性的代價就是一致性，因為你創(chuàng)造了你自己的標(biāo)記，而不是使用UML等的標(biāo)準(zhǔn)。
忘了昂貴的工具吧。很多時候，你需要的只是一張白紙、掛圖或白板，特別是當(dāng)你有一組人想要以協(xié)作的方式承擔(dān)設(shè)計過程。
代碼會講故事，但不會講述完整的故事。
代碼庫也沒有什么不同。盡管我們可以花很長一段時間繪圖和描述每一段代碼，但這樣做真的價值不大。我們真正需要的是列出興趣點，這樣就能集中精力去理解軟件的主要元素而無需陷入所有的細(xì)節(jié)。
把這個輔助文檔當(dāng)作一個指南，它應(yīng)該給人們上手提供足夠的信息，幫助他們加快探索的過程。
能講述產(chǎn)品如何工作、如何演化。
系統(tǒng)實際上做什么是否清楚？ 哪些特性、功能、用例、用戶故事等對架構(gòu)是重要的，原因是否清楚？ 重要的用戶是誰（角色、參與者、人物等）以及系統(tǒng)如何滿足他們的需求是否清楚？ 上述已用于塑造和定義架構(gòu)是否清楚？
概括來說，架構(gòu)就是結(jié)構(gòu)和愿景，這個過程的關(guān)鍵在于理解重要設(shè)計決策。
敏捷和架構(gòu)并不沖突。與其盲目聽從別人的指點，軟件團(tuán)隊更應(yīng)剔除炒作，理解技術(shù)領(lǐng)導(dǎo)力的方式，在其獨特的環(huán)境下量化所需的預(yù)先設(shè)計。
對于預(yù)先架構(gòu)和設(shè)計，我的方法是要做到“恰如其分”。
在我看來，軟件架構(gòu)最大的問題是它在與軟件行業(yè)每天創(chuàng)造的新事物競爭。
人們用于學(xué)習(xí)的時間和精力有限，但沒時間通常不是團(tuán)隊不理解軟件架構(gòu)是什么的原因。
