解釋
其實這句話很好理解，我們在解決乙個具體的需求的時候，不要老想著去用最新最酷炫的技術以此來提公升自己的簡歷，我們應當更加落實於問題，選擇正確的解決方案，而不是過於追求技術。
個人理解
這一條放在本書的正文第一頁，裡面說的情況其實還是挺真實的。就連我現在在學習階段，也是會犯下這樣的錯誤。面對老師提出的問題，總是想著用多麼多麼酷炫牛批的技術去實現，但實際上更加應該注重的是對於問題的分析以及問題的解決能力。正如書中所說，作為一名架構師，職業操守不能忘，能夠很好的完成任務才是自己首要該做的事。
解釋很多時候簡單的系統都會翻車。這時候大家都會把矛頭指向開發。但大部分專案都是由人完成的，人才是專案成敗與否的基礎。如果團隊有人工作方式不正確進而拖了整個團隊的後退怎麼辦？因此有一種非常古老的方式可以解決這類問題——對話，不要把對話當成對抗，不要帶著情緒與人交流，嘗試溝通設定共同的目標。這樣每次溝通才能都有所收穫。
個人理解解釋
顧客和使用者通常提出的所謂需求，只是他們心目中可行的解決方案。架構師要通過諮詢客戶，分析客戶要求的功能和需求的真正意義，定位真正的問題，從而提出比客戶的建議更好、成本更低的解決方案。總的來說，架構師應該通過與客戶面對面的交流，關注客戶的需求，引導客戶回答「為什麼」的問題。
個人理解
這點也深有體會。在實際的專案合作中，可能對於客戶來說實現他的需求的方式是這樣子的，但我們真的要做起來又是那樣子的。因此要加強與客戶（使用者）的溝通，引導他們說出到底為什麼要做這樣子的東西，即真正的需求是什麼，發掘出他們真正想要的東西。這樣才能更好的為他們服務，做出更加令人滿意的產品來。
解釋由上述的很多例子可以得出結論，系統必然會出錯。我們應當承認必然存在著不同形式的故障隱患，無論如何都無法徹底消滅。我們應該針對特定的故障設計對策，設計預防措施來限制故障，保護系統。
個人理解
這一條裡面提到的很多情況也是我自己一直在思考的一點。我在學習大資料框架的時候了解到很多大資料框架為了提高自己的效率，也是為了降低故障的機率，都採用了分布式，且具有高可用（high **ailable），即一台掛掉後可以迅速切換到另一台。但這麼做的話我一直覺得可行性不強。因此架構師的作用也才體現了出來。
架構師應該針對這種情況做好提前的預備措施，防止事件發生後沒有相應對策使得系統崩潰，進而全盤崩潰。
總的來說，這本書就類似於我高中的時候背單詞的小書一樣，全是一些指導性的建議。但裡面的每一點都是實實在在的，真實存在的實踐之談。還是可以學到很多知識的。
軟體架構師應該知道的97件事 筆記 一
1.客戶需求重於個人簡歷 不要為了學習新的知識或豐富自己的簡歷而選擇新技術解決問題，要盡量選擇切合實際的技術解決客戶的難題。腳踏實地的為客戶著想，選擇正確的方案可以降低專案的壓力，團隊工作起來更開心，客戶也會更滿意，從而你也會有更充裕的時間學習新的知識。2.簡化根本複雜性，消除偶發複雜性 根本複雜性...
軟體架構師應該知道的97件事 筆記 四
46.避免重複 如果開發人員複製救命 中的內容，說明這部分還可以簡化，甚至全部提取出來。消滅複製是架構師的責任，如果有重複，則應該重新研究框架，創造更完善的抽象機制。47.歡迎來到現實世界 現實世界是不可預知的，隨時都可能發生一些讓人預料不到的事情，如客戶撤消訂單，付款時間延誤等。如果現實世界帶來了...
讀《軟體架構師應該知道的97件事》有感
其實拿到博文視點 贈送的這本 軟體架構師應該知道的97件事 已經有一段時間了，可一直沒有時間去讀。在剛剛忙完乙個大專案之後，又有資料庫集群的架構需要調整。想想事情永遠是做不完的，再忙也不能把給自己充電的事情落下。還好，這是一本不需要有大段連續時間來讀的書，只要有一點點時間，就可以翻開書頁學幾件 應該...