文章標題很隨意，些微有一些騙點擊的“賊意”；但內(nèi)容卻是充滿了誠意，想必你已經(jīng)感受到了。
這是一次源于頭條 Android 客戶端軟件架構問題的探討，之所以冠上“嘴炮”之名，是因為它有一些務虛；同時又夾雜了一些方法論，不僅適用于客戶端軟件架構，也適用于其他工作場景，希望對大家有所幫助。
為了拉滿讀者的帶入感，且以“我們”為主語，來看架構的挑戰(zhàn)、判斷和打法。
我們的挑戰(zhàn)
期望高
優(yōu)秀的公司對架構都有著很高的期許，都希望有一個良好的頂層設計，從上到下有統(tǒng)一的認知，遵循共同的規(guī)范，寫出讓人舒適的代碼，甚至有那么一丟偷懶，有沒有“一勞永逸”的架構設計可保基業(yè)長青？
然而高期望意味著高落差，面對落差，我們?nèi)菀捉箲]：
- 代碼什么時候能寫的看上去本就應該是那個樣子；而現(xiàn)在怎么就像是在攀登“屎山”呢？
- 文檔什么時候能寫的既簡明又詳細；而現(xiàn)在怎么就簡明的看不懂，詳細的很多余呢？
- 工具什么時候能更好用更強大一點；而現(xiàn)在怎么就動不動掉鏈子，沒有想要的功能常年等排期呢？
- “我”什么時候能從架構工作中找到成就感，而不是搞一搞就想著跑路呢？
責任大
大量問題的最終歸因都是代碼問題：設計不合理、使用不規(guī)范、邏輯太晦澀、編碼“坑”太多。
沒有一個單一的團隊能承擔這些問題的責任，我們收到過很多“吐槽”：
- 這尼瑪誰寫的，簡直不堪入目，看小爺我推倒重來展現(xiàn)一把真正的實力
- XX 在這里埋了顆雷，但 XX 已經(jīng)不管了，事到如今，我也只能兜底搞一把
- 這壓根就不應該這么用，本來的設計又不是為了這個場景，亂搞怪我咯？
- 臥槽，這特么是隱藏技能啊，編譯時悄悄改了老子的代碼，找瞎了都沒找到在哪過環(huán)節(jié)滲透進來的
一方面，口嗨一時爽，我們“吐槽”歷史代碼得到了一時的舒緩；另一方面，也意味著責任也傳遞到了我們：處理得好，我們的產(chǎn)出可能還是一樣會被當作糟粕，但如果處理不好，我們就斷送了業(yè)務發(fā)展的前程。
事情難
架構面臨的從來不是單一的業(yè)務問題，而是多個業(yè)務多人協(xié)作的交叉問題，負重前行是常態(tài)。
- 業(yè)務歷久彌新，歷史包袱疊加新的場景，隨便動動刀子就拔出蘿卜帶出泥。譬如：頭條 2021 年 10 月的版本有 XXXX 組件，相比一年前已經(jīng)翻倍；類個數(shù) XXXXX；插件 XX 個；倉庫數(shù)量 XX 個；ttmain 倉庫權限 XXX 人。(XX 代表數(shù)量級，隱去了具體數(shù)字，^_^)
- 技術棧層出不窮，一方面要保持成熟穩(wěn)定，一方面要積極探索落地。架構的同學要熟悉多種技術棧，譬如：跨端技術在客戶端業(yè)務中通常都是多種共存(H5/Hybrid/小程序/Lynx/Flutter)，一個業(yè)務到底選用哪種技術棧進行承載，需要耗費多少成本？選定技術棧后存在什么局限，是否存在不可逾越的障礙？
療效慢
我們經(jīng)常說代碼復雜度高，并把降復雜度作為架構方向的重點工作之一；但影響復雜度的因子眾多，從外部來看，有主觀感受、客觀指標、行業(yè)對標三個角度；從內(nèi)部來看，有工程組織、代碼實現(xiàn)和技術棧三個角度。即便我們很好的優(yōu)化了工程結構這個因子，短時間內(nèi)也很難感受到復雜度有一個明顯的下降。
我們常說治理，其實是設計一種機制，在這種機制下運轉(zhuǎn)直到治愈。
就像老中醫(yī)開方子，開的不是特效藥，而是應對病癥的方法，是不是有用的方子，終究還是需要通過實踐和時間的檢驗。希望我們不要成為庸醫(yī)，瞎抓幾把藥一燉，就吹噓藥到病除。
我們的判斷
架構問題老生常談
誰來復盤架構問題，都免不了炒一炒“冷飯”；誰來規(guī)劃架構方向，都逃不出了“減負”、“重構”、“復用”、“規(guī)范”這些關鍵詞。難點在于把冷飯炒熱，把方向落實。
架構方向一直存在
架構并不只局限于一個產(chǎn)品的初始階段，而是伴隨著產(chǎn)品的整個生命周期。架構也不是一成不變的，它只適合于特定的場景，過去的架構不一定適合現(xiàn)在，當下的架構不一定能預測未來，架構是隨著業(yè)務不斷演進的，不會出現(xiàn)架構方向做到頭了、沒有事情可搞了的情況，架構永遠生機勃勃。
- 強制遵循規(guī)范： 通常會要求業(yè)務公共的組件逐漸下沉到基礎組件層，但隨著時間的推移，這個規(guī)范很容易被打破
- 需要成熟的團隊： 領域?qū)＜遥▽I(yè)務細節(jié)非常熟悉的角色）和開發(fā)團隊需緊密協(xié)作，構建出核心領域模型是關鍵。但盲目嘗試 DDD 往往容易低估領域驅(qū)動設計這套方法論的實踐成本，譬如將簡單問題復雜化、陷入過分強調(diào)技術模型的陷阱
迄今為止，用于商業(yè)應用程序的最流行的軟件架構設計模式是大泥球（Big Ball of Mud, BBoM），BBoM 是“......一片隨意構造、雜亂無章、凌亂、任意拼貼、毫無頭緒的代碼叢林。”
泥球模式將扼殺開發(fā)，即便重構令人擔憂，但也被認為是理所應當。然而，如果還是缺乏對領域知識應有的關注和考量，新項目最終也會走向泥球。沒有開發(fā)人員愿意處理大泥球，對于企業(yè)而言，陷入大泥球就會喪失快速實現(xiàn)商業(yè)價值的能力。
——《領域驅(qū)動設計模式、原理與實踐》Scott Millett & Nick Tune
復雜系統(tǒng)熵增不斷
只要業(yè)務繼續(xù)發(fā)展，越來越復雜就是必然趨勢，這貼合熱力學的熵增定律。
可以從兩個維度來看復雜度熵增的過程：理解成本變高和預測難度變大。
理解成本：規(guī)模和結構是影響理解成本的兩個因素
- 宏大的規(guī)模是不好理解的，譬如：在城市路網(wǎng)中容易迷路，但在鄉(xiāng)村中就那么幾條道
- 復雜的結構是不好理解的，譬如：一個鐘表要比一條內(nèi)褲難以理解
當需求增多時，軟件系統(tǒng)的規(guī)模也會增大，且這種增長趨勢并非線性增長，會更加陡峭。倘若需求還產(chǎn)生了事先未曾預料到的變化，我們又沒有足夠的風險應對措施，在時間緊迫的情況下，難免會對設計做出妥協(xié)，頭疼醫(yī)頭、腳疼醫(yī)腳，在系統(tǒng)的各個地方打上補丁，從而欠下技術債（Technical Debt）。當技術債務越欠越多，累積到某個臨界點時，就會由量變引起質(zhì)變，整個軟件系統(tǒng)的復雜度達到巔峰，步入衰亡的老年期，成為“可怕”的遺留系統(tǒng)。
正如飼養(yǎng)場的“奶牛規(guī)則”：奶牛逐漸衰老，最終無奶可擠；然而與此同時，飼養(yǎng)成本卻在上升。
——《實現(xiàn)領域驅(qū)動設計 - 深入理解軟件的復雜度》張逸
預測難度：當下的籌碼不足以應對未來的變化
- 業(yè)務變化不可預測，譬如：頭條一開始只是一個單端的咨詢流產(chǎn)品，5 年前誰也不會預先設計 Lite 版、抖音、懂車帝等，多端以及新的業(yè)務場景帶來的變化是無法預測的。很多時候，我們只需要在當下做到“恰當”的架構設計，但需要盡可能保持“有序”，一旦脫離了“有序”，那必將走向混亂，變得愈加不可預測
- 技術變化不可預測，譬如：作為一個 JAVA 開發(fā)人員，Lambda 表達式的簡潔、函數(shù)式編程的快感、聲明式/響應式 UI 的體驗，都是“真香”的技術變化，而陳舊的 Java 版本以及配套的依賴都需要升級，一旦升級，伴隨著的就是多版本共存、依賴地獄(傳遞升級)等令人膽顫的問題。很多時候，我們不需要也沒辦法做出未來技術的架構設計，但需要讓架構保持“清晰”，這樣我們能更快的擁抱技術的變化
既然注定是逆風局，那跑到最后就算贏。
過多的流程規(guī)范反倒會讓大家覺得是自己是牽線木偶，牽線木偶注定會隨風而逝。
我們應該更多“強調(diào)”一些原則，譬如：分而治之、控制規(guī)模、保持結構的清晰與一致，而不是要求大家一定要按照某一份指南進行架構設計，那既降低不了復雜度，又跟不上變化。“強調(diào)”并不直接解決問題，而是把重要的問題凸顯出來，讓大家在一定的原則下自己找到問題的解決辦法。
我們的打法
我們的套路是：定義問題 → 確定架構 → 方案落地 → 結果復盤。越是前面的步驟，就越是重要和抽象，也越是困難，越能體現(xiàn)架構師的功力。所以，我們打法的第一步就是要認清問題所在。
認清問題
問題分類
架構的問題是盤根錯節(jié)的，將所有問題放在一起，就有輕重緩急之分，就有類別之分。區(qū)分問題的類別，就能在一定的邊界內(nèi)，匹配上對應的人來解決問題。
工程架構：
業(yè)務架構：
基礎能力：
標準化：
問題分級
挑戰(zhàn)、問題、手段這些經(jīng)常混為一談，哪些是挑戰(zhàn)？哪些是問題？那些是手段？其實這些都是一回事，就是矛盾，只是不同場景下，矛盾所在的層級不同，舉一個例子：
我們判斷當前的研發(fā)體驗不能滿足業(yè)務日漸延伸的需要，這是一個矛盾，既是當下的挑戰(zhàn)，也是當下的一級問題。要處理好這個矛盾，我們得拆解它，于是就有了二級問題：我們的代碼邏輯是否已經(jīng)足夠優(yōu)化？研發(fā)流程是否已經(jīng)足夠便捷？文檔工具是否已經(jīng)足夠完備？二級問題也是矛盾，解決好二級問題就是我們處理一級矛盾的手段。這樣層層遞進下去，我們就能把握住當前我們要重點優(yōu)化和建設的一些基礎能力：插件化、熱更新、跨端能力。
在具體實踐過程中，基礎技術能力還需要繼續(xù)拆解，譬如：熱更新能力有很多（Java 層的 Robust/Qzone 超級補丁/Tinker 等，Native 層的 Sophix/ByteFix 等），不同熱更方案各有優(yōu)劣，適用場景也不盡相同。我們要結合現(xiàn)狀做出判斷，從眾多方案汲取長處，要么做出更大的技術突破創(chuàng)新，要么整合已有的技術方案進行組合創(chuàng)新。
勤于思考問題背后的問題
亨利福特說，如果我問客戶需要什么，他們會告訴我，他們需要一匹更快的馬。從亨利福特的這句話，我們可以提煉出一個最直接的問題：客戶需要一匹更快的馬。立足這個問題本身去找解決方案，可能永遠交不出滿意的答卷：尋找更好的品種，更科學的訓馬方式。
思考問題背后的問題，為什么客戶需要一匹更快的馬？可能客戶想要更快的日常交通方式，上升了一個層次后，我們立刻找到了更好的解決方案：造車。
我們不能只局限于問題本身，還需要看到問題背后的問題，然后才能更容易找到更多的解決方案。
認知金字塔
引用認知金字塔這個模型，謹以此共勉，讓我們能從最原始數(shù)據(jù)中，提煉出解決問題的智慧。
DATA： 金字塔的最底層是數(shù)據(jù)。數(shù)據(jù)代表各種事件和現(xiàn)象。數(shù)據(jù)本身沒有組織和結構，也沒有意義。數(shù)據(jù)只能告訴你發(fā)生了什么，并不能讓你理解為什么會發(fā)生。
INFORMATION： 數(shù)據(jù)的上一層是信息。信息是結構化的數(shù)據(jù)。信息是很有用的，可以用來做分析和解讀。
KNOWLEDGE： 信息再往上一層是知識。知識能把信息組織起來，告訴我們事件之間的邏輯聯(lián)系。有云導致下雨，因為下雨所以天氣變得涼快，這都是知識。成語典故和思維套路都是知識。模型，則可以說是一種高級知識，能解釋一些事情，還能做預測。
WISDOM： 認知金字塔的最上一層，是智慧。智慧是識別和選擇相關知識的能力。你可能掌握很多模型，但是具體到這個問題到底該用哪個模型，敢不敢用這個模型，就是智慧。
這就是“DIKW 模型”。
循序漸進
架構的問題不能等，也不能急。一個大型應用軟件，并非要求所有部分都是完美設計，針對一部分低復雜性的區(qū)域或者不太可能花精力投入的區(qū)域，滿足可用的條件即可，不需要投入高質(zhì)量的構建成本。
以治理頭條復雜度為例：
- 長期的架構目標：更廣（多端復用）、更快（單端開發(fā)速度）、更好（問題清理和前置攔截）
- 當下的突出問題：業(yè)務之間耦合太重、缺少標準規(guī)范、代碼冗余晦澀
細節(jié)已打碼，請讀者不要在意。重點在于厘清問題之后，螺旋式上升，做到長期有方向，短期有反饋。
最后
一頓輸出之后，千萬不能忘卻了人文關懷，畢竟謀事在人。架構獅得供起來，他們高瞻遠矚，運籌帷幄；但架構人，卻是更需要被點亮的，他們可能常年在“鏟屎”，他們期望得到認可，他們有的還沒有對象...干著干著，架構的故事還在，但人卻仿佛早已翻篇。
