最近讀完<clean architecture>(by Robert C.Martin, 即uncle Bob),和筆者日常所見所思有些共鳴，打算寫幾段文字，少量是介紹Bob大叔的新書，更多的是記錄自己的一些想法，算是借別人的酒澆自己心中的塊壘。這說明，這個系列的文字並不打算介紹這本書，即便是引述的內容都未必是Bob大叔想表達的原意(語境改變引起)，而更可能是我故意的曲解。
Bob大叔是敏捷軟件開發宣言(2001)的17位簽署者之一。今天想到這個事實，感覺似可以和獨立宣言的簽署者類比，何其奇怪而自然的聯想。敏捷的技術實踐中軟件設計可能是最難落地的。敏捷和<極限編程>都在強調自己是基於價值觀的方法。實際上一定有兩個問題，其一: 價值觀的理解不可能一致，進而引起good words問題，即如果敏捷成爲一種主流的開發方法，它所描述的價值觀成爲所謂good words後，這些詞的所指和能指一定發生重大的變化(想想我們今天怎麼使用”和諧“這個詞? ); 其二: 敏捷價值觀本質是一種精英價值觀。現實是今天參與軟件開發的人，大部分並不是精英，大部分公司也不能招來那麼多精英。怎麼讓軟件設計方法使日常的開發獲益一直是個問題。
架構的產生，一種看法是它應該是生長出來的，原初應該無知，發生變化,架構應該隨着變化生長，類似<反脆弱>一書中所描述的觀點;一種看法是，架構是藍圖，應該提前設計出來。實際中肯定會有一個折中，根本原因是我們不可能真的對某個領域無知，太陽之下無新事，總有可以類比成樣的東西。一類有廣泛市場和大量開發者的產品，往往還會有現成的框架、專用工具等以利開發和提升效率。這個折中的度的選擇上，千萬不要假裝看不見。對於會長期演進的產品，千萬不要假裝不知道它後來會有各種可以預見和難以想象的新需求，假裝看不到長期利益的存在，灰犀牛就在那，誰都不想談的結果是大家一起完蛋。特別是對於開發者，這麼做是愚蠢的，除非你打算寫完這個模塊就離職(但仍有悖你的職業道德)。架構師對軟件的長期利益即它的靈活性(變更的代價)應該負有首要的義務。一般而言出現的問題往往是缺乏設計而非過度設計，更不要借敏捷之名而行缺乏設計之實。
好吧，我的基本看法是，架構師要給出系統拆解的標準和組合的方式，要促使系統上下游達成-致，要分清功能和約束(特別是在處理性能方面)，最重要的是要使這一切具有真實的可行性。不要寄希望於價值觀產生直接的效果(價值觀很重要，但不夠具體)，不要相信架構能在代碼中自行健康的生長，一言以蔽之，要做適當的約束和控制。
計劃中的話題包括
(一)軟件的核心價值:長期演進
(二)編程範式的變化:約束能力
(三)組件設計原則
(四)原則間的矛盾: SIP vs ISP
(五)架構關心什麼
(六)劃分邊界
(七)抽象和接口
(八)核心域和分層
(九)敏捷價值觀和現實的碰撞
(十)架構師的職責
一到七節，基本按<clean architecture>- -書的脈絡走，最後三節和此書關係不大，但和我理解的架構師的職責有很大的關係。