作者 ｜ 段和塵

文章標題很隨意，些微有一些騙點擊的“賊意”;但內容卻是充滿了誠意，想必你已經感受到了。

這是一次源于頭條 Android 客戶端軟件架構問題的探討，之所以冠上“嘴炮”之名，是因為它有一些務虛;同時又夾雜了一些方法論，不僅適用于客戶端軟件架構，也適用于其他工作場景，希望對大家有所幫助。

為了拉滿讀者的帶入感，且以“我們”為主語，來看架構的挑戰、判斷和打法。

我們的挑戰期望高

優秀的公司對架構都有著很高的期許，都希望有一個良好的頂層設計，從上到下有統一的認知，遵循共同的規范，寫出讓人舒適的代碼，甚至有那么一丟偷懶，有沒有“一勞永逸”的架構設計可保基業長青?

然而高期望意味著高落差，面對落差，我們容易焦慮：

代碼什么時候能寫的看上去本就應該是那個樣子;而現在怎么就像是在攀登“屎山”呢?

文檔什么時候能寫的既簡明又詳細;而現在怎么就簡明的看不懂，詳細的很多余呢?

工具什么時候能更好用更強大一點;而現在怎么就動不動掉鏈子，沒有想要的功能常年等排期呢?

“我”什么時候能從架構工作中找到成就感，而不是搞一搞就想著跑路呢?

責任大

大量問題的最終歸因都是代碼問題：設計不合理、使用不規范、邏輯太晦澀、編碼“坑”太多。

沒有一個單一的團隊能承擔這些問題的責任，我們收到過很多“吐槽”：

這尼瑪誰寫的，簡直不堪入目，看小爺我推倒重來展現一把真正的實力

XX 在這里埋了顆雷，但 XX 已經不管了，事到如今，我也只能兜底搞一把

這壓根就不應該這么用，本來的設計又不是為了這個場景，亂搞怪我咯?

臥槽，這特么是隱藏技能啊，編譯時悄悄改了老子的代碼，找瞎了都沒找到在哪過環節滲透進來的

一方面，口嗨一時爽，我們“吐槽”歷史代碼得到了一時的舒緩;另一方面，也意味著責任也傳遞到了我們：處理得好，我們的產出可能還是一樣會被當作糟粕，但如果處理不好，我們就斷送了業務發展的前程。

事情難

架構面臨的從來不是單一的業務問題，而是多個業務多人協作的交叉問題，負重前行是常態。

業務歷久彌新，歷史包袱疊加新的場景，隨便動動刀子就拔出蘿卜帶出泥。譬如：頭條 2021 年 10 月的版本有 XXXX 組件，相比一年前已經翻倍;類個數 XXXXX;插件 XX 個;倉庫數量 XX 個;ttmain 倉庫權限 XXX 人。(XX 代表數量級，隱去了具體數字，^_^)

技術棧層出不窮，一方面要保持成熟穩定，一方面要積極探索落地。架構的同學要熟悉多種技術棧，譬如：跨端技術在客戶端業務中通常都是多種共存(H5/Hybrid/小程序/Lynx/Flutter)，一個業務到底選用哪種技術棧進行承載，需要耗費多少成本?選定技術棧后存在什么局限，是否存在不可逾越的障礙?

療效慢

我們經常說代碼復雜度高，并把降復雜度作為架構方向的重點工作之一;但影響復雜度的因子眾多，從外部來看，有主觀感受、客觀指標、行業對標三個角度;從內部來看，有工程組織、代碼實現和技術棧三個角度。即便我們很好的優化了工程結構這個因子，短時間內也很難感受到復雜度有一個明顯的下降。

我們常說治理，其實是設計一種機制，在這種機制下運轉直到治愈。

就像老中醫開方子，開的不是特效藥，而是應對病癥的方法，是不是有用的方子，終究還是需要通過實踐和時間的檢驗。希望我們不要成為庸醫，瞎抓幾把藥一燉，就吹噓藥到病除。

我們的判斷

架構問題老生常談

誰來復盤架構問題，都免不了炒一炒“冷飯”;誰來規劃架構方向，都逃不出了“減負”、“重構”、“復用”、“規范”這些關鍵詞。難點在于把冷飯炒熱，把方向落實。

架構方向一直存在

架構并不只局限于一個產品的初始階段，而是伴隨著產品的整個生命周期。架構也不是一成不變的，它只適合于特定的場景，過去的架構不一定適合現在，當下的架構不一定能預測未來，架構是隨著業務不斷演進的，不會出現架構方向做到頭了、沒有事情可搞了的情況，架構永遠生機勃勃。

強制遵循規范： 通常會要求業務公共的組件逐漸下沉到基礎組件層，但隨著時間的推移，這個規范很容易被打破

需要成熟的團隊： 領域專家(對業務細節非常熟悉的角色)和開發團隊需緊密協作，構建出核心領域模型是關鍵。但盲目嘗試 DDD 往往容易低估領域驅動設計這套方法論的實踐成本，譬如將簡單問題復雜化、陷入過分強調技術模型的陷阱

迄今為止，用于商業應用程序的最流行的軟件架構設計模式是大泥球(Big Ball of Mud, BBoM)，BBoM 是“......一片隨意構造、雜亂無章、凌亂、任意拼貼、毫無頭緒的代碼叢林。”

泥球模式將扼殺開發，即便重構令人擔憂，但也被認為是理所應當。然而，如果還是缺乏對領域知識應有的關注和考量，新項目最終也會走向泥球。沒有開發人員愿意處理大泥球，對于企業而言，陷入大泥球就會喪失快速實現商業價值的能力。

——《領域驅動設計模式、原理與實踐》Scott Millett & Nick Tune

復雜系統熵增不斷

只要業務繼續發展，越來越復雜就是必然趨勢，這貼合熱力學的熵增定律。

可以從兩個維度來看復雜度熵增的過程：理解成本變高和預測難度變大。

理解成本：規模和結構是影響理解成本的兩個因素

宏大的規模是不好理解的，譬如：在城市路網中容易迷路，但在鄉村中就那么幾條道

復雜的結構是不好理解的，譬如：一個鐘表要比一條內褲難以理解

當需求增多時，軟件系統的規模也會增大，且這種增長趨勢并非線性增長，會更加陡峭。倘若需求還產生了事先未曾預料到的變化，我們又沒有足夠的風險應對措施，在時間緊迫的情況下，難免會對設計做出妥協，頭疼醫頭、腳疼醫腳，在系統的各個地方打上補丁，從而欠下技術債(Technical Debt)。當技術債務越欠越多，累積到某個臨界點時，就會由量變引起質變，整個軟件系統的復雜度達到巔峰，步入衰亡的老年期，成為“可怕”的遺留系統。

正如飼養場的“奶牛規則”：奶牛逐漸衰老，最終無奶可擠;然而與此同時，飼養成本卻在上升。

——《實現領域驅動設計 - 深入理解軟件的復雜度》張逸

預測難度：當下的籌碼不足以應對未來的變化

業務變化不可預測，譬如：頭條一開始只是一個單端的咨詢流產品，5 年前誰也不會預先設計 Lite 版、抖音、懂車帝等，多端以及新的業務場景帶來的變化是無法預測的。很多時候，我們只需要在當下做到“恰當”的架構設計，但需要盡可能保持“有序”，一旦脫離了“有序”，那必將走向混亂，變得愈加不可預測

技術變化不可預測，譬如：作為一個 Java 開發人員，Lambda 表達式的簡潔、函數式編程的快感、聲明式/響應式 UI 的體驗，都是“真香”的技術變化，而陳舊的 Java 版本以及配套的依賴都需要升級，一旦升級，伴隨著的就是多版本共存、依賴地獄(傳遞升級)等令人膽顫的問題。很多時候，我們不需要也沒辦法做出未來技術的架構設計，但需要讓架構保持“清晰”，這樣我們能更快的擁抱技術的變化

既然注定是逆風局，那跑到最后就算贏。

過多的流程規范反倒會讓大家覺得是自己是牽線木偶，牽線木偶注定會隨風而逝。

我們應該更多“強調”一些原則，譬如：分而治之、控制規模、保持結構的清晰與一致，而不是要求大家一定要按照某一份指南進行架構設計，那既降低不了復雜度，又跟不上變化。“強調”并不直接解決問題，而是把重要的問題凸顯出來，讓大家在一定的原則下自己找到問題的解決辦法。

我們的打法我們的套路是：定義問題 → 確定架構 → 方案落地 → 結果復盤。越是前面的步驟，就越是重要和抽象，也越是困難，越能體現架構師的功力。所以，我們打法的第一步就是要認清問題所在。

認清問題

問題分類

架構的問題是盤根錯節的，將所有問題放在一起，就有輕重緩急之分，就有類別之分。區分問題的類別，就能在一定的邊界內，匹配上對應的人來解決問題。

工程架構：

業務架構：

基礎能力：

標準化：

問題分級

挑戰、問題、手段這些經常混為一談，哪些是挑戰?哪些是問題?那些是手段?其實這些都是一回事，就是矛盾，只是不同場景下，矛盾所在的層級不同，舉一個例子：

我們判斷當前的研發體驗不能滿足業務日漸延伸的需要，這是一個矛盾，既是當下的挑戰，也是當下的一級問題。要處理好這個矛盾，我們得拆解它，于是就有了二級問題：我們的代碼邏輯是否已經足夠優化?研發流程是否已經足夠便捷?文檔工具是否已經足夠完備?二級問題也是矛盾，解決好二級問題就是我們處理一級矛盾的手段。這樣層層遞進下去，我們就能把握住當前我們要重點優化和建設的一些基礎能力：插件化、熱更新、跨端能力。

在具體實踐過程中，基礎技術能力還需要繼續拆解，譬如：熱更新能力有很多(Java 層的 Robust/Qzone 超級補丁/Tinker 等，Native 層的 Sophix/ByteFix 等)，不同熱更方案各有優劣，適用場景也不盡相同。我們要結合現狀做出判斷，從眾多方案汲取長處，要么做出更大的技術突破創新，要么整合已有的技術方案進行組合創新。

勤于思考問題背后的問題

亨利福特說，如果我問客戶需要什么，他們會告訴我，他們需要一匹更快的馬。從亨利福特的這句話，我們可以提煉出一個最直接的問題：客戶需要一匹更快的馬。立足這個問題本身去找解決方案，可能永遠交不出滿意的答卷：尋找更好的品種，更科學的訓馬方式。

思考問題背后的問題，為什么客戶需要一匹更快的馬?可能客戶想要更快的日常交通方式，上升了一個層次后，我們立刻找到了更好的解決方案：造車。

我們不能只局限于問題本身，還需要看到問題背后的問題，然后才能更容易找到更多的解決方案。

認知金字塔

引用認知金字塔這個模型，謹以此共勉，讓我們能從最原始數據中，提煉出解決問題的智慧。

• DATA：金字塔的最底層是數據。數據代表各種事件和現象。數據本身沒有組織和結構，也沒有意義。數據只能告訴你發生了什么，并不能讓你理解為什么會發生。
• INFORMATION：數據的上一層是信息。信息是結構化的數據。信息是很有用的，可以用來做分析和解讀。
• KNOWLEDGE： 信息再往上一層是知識。知識能把信息組織起來，告訴我們事件之間的邏輯聯系。有云導致下雨，因為下雨所以天氣變得涼快，這都是知識。成語典故和思維套路都是知識。模型，則可以說是一種高級知識，能解釋一些事情，還能做預測。
• WISDOM：認知金字塔的最上一層，是智慧。智慧是識別和選擇相關知識的能力。你可能掌握很多模型，但是具體到這個問題到底該用哪個模型，敢不敢用這個模型，就是智慧。

這就是“DIKW 模型”。

循序漸進

架構的問題不能等，也不能急。一個大型應用軟件，并非要求所有部分都是完美設計，針對一部分低復雜性的區域或者不太可能花精力投入的區域，滿足可用的條件即可，不需要投入高質量的構建成本。

以治理頭條復雜度為例：

• 長期的架構目標：更廣(多端復用)、更快(單端開發速度)、更好(問題清理和前置攔截)
• 當下的突出問題：業務之間耦合太重、缺少標準規范、代碼冗余晦澀

細節已打碼，請讀者不要在意。重點在于厘清問題之后，螺旋式上升，做到長期有方向，短期有反饋。

最后

一頓輸出之后，千萬不能忘卻了人文關懷，畢竟謀事在人。架構獅得供起來，他們高瞻遠矚，運籌帷幄;但架構人，卻是更需要被點亮的，他們可能常年在“鏟屎”，他們期望得到認可，他們有的還沒有對象...干著干著，架構的故事還在，但人卻仿佛早已翻篇。