知不知上——控制調查範圍

這又是一篇我說不清楚到底屬於「架構設計」還是「道德經解讀」的討論。

《道德經》說「知不知上，不知知病」（吐一句嘈，道德經大部分話，用普通話念好難聽，還是用我們本地土話念出來押韻。我中學的語文老師楊寶霖老師是研究我們本地語言發展的，他說我們的本地話是「唐音的嫡音」，所以我的古文背誦基本上都是用本地土話來背的。我說這個，是要告訴你，其實道德經大部分話都是押韻的，只是你不一定會念），不知道有沒有人考量過背後的意思？

為什麼是「知不知上」，而不是「全能全知上」？這個問題只有神棍才會問：），因為根本就沒有「全能全知」。自稱全能全知的——如果你能看見的話——除了在你面前裝神弄鬼或者扮清高，啥事兒解決不了。所以，關鍵問題不在這個上面。

關鍵在於「不知知病」，我們覺得有問題的，是我們「不知道」「我們想要知道的」，這樣我們才認為是「病」（有問題）。換句話說，只有我們有「要解決的問題」，我們才知道我們有什麼「病」。這才是知不知上的關鍵。這是戰略設計，也是軟體構架設計的關鍵問題。戰略設計階段，就好像玩2048遊戲開始的階段，你有無數的自由度，這個階段你用「能解決問題就好」，「能運行就行」來定義你的設計，後面很短時間內就會「數窮」，要讓自己不那麼快「數窮」，讓自己的軟體或者戰略「天長地久」，就要「慈」，「儉」，「不為天下先」。也就是用最小的籌碼，實現所有想達成的目標。

所以，沒有目標，無所謂「儉」。「儉」是解決了問題，但花的代價比其他解決問題的方法花的代價少。

然則，全知就不「儉」，因為這花了巨大的代價，解決的問題卻很少。要知知，要病病，前提就是有目標。沒有目標就無法知其所需知，也就無法病其所以病。所以，其出彌遠，其知彌少。要知知，就要回到問題的本源。所以貴「食母」。

我二十多年前入行，開始做驅動開發，然後做子系統的SE（系統工程師），然後做版本的SE，然後做產品線的構架師，然後現在做產品系列的架構師。我發現我寫的設計越來越短。在我做SE的時候，我基本上都是用IEEE-1471-2000指導自己的設計的，其實IEEE1471對構架的定義已經非常寬泛了，它是這樣定義的：

The fundamental organization of a system embodied in its components, their relationship to each other, and to the environment, and the principles guiding its design and evolution.

翻譯成中文大概是這樣：

（構架設計是）一個系統的基本組織，和對它的設計和演進的基本指導。所述的「組織」包括這個系統的部件，它們之間，以及它們和外界環境之間的關係。

這個通用度已經相當大了，無論系統是大是小，終究是個分解，聚合的過程。

做模塊設計的時候，我可以設計關鍵數據結構，核心演算法，狀態機。到設計版本的時候，我要設計部件選型，關鍵介面選型，考量開發和運營成本。到設計產品的時候，我就只能關注總體人力投入，市場競爭力，所有依賴部件的生存能力，供應商和我們的關係等等。到我現在設計「生態」了，我寫下的設計，幾乎就只剩下選擇哪個需求做，那個需求不做了。

這樣，到了開發「生態」這個級別，IEEE1471也不夠用了，我現在還沒有找到比道德經更能解釋我現在為什麼要這樣來做設計的理論。

高級別的構架設計，其實很核心的一個工作是定義「我們不做什麼」。因此我寫的構架設計常常通篇都是這樣的東西：

某某某特性我們不做

某某特性讓客戶自己做

某某特性慫恿某開源社區和友商做

很多人表面可能不好意思說，其實背後會質疑：你瑪怎麼通篇都是「不做」，你到底做什麼？哈，我就做那些被我發現「你」不做的：）這就叫為天下溪。

所以，構架控制其實是非常累的一件事，離遠了，你控制不了（神棍就特喜歡這個，他們喜歡說「人家到深山裡去了，不和你們玩了」，不玩就死遠點嘛，叫條毛啊？），離近了，你破壞系統。不使力，成不了，使力了你自己變成競爭者。到最後，只剩下「就事論事」一個可以比較長遠的策略了。構架設計，也就「需求分析」是比較靠譜一點的（也不怎麼靠譜），其他的，能長遠比較難。

所以我通常都跟我的領導說，你別用我怎麼干來評價我，你用產品的進展來評價我，因為構架設計沒有樣子看的。這種邏輯其實也適合其他的系統控制。你的自信要建立在成敗上，沒有「成敗」，說啥都是打嘴炮，打嘴炮最後就是看誰的嗓門大，有意思么？

但我這裡不是要討論這個，我要討論的是，如果你的設計到最後變成了「不設計」，你還如何控制系統向你期望的方向發展？構架設計首先是「設計」，是一個「有」，不是一個「無」。那麼，構架設計過程中，具體應該「守」什麼？

我的一般觀點是：

1. 維護一組當前承認的需求

2. 定義一組被承認的分支，並保持一個可以被自己控制的分支

3. 對當前每個大的特性定義一組模型，說明整個結構和合作關係（這主要用來推演miss了什麼）

4. 為當前偏離的發展方向，在特性設計中添加原則

然後，架構師就可以投下去做拜訪客戶，試用產品，寫某個模塊這種具體的工作，半年再回來Review這些設計了。

如果這種方法不適合你的產品，不妨告訴我。