《恰如其分的軟體架構》這本書和其他英文翻譯書一樣，並沒有太多手把手教你如何設計乙個軟體架構。
但是！對於乙個工作多年的嵌入式軟體工程師，書中很多概念還是給人留下了深刻的印象！有一種——哦！我在做xx專案時，感覺就是這樣！！ ——哦！這不是就是我當時寫的那個**的樣子嗎！！
just enough!!!
我看的是翻譯版的書，中文把名字翻譯成了《恰如其分的軟體架構》，看完前面章節後，總感覺這個「恰如其分」有點文縐縐的，沒有直達人的心靈，果然一查原有英文 just enough!!，對就是這個詞。一般情況下軟體架構都是在軟體開始**編寫之前開始設計的，這個時候就有個問題，架構設計要進行到什麼程式，是不是把每一種可能情況都想到，設計覆蓋每個細節的架構，然後編碼就嚴格按照這個架構設計進行，才可以？還是說架構設計做乙個大概的方向，然後馬上開始進行**開發？？這本書告訴我們，都不是！！ 軟體架構設計應該是在這兩個極端之間。 就是在**開始編寫前我們需要做架構設計，但是沒有必要把所以細節完全覆蓋，當然這也不現實。那架構設計做到什麼程度呢？——夠用就好！！書中給出另乙個風險驅動的模型，認為要根據風險來確定架構設計需要進行到什麼程度，的確這確實是乙個辦法。 不過我回顧了一下，自己和團隊在做專案和產品過程中是如何處理這個問題的（雖然當時我們自己沒有意識到，但我們確實是做了本書中所講的策略），大多數時候我們會根據需求在腦海中形成乙個相對模糊解決方案，架構設計負責的就是把這個解決方案具體化，直到圖紙上和腦海中形成乙個相對清晰的解決方案，然後會發現哪些地方是難點，哪些地方有比較大的風險，在寫**的時候需要多加注意。我們不可能把對應的風險全部在寫**之前確定好如何解決，尤其對於嵌入式軟體工程師，因為有些地方我們需要做一些」實驗「，看一下我預想的是不是對的。但是這樣的架構設計，大多數情況下，足以支撐專案走下去了，而不是喋喋不休的不斷的進行架構設計的迭代——軟體架構夠用就好！！just enough！！
檢視這個概念並不新鮮，但是本書強調的幾個注意事項還是值得銘記在心的。
首先完整詳細的架構是有的，但是我們不能一下子全部看到，有點類似於工程製圖中，投影的原理，把乙個三維圖形投影到二位平面中。在軟體架構設計中，我們可以做出各種檢視，但是每個檢視只回答乙個關切問題，乙個檢視不能面面俱到。
靜態檢視和執行檢視
對，就是這個，非常關鍵！！大多數時候，我們寫的**是和靜態檢視對應的，程式設計中對於高內聚低耦合的模組是推崇的，這樣便於維護，擴充套件，對架構設計大多數時候也是遵循這個規定的，誠然這模組式的程式設計對於專案和程式設計師本身來講都是有好處的。但是這裡有乙個問題——**執行的時候，是動態的，程式**可能會來回的跳轉執行，把靜態檢視模型下寫的**於執行的檢視聯絡起來就成了程式設計師面臨的挑戰。即使使用面向流程的c語言，仍然面臨這個問題。準確，快速的在腦海中構建乙個**的執行檢視，起碼在嵌入式領域是檢測乙個程式能力水平的試金石。
最後，我認為《恰如其分的軟體架構》這本書，是一本提高「內功」的書，看完這本書之後，並沒有讓自己馬上掌握了乙個快速高階的工具或者方法，讓自己短時間邁入架構師這個高大上的行列，但是對於乙個程式開發人員，讀過這本書後會讓自己在後續的程式開發生涯中有所收穫，行穩致遠（這個詞用得有點高階
設計恰如其分的架構
遠在2009年，martin fowler與rebecca parsons在qcon sf做了一次題為agilists and architects allies not adversaries presentation的演講。演講主要討論了在敏捷方法中的架構活動。相似的話題，neal ford則提...
軟體架構讀書筆記
我們自己不知不覺地設定了事物之間的界限，並把這些界限 層次與邏輯井然的東西稱為 系統 當我們從那些無序的事物中識別出了這樣的 系統 並用一些概念 名詞去定義了他們之後，我們對此的一切知識也就固化了。當這種秩序被建立起來之後，我們也就得到了對有序和無序價值的識別與肯否 當我們設定了種種價值 觀念 觀察...
讀書筆記 鳳凰架構 其一
什麼是鳳凰架構 1 提出重程式設計能力還是重架構的問題 2 提出構建乙個大規模但依然可靠的軟體系統是否是可行的 通過馮諾依曼研發自複製自動機的例子舉例我們一直是在用不可靠部件構造可靠的系統。比如我們開發的每個環節都是有可能出錯的，但最終設計出的軟體必然是不可靠的，但事實並非如此。用馮諾依曼的自動機這...