架構應該如何來理解？
最近要多帶一個架構團隊做一個新版本，我寫一些基本邏輯來給團隊建第一層策略建模，以便我們後面的討論有基礎，由於這種問題是普適的，也不會涉及什麼具體的保密問題，所以我公開來寫。
架構是一個充滿了自由度的工作，是一個最不適合用過去的成功指導下一波策略設計的領域，無論你過去的領域和這個領域有多相像，你過去的成功經驗都只能拿來參考，不適合用來拷貝。
因爲即使是完全相同的領域，時間已經不同了，行業生態，技術發展已經不同了，你面對的人不同了，業務的瓶頸已經不同了，生態的各個利益體的投資已經不同了，成熟的領域人員可能減少，當初的績優股可能已經失敗，你面對的是一個新的領域，我們做架構，永遠不能被過去的 “定義”，左右了我們的判斷。所以，做新的架構設計，你可以參考過去的成功 pattern，但你的分析，必須建立在現在的條件上，不能離開對現在問題的調查，直接打算使用過去的模式。
這是我對我們進行產品戰略設計的第一個建議。
架構設計是一個非常微妙的設計領域，它是完全建立在形而上的邏輯上的，它是抽象的，非具象的。但這種抽象必須要以可以實施爲底線，否則就淪爲紙上談兵了。所謂高以下爲基，貴以賤爲本。所以，我們不要出現 “架構上我們應該如何如何，但我們現在人力不足啊” 這樣的思維角度，這是廢話，架構就是建立在準備實施這個角度上的，你不能把架構設計和實施隔離，說一堆 “我們要如何如何，只是某某條件不成熟。” 這樣的鬼話，如果某某條件不成熟，你就不該做出這個設計來浪費我們的時間。
架構設計是實施團隊的一部分，沒有獨立於實施的架構設計。架構設計 90% 的工作是輔助實施團隊實施架構戰略和挑戰架構戰略，不是實施之外的獨立設計。把人分離出來是爲了保證投入，不是爲了讓這個團隊成爲實施團隊的競爭者。
但反過來說，你不能說我們現在只有多少多少人，我們就做一個基於現在有多少人的方案，因爲事情是變化的，在架構設計初期，給你很多的人，你也用不了，人力多了是個累贅，看在財報上每個月花出去的錢就讓人害怕，但如果你的設計只是現在有多少人，那後面開始展開了，你根本就發展不了。沒有準備，未來有可能給你補人你也接收不了。如果人力不是這樣從小到多的一個變化過程，我們也不需要架構設計，架構設計必須可以響應這種人力，資源，市場等各方面的變化。
所以，我們從一開始就做好了做這種多步的策略的打算，考慮整體目標的時候，要用整個市場域的機會作爲我們發展的上限，在實施的時候，要考慮好怎麼一步步增強投資者和市場的信心，從而可以有序擴大整個業務，不要用 “我的架構沒有錯，錯的是市場，錯的是人力資源沒給夠人，錯的是……” 來給自己做理由。架構設計包括對這些 “別人的錯” 的預判。架構設計和實施是和整個產品的所有其他力量（開發，銷售，維護，財務，法務等等）融合在一起的，沒有獨立於這些開發力量的架構設計。
這是第二個建議。
但對於這個建議，我有個直接的工作技巧可以分享。當我們確切落筆寫一個架構設計的時候，要考慮：以客戶爲目標，以工程爲準繩。
什麼意思呢？就是說，你在架構設計的第一個部分，要明確說你打算賣一個什麼樣的東西到市場上去，你的客戶打算買你的東西，這個決定的控制要素是什麼？有這樣一個標準在最前面，我們中間的所有變化，遇到的障礙，我們都知道往哪裏繞。也知道我們繞完了，應該繼續向什麼方向走。
而在你的架構設計的最後一段，你要把你的所有設計落實爲 “版本” 和“項目”。所有的人力管理，都是以項目爲基礎的，因爲項目有確切的目標和人力資源投入，而不是 “小李你去幫幫他們” 這種盡力而爲的東西，架構策略一旦展開，所有人都會面對無限的要求，沒有確切的資源分割，凡是長遠的東西都會被忽略和放棄。所以，要把架構策略得以實施的希望建立在人力資源管理上，不要建立在 “期望”，“正義”，“道德”，“道理” 這些依賴上。所謂子非不辨也，老子忙起來誰都不認也。
當然，我這裏說的項目，是廣義的項目，不一定是你流程中說的那個項目。
而項目，要輸出確切的版本，你有硬件，有軟件，有插件，這些都是有版本的，不要說什麼做一個 my-wonderful-app，裏面支持這特性，那特性的。
你的軟件上了市場，遇到一堆的客戶，這些客戶的要求都會不一樣，你是用一個版本還是用多個版本去響應他們？產品是會有 Bug 的，是要有新特性開發的，修復 Bug 和增加新特性是會引入新的 Bug 的，所以，客戶可能可以接納升級你修復他的 Bug 的版本，可不一定肯接納你發佈的修復其他人問題的版本的。
這樣，你在市場上就會有很多版本，這是天然的，版本一多，開發，測試，維護，管理的成本會大幅上升，這是一個重要的工程控制要素。你用 my-wonderful-app 這一個概念來考慮你的設計，你實施的時候就會怎麼搞怎麼不正常，因爲你以爲你開發的是 my-wonderful-app，其實你開發的是 my-wonderful-app-v1、my-wonderful_app-v2、my-wonderful-app-v2.1、my-wounderful-app-v2.1-without-tso-llvm_v7_specific-edition…… 你對人力和項目的預判都是錯誤的，當然執行不下去了。
所以，很多人其實不明白 “開源交付” 是個什麼東西，開源交付其實是一種減少版本的方法，一個源代碼樹是可以編譯出很多二進制版本的，我給你源代碼，編譯產生多個版本的的維護成本就是你的了，很多人以爲交付源代碼是對用戶友好，是爲行業做貢獻——那得看客戶是想當你的競爭對手，還是想解決他的問題了。（但即使你用 “源代碼交付”，如果是商業交付，你的測試還是需要落實到一組二進制版本上的，而且你必須很清楚，這些二進制版本都是會升級的，死版本支持的生態是死的生態）
但無論如何，架構設計一個基本的要求，高以下爲基，不要離開你的工程成本想得天花亂墜，只要涉及工程，什麼美好想法都得給我從天上掉下來。
第三個建議：調查和設計也是要結合起來的。架構設計初期，我們有無數的 “未知”：競爭對手的戰略是什麼？客戶的期望是什麼？研究機構有什麼新的突破？市場份額的預測是什麼？國家政策的走向是什麼？……
如果你要調查完這些東西才做決定，你就永遠都不用做了。所以，進行架構設計，要勇敢進行 “猜”，“預判”，哪怕錯了，你也要 “猜”，因爲這是架構設計工作的基礎。你的決策要同時決策：使用猜這個結論和再調查一下，哪個投資收益比更低？然後就要去實施。我在這個專欄中經常強調 “守弱”，其本質就是這個：架構本身就是一種猜，我們在猜的基礎上執行，如果你非要維護面子，在執行的時候收到當時猜錯了的反饋，你死要面子不肯調整，那這個架構執行就失敗了。
所以，做架構不能要面子，你眼中只能有產品的最後成功，到成功的時候，你坐在那裏，旁邊的人說什麼，你都可以冷冷看着他，由他講他的道理，你根本不用在乎。
這樣就要提到第四個建議了：你不要指望實施團隊會很喜歡你，你做的所有事情，都是爲了未來讓他們 “繞路” 走，你的結論他們不會喜歡的。你可以用你所有的個人魅力去儘量 soften 這種衝突，你可以下去和他們一起分擔開發調試的壓力，讓他們沒有那麼恨你，但你要知道，如果實施團隊很舒服，你的架構設計肯定變成在旁邊說胡話了，根本沒有設計效果。
所以，你決定來做架構了，就不要期望你有多 nice。這是這個工作的特性，不能調和的。不要爲了實施團隊的一般抱怨就去改變你的設計去迎合，否則產品失敗的時候，就沒有人跟你抱怨了。吾之所以有大患者，爲吾有身，及吾無身，何患之有？你應該多聽實施團隊的抱怨，但你要分清楚哪些是真正在反饋問題，哪些只是你戰略實施的成本。
最後一個建議：架構團隊來自不同的領域，不要用 “領域代表” 看待自己。不要說我只是做芯片設計，我只是做安全的，我只是做內核的，我只是做數據庫的。架構團隊存在的目的，就是爲了設計那些多個模塊互相甩鍋的 Gap，然後所有模塊和協同起來，達到最優的效率。你盡然進來架構組了，你就不是某個模塊的 “甩鍋代表”，你就是整個產品。
大部分投資者都是不懂技術的，就算他們來自技術背景，他們對你實施的這個技術也是外行，因爲細節只是我們知道，否則他就不用你來做了，他自己做就好了。這些人決策的方式就是 “多方確認”。
如果架構組自己都達不成共識，各說各話，那怎麼說服投資人（其實包括準備用你的客戶），所以，架構組每個人都應該對整個架構策略都很熟悉。我不要求做芯片的人就會寫程序，但我需要做芯片的人知道軟件部分的構架要求，在解決方案中所處的地位。你不要告訴我你只懂 UEFI，不懂 Kernel 是怎麼做的，我需要你知道 ACPI 表那些信息是給 Kernel 的哪個模塊看的，你不是在做實施，等着別人給要求，你是那個負責知道少給一張 EINJ 表，Kernel 會不會起不來的人。
推廣起來說，作爲一個產品的架構團隊，你也不能只管 “我的產品如何如何”，你必須從整個產業生態上開始設計。狼喫羊，羊喫草，你不能說你是狼，不管羊的死活。沒有羊了，狼也死了。做架構設計的人，必須知道狼可以喫多少羊，喫到什麼時候就要開始收手了。
所以，對於一個產品的架構師，必須知道整個生態鏈是怎麼運作的，要爲了整個生態的平衡，不怕把自己部分自己的業務讓給其他產品，其他企業，也不怕自己背上別人不肯實施的業務，這樣你纔會有掌控生態的力量。
大概就是這樣一些吧，再往下，就是具體業務怎麼做的問題的。但當我們碰到困難的時候，不妨回頭來看看我們的總體思路，也許覺得無路走的時候又發現有路了，覺得很順利的時候，說不定就是危機的開始了。
來源：https://zhuanlan.zhihu.com/p/141027477
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/fywVIRLE8sJp1EeMwxYnlQ