這篇文檔沒有新東西，是最近評審了一個比較大型的架構設計，感覺該犯的典型錯誤都犯了，這裡記錄一下，作為以後舉例子時的參考吧。

第一個典型錯誤：不抽象。比如你做一個設備，這個設備的軟體燒到設備上，軟體有很多類型，比如bootloader，kernel，FS鏡像，獨立可升級軟體部件，配置數據，備份數據等等。你做架構設計，從燒寫的角度，你管這是bootloader還是kernel還是FS鏡像呢？你關注是的flash分區這個概念，這些東西應該稱為分區數據。這個部分的設計就應該基於分區數據來談。你不抽象，在燒寫邏輯下認知被燒寫的每個不同的對象。然後，在下一個角度，比如在源代碼管理這個邏輯下，認知每種不同的對象的源代碼管理。每個抽象角度你都用被你描述對象的全集來覆蓋。你的邏輯就會變得非常複雜，寫架構就變成寫代碼了。寫架構變成寫代碼不是勤奮，是「用戰術的勤奮掩蓋戰略的懶惰」。關鍵是，你讓我看你這麼複雜的邏輯鏈，我根本看不下來，我看不下來，參與你這個項目的其他人其實也看不下來，最終的結果是什麼呢？——當然就是沒有架構了，你寫的都是廢話——進不了別人心裡的，當然都是廢話。

這個錯誤有一個變體。不抽象，常常就帶著沒有角度。你說你怎麼燒寫，和你怎麼管理源代碼，是兩個獨立的角度。你非要把如何燒寫，和你選擇了github管理你的源代碼建立關聯（比如燒寫的時候用github來保存一些數據），以後想換別的代碼管理平台，就不用換了。這樣設計法，一開始就讓本來沒有關聯的東西變成混沌系統。

第二個典型錯誤是第一個錯誤引起的——邏輯不完整。因為沒有抽象，邏輯就變得非常複雜，比如根文件系統有100個包吧，你不抽象，有些包是tar打的，有些包是rpm，有些包裡面放了一個metadata，有些包放了些描述文件。然後你就一個個說吧，但肯定說不完，然後就一些有，一些沒有。然後你說這個設計能否實施呢？鬼知道，你都已經陷入細節了，高一層的邏輯已經沒有了，這就是沒有架構設計。所以，雖然你寫了上百頁的文檔，這些也不是架構設計。架構設計已經在你這層丟失了。

這種丟失其實常常發生在歷史階段，比如做一個項目，一開始根本就沒指望有長遠發展，臨時做起來的，這裡加加，那裡加加，就會變得很複雜。後面賺大錢了，做下一個版本，輕易也不敢動原來的東西，這時應該怎麼辦呢？——還是那句話——不為天下先。已經成了這樣了，就讓它這樣吧（你不是賺大錢了么）。但你不是要設計嗎？你決定你要設計什麼就好了，混沌的部分，你要不有資源有收益整理掉，要不你就繞著它走。但你的架構設計應該明確知道（乃至定義）這個部分是個混沌系統。很多人在架構設計中看不得臟，卻在實施中忍得了臟。這不是架構師應該做的，架構師需要反過來。架構設計時忍得了臟，面對最黑的一面。實施的時候嚴格按架構設計來執行，容不下臟。這樣才能讓目標得以保持。

所以，前面那個例子中，如果你能容忍有這麼多包，反正的系統就能跑了，也能加減包了，就先這樣唄，但假如你要加入動態安裝功能，你可以直接定義一種你要求的包的格式，然後增加直接，保證這種「可動態安裝包」的格式符合你的要求，基於這個來推演你的整個動態安裝過程好了。

其實這個錯誤的本質就是每個邏輯鏈都太長。你說30行代碼，你能看得出有沒有破綻。10000行你怎麼看得出，你肯定是需要把它通過函數組織，把每個獨立邏輯縮減到30行，才好分析這個邏輯有沒有錯的對吧。同樣道理，你一個自洽的邏輯，表述在2頁的文檔中，我還能看出有沒有破綻，你放在100頁的文檔中，你給誰看呢？你自己都不知道邏輯是不是通的，對吧。

第三個典型錯誤：沒有錯。最沒用的架構設計是沒有錯，不被人反對的架構設計。這幾乎是所有初學者必犯的錯誤，而且是最嚴重的錯誤。比如說，你設定一個原則：「rule1：所有軟體包必須保證和其他軟體包解耦」。

這句話肯定沒錯，問題是，Who care? 這話說了等於沒說，這種原則完全不痛不癢，用來在知乎上寫雞湯還馬虎，用來做設計？

又比如說，你去詳細定義一個安裝的過程，沒有人能看出這個設計有沒有錯。但你設計這個東西想給誰看？

架構設計不是代碼，不是實現。你是去干涉別人的實現，別人必然會幹的東西，要你多說一句嗎？

架構設計設定的每個設計要求，都是刀子，是一刀切下去，一堆人會痛，要跟你撕逼的。這才是架構設計。你所有的設計，聽眾都是點點頭，當做沒有說過一樣，你這個設計必然做錯了。你不是做詳細設計的人，你對於那些模塊都是外行，你不可能不錯的。比如你要統一安裝包的格式，以便可以統一安裝，統一升級。你要求所有的軟體包都用rpm格式打包，並且交叉安裝在Host上，然後壓縮成squashfs燒到單板上。做UEFI的人就該來找你麻煩了（根本沒有目標安裝目錄），從Debian直接引入源代碼的人也來找你麻煩了（可能因為他們遵循的目錄樹放置規則，或者使用的libc庫和你的要求不兼容？），你要不K贏他們，要不修改你的設計。無論如何吧，架構設計一刀子都是又快又狠地切下去的，然後根據反彈的程度（以及不斷增長的信息）來進行一步步修正，從而既保證了你的目標得以推行，又保證這個目標推行的時候不會大幅傷害可實施性。

我不知道我說明白這個問題沒有，真希望可以讓讀者看看那些「不狠」的構架設計，基本上這些貌似什麼都沒有錯的構架設計啊，就和沒有設計一樣。

推薦閱讀：