作者 | 曹春暉
來源 | 碼農(nóng)桃花源
架構(gòu)的腐化是必然的，不以人的意志為轉(zhuǎn)移。
我們先從一個故事開始，從前有一個公司，這個公司有一個部門，這個部門里有兩個組。
兩個組做的項目比較類似，都是策略類項目。
其中一個組做需求基本靠堆人，業(yè)務(wù)和 PM 的所有需求，能找到人，并且讓這個人在各種場景，各種模塊，各種分支里加 if else 就可以搞定，代碼膨脹飛快。很快沒人能說得清項目內(nèi)的細節(jié)，但是公司業(yè)務(wù)涉及的策略又很多，需求做不過來，所以瘋狂堆人，小組規(guī)模迅速膨脹到幾十個人。大家都很忙碌，充實，每天都在加班，就是代碼稍微有點看不懂，但這不重要。重要的是大家都很充實且周報飽滿。小組 leader 也高升了，可謂皆大歡喜。
另一個小組做項目，老是喜歡做一些設(shè)計，接需求的時候總是邊做邊停，但是發(fā)展了一段時間以后，似乎剩下的工作就非常地簡單而單薄，組員們寫寫配置，寫寫工作流。這都嫌麻煩又做了個前端，所以每天的工作變成了點點鼠標(biāo)，再后來他們又覺得太麻煩。點鼠標(biāo)的工作扔給業(yè)務(wù)去做。這些程序員就顯得每天特別閑。很快變成老板的眼中釘，隨便找個理由就把這個組拆掉去做更“核心”的業(yè)務(wù)了。
如果你在推崇田園敏捷的互聯(lián)網(wǎng)公司工作（也許已經(jīng)沒有不是這樣的公司了），可能每天都在經(jīng)歷著類似的故事。所謂太陽底下沒有新鮮事，不幸的人都有著相同的不幸。
問題到底出在哪里呢？
互聯(lián)網(wǎng)行業(yè)向國外學(xué)習(xí)，推崇敏捷開發(fā)，但實際上學(xué)習(xí)到的只不過是表面敏捷，只考慮交付敏捷，很多時候不考慮開發(fā)。所以他們看上去是敏捷開發(fā)，實際上可能連瀑布模型都不如。瀑布模型是什么樣的？
瀑布模型需要做詳細的需求調(diào)研，和長時間的設(shè)計規(guī)劃，所以在互聯(lián)網(wǎng)公司一日十年的發(fā)展速度下被人詬病。而現(xiàn)代的互聯(lián)網(wǎng)公司又都是業(yè)務(wù)驅(qū)動，顯著的特點是不管你看上去多么簡單的軟件，背后都有極其龐大而復(fù)雜的流程、策略系統(tǒng)。一個中型互聯(lián)網(wǎng)公司的業(yè)務(wù)代碼，單單流程可能就已經(jīng)有幾百萬行。在持續(xù)演進過程中，業(yè)務(wù)本身又會持續(xù)變化。可能是策略變化，可能是流程變化，可能是領(lǐng)域變化，也可能是因為被競爭對手打得滿地找牙需要自己主動做架構(gòu)變化。瀑布模型這種需要長期做規(guī)劃，并且規(guī)劃以后沒法變的工作方式確實不適合互聯(lián)網(wǎng)公司。
悲劇的是，丟掉了瀑布模型，人們不只丟掉了流程，甚至把設(shè)計環(huán)節(jié)也完全丟掉了。大多數(shù)敏捷開發(fā)的流程圖里也并沒有把設(shè)計當(dāng)回事，看看 Scrum 概念里，每個敏捷迭代周期的 planning 部分：
Scrum methodology advocates for a planning meeting at the start of the sprint, where team members figure out how many items they can commit to, and then create a sprint backlog – a list of the tasks to perform during the sprint.
為了體現(xiàn)出工作態(tài)度，工程師必然本能地避開重構(gòu)工作，這些業(yè)務(wù) task 才是能讓我寫周報加班晉升的好寶貝。多多益善，充分體現(xiàn)工作量。項目質(zhì)量什么的，跟我有啥關(guān)系。
有時系統(tǒng)確實太復(fù)雜了，普通工程師搞不定了，也會有個裝模作樣的設(shè)計階段，像瀑布模型那樣的，專門拿一兩個周來做。不過也只是架構(gòu)師們聚在一起，設(shè)計一個看起來能跑的最初的 POC 架構(gòu)，一旦軟件進入開發(fā)階段，架構(gòu)師們可能就已經(jīng)逃之夭夭去參加下一個復(fù)雜的項目設(shè)計了。
軟件的后期迭代和進化架構(gòu)師們往往是不參與的。業(yè)務(wù)的變化又不會少數(shù)人的意志為轉(zhuǎn)移，隨著變化，一定會有那些并不適合放進最初設(shè)計中的需求出現(xiàn)，這時候架構(gòu)師遠在天邊。工程師們排期又緊，那就只能先臨時用丑陋的方案把需求實現(xiàn)。在系統(tǒng)里留下技術(shù)債。
這種“不適合融入既有架構(gòu)”的需求事件出現(xiàn)在什么時間點，誰也說不清楚。給每個項目都安排長期跟進的架構(gòu)師，而項目又一直沒出現(xiàn)大的變化，又會變成資源浪費。架構(gòu)師日常的工作如果不是跟進某個項目，這個項目碰到問題的時候，需要再做設(shè)計評審，臨時抱佛腳找架構(gòu)師來 review，大多也是走馬觀花。
這還真是有點兩難。
這種情況下，最合適的還是在團隊內(nèi)部培養(yǎng)合適的人選承擔(dān)組內(nèi)架構(gòu)師的職責(zé)，負責(zé)一定的重構(gòu)、設(shè)計和架構(gòu)工作，但這個要求不見得總是可行。大家都是混口飯吃，不讀書不學(xué)習(xí)不求上進的程序員何其多，一個幾百人業(yè)務(wù)技術(shù)部門，可能真的遇到幾個組都沒有一個合格的架構(gòu)師的情況。即使有能力，也可能沒時間。一線工程師還是眼睜睜地看著系統(tǒng)一步步變成 shit。
回到開頭的故事。以上帝視角來看，我們考慮的理想與非理想狀況對于在故事中的角色們來說也并不公平。即使能有合理的流程，從外部招到公司的“架構(gòu)師”很多也只不過只是工齡長罷了，言必談 DDD，中臺，戰(zhàn)略，一到了落地環(huán)節(jié)提不出合理的見解和建議。也有掛著架構(gòu)師的頭銜，實際上卻是個“管理專家”，在催進度上更在行。何況對于某些人來說，沒有合理的架構(gòu)，從結(jié)果上來說可能更好。這和互聯(lián)網(wǎng)行業(yè)扭曲的價值觀相匹配，大多數(shù)時候衡量身價是用一個人的 小弟數(shù)目*公司光環(huán)加成，用簡單的算術(shù)就能算出來，可喜可賀。這樣大家的奮斗目標(biāo)都是怎么樣招更多的小弟，系統(tǒng)做成什么樣根本無所謂啦。
能碰到一個靠譜的架構(gòu)師，對于一個一線工程師來說，很多時候也是奢望。對于那些中小公司的人來說，可能就是絕望。
怎么避開這種絕望？只能憑運氣，從客觀規(guī)律來講，大公司也是從小公司中公司發(fā)展而來，在它發(fā)展的前期階段，靠譜的架構(gòu)師 90% 不會愿意加入，而公司真的做大了，可能你手邊系統(tǒng)的架構(gòu)問題已經(jīng)被靠譜的架構(gòu)師解決完了，至少短時間內(nèi)不會遇到問題。如果你不是陪著公司長大，很難體驗到優(yōu)秀的架構(gòu)能給自己的日常工作帶來多大的收益。
所以這是一個無解的問題。對于一個工程師來說，平常還是要多多學(xué)習(xí)，一方面提高個人實力，能夠承擔(dān)更高級的工作職責(zé)，實力強大了也可以有更多選擇。至于那些外來的和尚，一般情況下都是指望不上的。
PS. 開頭的故事是我編的。
