1、
幾十年前，一幫鑽研國外開源代碼、研究過各個國家傑出軟體工程理論的程式員們，産生了建立一個自主架構的願望。
這些人有的在外企底層做過coding或者打雜，其中一位若幹年後成為了 company 的首席架構師。一些人目睹了另一個龐大軟體王國的四處擴張，威懾天下，心向往之并奉為圭臬，勸說其他人沿襲那個帝國的架構和思想，殊不知那個遠古時代骨子裡就流着邪惡之血的帝國也早已病入膏肓。更多人還是土狼，在國内紅海中曆經磨砺，幾乎每個人都是人中之龍。
這樣一群人聚集起來，在幾十年前定下來了一個大架構，并設定了一個非常宏偉的 vision，但這原本是一位聖賢為他的國度應付幾百萬獨立通路者設定的，又如何能像古代的那些帝國開創者一樣定為“祖宗之法不可變”呢？
2、
龐大的工程就這麼建立了起來，它确實讓 company 獲益，創造了世人矚目的諸多成就，頂住了巨大的以億計的流量沖擊。可人們都知道它隐隐有一個硬傷，沒有太多實踐經驗的那群程式員，雖然早已學習過很多優秀的、行之有效的設計模式，但不知為什麼卻沒有貫徹到他們親手打造的工程裡。
他們留下了太多生硬的接口，工作流多如牛毛，但指導它們運轉的原則卻不那麼清晰，甚至蹩腳。随着時間的流逝，在這些接口上衍生出了太多的應用，有太多的新程式員在這些接口和服務上繼續開發，并嘗試更新系統，但就像多數工程一樣，在一個跑了幾十年的生産系統上，要讓系統繼續不間斷地應付與日俱增的通路量，你隻能零敲碎打修修補補。
無數新程式員學習這個系統的代碼時，都呼籲“重構”“靈活”。但項目總監、産品總監、營運總監們知道，“重構”談何容易，誰能承受為了更新而暫停服務？誰能承擔重構失敗的責任？沒有測試環境，隻有生産環境，你怎麼保證你的重構是正确的。
在原有系統上挂接的各個營運機關要在每一次系統小更新中分一杯羹，在每一個小更新檔上都要嵌入自己的推廣代碼，是以也都不願意自己被砍掉。
你有什麼好辦法？
