架構的腐化是必然的，不以人的意志為轉移。

我們先從一個故事開始，從前有一個公司，這個公司有一個部門，這個部門里有兩個組。

兩個組做的項目比較類似，都是策略類項目。

其中一個組做需求基本靠堆人，業務和 PM 的所有需求，能找到人，并且讓這個人在各種場景，各種模塊，各種分支里加 if else 就可以搞定，代碼膨脹飛快。很快沒人能說得清項目內的細節，但是公司業務涉及的策略又很多，需求做不過來，所以瘋狂堆人，小組規模迅速膨脹到幾十個人。大家都很忙碌，充實，每天都在加班，就是代碼稍微有點看不懂，但這不重要。重要的是大家都很充實且周報飽滿。小組 leader 也高升了，可謂皆大歡喜。

另一個小組做項目，老是喜歡做一些設計，接需求的時候總是邊做邊停，但是發展了一段時間以后，似乎剩下的工作就非常地簡單而單薄，組員們寫寫配置，寫寫工作流。這都嫌麻煩又做了個前端，所以每天的工作變成了點點鼠標，再后來他們又覺得太麻煩。點鼠標的工作扔給業務去做。這些程序員就顯得每天特別閑。很快變成老板的眼中釘，隨便找個理由就把這個組拆掉去做更“核心”的業務了。

如果你在推崇田園敏捷的互聯網公司工作（也許已經沒有不是這樣的公司了），可能每天都在經歷著類似的故事。所謂太陽底下沒有新鮮事，不幸的人都有著相同的不幸。

問題到底出在哪里呢？

互聯網行業向國外學習，推崇敏捷開發，但實際上學習到的只不過是表面敏捷，只考慮交付敏捷，很多時候不考慮開發。所以他們看上去是敏捷開發，實際上可能連瀑布模型都不如。瀑布模型是什么樣的？

瀑布模型需要做詳細的需求調研，和長時間的設計規劃，所以在互聯網公司一日十年的發展速度下被人詬病。而現代的互聯網公司又都是業務驅動，顯著的特點是不管你看上去多么簡單的軟件，背后都有極其龐大而復雜的流程、策略系統。一個中型互聯網公司的業務代碼，單單流程可能就已經有幾百萬行。在持續演進過程中，業務本身又會持續變化?？赡苁遣呗宰兓?#xff0c;可能是流程變化，可能是領域變化，也可能是因為被競爭對手打得滿地找牙需要自己主動做架構變化。瀑布模型這種需要長期做規劃，并且規劃以后沒法變的工作方式確實不適合互聯網公司。

悲劇的是，丟掉了瀑布模型，人們不只丟掉了流程，甚至把設計環節也完全丟掉了。大多數敏捷開發的流程圖里也并沒有把設計當回事，看看 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.

為了體現出工作態度，工程師必然本能地避開重構工作，這些業務 task 才是能讓我寫周報加班晉升的好寶貝。多多益善，充分體現工作量。項目質量什么的，跟我有啥關系。

有時系統確實太復雜了，普通工程師搞不定了，也會有個裝模作樣的設計階段，像瀑布模型那樣的，專門拿一兩個周來做。不過也只是架構師們聚在一起，設計一個看起來能跑的最初的 POC 架構，一旦軟件進入開發階段，架構師們可能就已經逃之夭夭去參加下一個復雜的項目設計了。

軟件的后期迭代和進化架構師們往往是不參與的。業務的變化又不會少數人的意志為轉移，隨著變化，一定會有那些并不適合放進最初設計中的需求出現，這時候架構師遠在天邊。工程師們排期又緊，那就只能先臨時用丑陋的方案把需求實現。在系統里留下技術債。

這種“不適合融入既有架構”的需求事件出現在什么時間點，誰也說不清楚。給每個項目都安排長期跟進的架構師，而項目又一直沒出現大的變化，又會變成資源浪費。架構師日常的工作如果不是跟進某個項目，這個項目碰到問題的時候，需要再做設計評審，臨時抱佛腳找架構師來 review，大多也是走馬觀花。

這還真是有點兩難。

這種情況下，最合適的還是在團隊內部培養合適的人選承擔組內架構師的職責，負責一定的重構、設計和架構工作，但這個要求不見得總是可行。大家都是混口飯吃，不讀書不學習不求上進的程序員何其多，一個幾百人業務技術部門，可能真的遇到幾個組都沒有一個合格的架構師的情況。即使有能力，也可能沒時間。一線工程師還是眼睜睜地看著系統一步步變成 shit。

回到開頭的故事。以上帝視角來看，我們考慮的理想與非理想狀況對于在故事中的角色們來說也并不公平。即使能有合理的流程，從外部招到公司的“架構師”很多也只不過只是工齡長罷了，言必談 DDD，中臺，戰略，一到了落地環節提不出合理的見解和建議。也有掛著架構師的頭銜，實際上卻是個“管理專家”，在催進度上更在行。何況對于某些人來說，沒有合理的架構，從結果上來說可能更好。這和互聯網行業扭曲的價值觀相匹配，大多數時候衡量身價是用一個人的 小弟數目*公司光環加成，用簡單的算術就能算出來，可喜可賀。這樣大家的奮斗目標都是怎么樣招更多的小弟，系統做成什么樣根本無所謂啦。

能碰到一個靠譜的架構師，對于一個一線工程師來說，很多時候也是奢望。對于那些中小公司的人來說，可能就是絕望。

怎么避開這種絕望？只能憑運氣，從客觀規律來講，大公司也是從小公司中公司發展而來，在它發展的前期階段，靠譜的架構師 90% 不會愿意加入，而公司真的做大了，可能你手邊系統的架構問題已經被靠譜的架構師解決完了，至少短時間內不會遇到問題。如果你不是陪著公司長大，很難體驗到優秀的架構能給自己的日常工作帶來多大的收益。

所以這是一個無解的問題。對于一個工程師來說，平常還是要多多學習，一方面提高個人實力，能夠承擔更高級的工作職責，實力強大了也可以有更多選擇。至于那些外來的和尚，一般情況下都是指望不上的。

PS. 開頭的故事是我編的。

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的架构的腐化是必然的的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。