架構設計的0層邏輯

編程的本質是創建名稱空間。所謂名稱空間，包括三個東西：

1. 一組字元串，作為名（Identity）

2. 定義名（字）是什麼

3. 定義名怎麼樣

很明顯，名稱空間完全是精神世界的產物。在精神世界裡，我們有很高的自由度，唯一的限制是我們的想像力和腦容量。我強調這點，要說明的的是，精神世界左右你的核心問題肯定不是Pattern，甚至不是邏輯（邏輯一致，或者說概念一致性，是一個簡化邏輯空間的方法，卻不是程序的前提），我們不見得需要用這些東西來左右自己的名稱空間。

但如果你要用程序去解決問題，你的限制就來了。「名」為了描述「道」（現實）而產生，但「道」很大程度上不被「名」所左右，甚至名本身就是「道」的一部分。優秀的程序的每個名字定義，都為了對道進行逼近，而不是為了「名」本身簡潔和好看。「名」的簡潔和好看是個人的精神需要，我們都希望事情簡單優美，但最終我們希望逼近道。

我們在這個專欄的前面花了12個博客來討論性能優化，最終都是為了用具體實例來說明這一點：我們以為我們受的限制僅僅在名稱空間的外圍，在物理世界和精神世界的邊界處，在我們的設計（精神世界定義）內部可以有很多選擇，但其實在「性能」的壓力下，你在精神世界也是幾乎沒有幾個選擇的。性能是現實綳進邏輯空間的弦，讓看起來有很大自由度的精神世界，也變得和現實一樣冷冰冰，沒有選擇。

在這一篇中：生成優秀的架構，我們討論過這個問題：我們維護一個大型的軟體，在每個維護開發周期能修改的部分有限，這些修改必須都用於取得競爭力，否則這個軟體就會被淘汰，被取代，它幾乎是沒有選擇的。這特別像一顆自然的植物，它生生不息地生長，每個生長都必須伸向陽光，水份和肥料（而不是擺出一個「道」字的形狀：））。所以你看起來每顆植物形態各異。但對植物個體來說，它長成今天這個樣子，幾乎就是一種「必然」。只有溫室中的花朵可以在強大的人力營造的環境中被隨心所欲打扮，但溫室的花朵是無法在大自然中存活的。

綜合起來說，一個軟體能變成什麼樣子，和所選擇的需求，投入的資源息息相關，在大的層面，最終就是個必然，和架構師的期望，乃至「老闆的目的」、「程序員的情懷」都沒有非常大的關係。

所以，第一層架構邏輯，也許你不會寫下來，但它既不是這個軟體的需求，也不是在這個軟體的「名稱定義」，而是定義清楚軟體的需求和養分是什麼。軟體的需求和養分，看起來歸根結底是「投資」的問題，事實上不是，你這樣理解一下：有一個千億萬富翁，閑著沒事，找了一千人，花了十年，開發了一個可以在天上列印一個「愛」字的軟體，這個軟體有一億行代碼，這個軟體能「活」下去嗎？

「活」不下去的，它的生命周期就是這個富翁的投資周期。沒有人靠這個軟體過活，這個軟體就會死亡。

軟體真正的養分，是用戶量。如果能想讓一個軟體可以不斷活下去，你真正要做的是讓它擁有最大量的用戶。這個邏輯，甚至不受你的老闆的左右。專門支持某運營商的X信死了（或者說不死不活吧），支持所有平台的微信能活。這你也許說是有投資的原因，但但凡這種還沒打就把自己限制在一個平台上的，就已經屬於綁著自己的手和別人競爭了。

當然，不是每個人都希望一個軟體能活下去，只是想解決一個臨時的問題。但大部分時候我們不是這樣，所以，一件事只要開始做了，每個人都只是這件事上的其中一隻螞蚱，無論是上司還是下屬，都很難離開這個漩渦了。這個事情會被整件事情的名稱空間所控制，決定你下一步可以做什麼。這是架構設計的0層邏輯。 要研究一個軟體如何發展，首先不是研究直接給出來的需求，而是研究這個軟體如何在整個生態鏈上浮著，成為整個生態鏈生存的需要，在那之後，你才能談你的個人情懷。

我們看一個開源軟體是否成功，到頭來，也不是你看到的花團錦簇，而是用戶量的變化，這個用戶量，也不是「使用」這個軟體的用戶量，而是「靠」這個軟體過活的用戶量。當我們把目光盯在這個問題上，我們就能看懂一個軟體真正的競爭力了。

我想起要寫這個文檔，是因為常常在討論軟體構架策略的時候，別人會跟我談到開源和閉源的戰略問題，談「公開宣講」和「私下目的」的問題。他們總認為這兩者是可以割裂的，他們以為他們可以口上說一套，私下做另一套，或者開源做一套，私下做另一套。我認為他們都沒有想明白一個道理：暴露出來的策略，和私有的策略，只有可能互相順從，否則吃虧的一定那個所謂的私有策略，這就是「守中之道」。表象和內在，在性能（競爭力）的壓力下，是必然必須互相對齊的。所以才有「聖人無私，所以成其私」。所以，做開源方案，或者做行業標準，或者建立一個新市場，唯一的辦法是全力投進去幫助整個生態，你以為你可以簡單攪起一點風雨，然後坐在後面看別人表演，終究是為他人做嫁衣裳的。國內很多軟體企業都缺乏這個認識，所以他們的行業解決方案都毫無價值可言。

附錄1：關於公開方案和私有方案的進一步解釋。

這段補充回答有人私信問的問題：「為什麼暴露出來的策略，和私有的策略，只有可能順從，否則吃虧的一定是私有策略」。

這個原理就是前面的推導，一個解決方案，他可以如何設計，受需求和性能壓力的拉緊：

1. 如果你的開放方案和私有方案各懷鬼胎，這個方案沒有「拉頸」，這個解決方案在競爭中就會落敗。

2. 如果開放方案是完全受控的（受你控制），它給你帶來的收益肯定不如你全力去做一個私有方案，這是自己給自己找麻煩

3. 如果你使用一個很小的私有方案，而這個方案在整個解決方案中很重要，如果其他人做不了，沒有多少人會投進來，如果別人覺得在這個體系中還能活下去。這個體系一定有你想不到的路子讓體系在沒有你的情況下活下去，到時受控的是你，不是別人。

所以，我素來說偽君子比真小人好。偽君子自己的那點小九九，在他自己建立的體系面前，只會讓他死無全屍。