金玉良言
走快的唯一方法是先走好。
做一個好的軟體架構師所需要的自律和專注程度可能會讓大部分程式設計師始料未及。
軟體系統不應該依賴其不直接使用的元件。
程式規模上的墨菲定律
程式的規模會一直不斷地增長下去，直到將有限的編譯和連結時間填滿為止。
軟體架構師自身需要是程式設計師，並且必須一直堅持做一執行緒序員。
軟體架構師應該是能力最強的一群程式設計師。
如果不親身承受因系統設計而帶來的麻煩，就體會不到設計不佳所帶來的痛苦，接著就會逐漸迷失正確的設計方向。
要在設計中儘可能長時間地保留儘可能多的可選項。
系統維護的主要成本集中在“探祕”和“風險”這兩件事上：
探祕：確定新增功能或被修復問題的最佳位置和最佳方式。
風險：當我們進行上述修改時，總是有可能衍生出新的問題。
如果在開發高層策略時，有意地讓自己擺脫具體細節的糾纏，就可以將與具體實現相關的細節決策推遲或延後。越到後期，我們就有越多的資訊來做出合理的決策。
一個優秀的軟體架構師應該致力於最大化可選項數量。
重複在軟體行業裡一般來說都是壞事。
如果有兩端看起來重複的程式碼，它們走的是不同的演進路徑，有著不同的變更速率和變更緣由，那麼這兩段程式碼就不是真正的重複。
要小心避免陷入對任何重複都要立即消除的應激反應模式中。
軟體架構設計本身就是一門劃分邊界的藝術。
一個系統最消耗人力資源的是什麼？答：耦合
I/O是無關緊要的細節
軟體開發技術發展的歷史，就是一個如何想方設法方便地增加外掛，從而構建一個可擴充套件、可維護的系統架構的故事。
執行緒既不屬於架構邊界，又不屬於部署單元，僅僅是一種管理並排程程式執行的方式。
系統架構中最強的邊界形式就是服務。
架構設計的工作常常需要將組建重排組合成為一個有向無環圖。圖中的每一個節點代表一個擁有相同層次策略的元件，每一條單向連結代表了一種元件之間的依賴關係。
軟體系統是一組策略語句的集合。
一條策略距離系統的輸入/輸出越遠，它所屬的層級就越高。而直接管理輸入/輸出的策略在系統中的層次是最低的。
希望原始碼中的依賴關係與其資料流向脫鉤，而與元件所在的層次掛鉤。
一定要帶著懷疑的態度審視每一個框架。
保持對系統用例的關注，避免讓框架主導我們的架構設計。
應該通過用例物件來排程業務實體物件，確保所有的測試都不需要依賴框架。
任何形式的共享資料行為都會導致強耦合。
架構設計的任務就是找到高層策略和低層細節之間的架構邊界，同時保證這些邊界遵守依賴關係規則。
橫跨型變更（cross-cutting concern）。系統的架構邊界事實上並不落在服務之間，而是穿透所有服務，在服務內部以元件的形式存在。
必須在服務內部採用遵守依賴關係原則的元件設計方式。
服務邊界並不能代表系統的架構邊界，服務內部的元件邊界才是。
系統的架構是由系統內部的架構邊界、邊界之間的依賴關係所定義的，與系統中各元件之間的呼叫、通訊方式無關。
軟體設計的第一條原則——不要依賴於多變的東西。
測試元件是系統架構中最外圈的程式。它們始終是向內依賴的，而且系統中沒有其他元件依賴於它們。
軟體（software）應該是一種使用週期很長的東西，而韌體（firmware）則會隨著硬體演進而淘汰過時。
軟體構建過程的三個階段
先讓程式碼工作起來——如果程式碼不能工作，就不能產生價值
然後再試圖將它變好——通過對程式碼進行重構，讓我們自己合其他人更好地理解程式碼，並能按照需求不斷地修改程式碼。
最後再試著讓它執行得更快——按照效能提升的“需求”來重構程式碼。
隨時準備“拋棄一個設計”
在實踐中學習正確的工作方法，然後再重寫一個更好的版本。
如果我們在構建程式碼的時候不夠小心，沒有小心安排哪些模組之間可以互相依賴，程式碼很快就非常難以更改了。
軟體與韌體之間的邊界被稱為硬體抽象層（HAL）
類似的還有，作業系統抽象層（OSAL）
從系統架構的角度來看，工具通常是無關緊要的。
常見的封裝方式
按層封裝，傳統的水平分層架構
按功能封裝，即垂直切分
埠和介面卡，業務領域程式碼與具體實現細節隔離的架構
按元件封裝
軟體架構的響應式設計：前期設計夠用，後期進行大量重構的設計思想。
每一項設計決策都必須為未來的變化敞開大門。
大部分的軟體開發者是沒有太多架構意識的，是更有經驗的開發者讓我瞭解了架構。
***********************************************************************
【如果文字看累了，可b站搜尋“沙皮狗2021”，用聽的方式領略知識的魅力】
傳送門 ：https://space.bilibili.com/407643589
【微信公眾號】：沙皮狗2021
***********************************************************************