最近阿裡拆除中台和CTO下放到業務線做負責人的新聞在網絡上傳播，讓我非常感慨，我以前在一家網際網路SAAS中廠做過架構師，負責産品技術架構的選型和設計，當時正是網際網路公司如日中天的時候，一旦提起架構就會有一堆名詞出來，業務中台，微服務，領域驅動，分布式，高并發，虛拟化，企業的老闆業務出生，對技術一知半解，要是你做架構不把這些名詞放到嘴邊就感覺你什麼都不是一樣，技術架構的選擇跟企業的業務規模、業務模式、研發成本、團隊能力息息相關，如果這些條件不具備，強行推動所謂的架構更新都是在給自己找事，不僅不能為企業創造價值，反而會讓企業付出巨大的研發成本代價和業務損失，一些經驗一般的程式員特别喜歡跟風架構領域的新概念，并以此來彰顯自己的能力，而架構領域每隔幾年就會有新的概念出來，有些是新思維新技術，有些就是新瓶裝老酒，非技術型的老闆在這些程式員的忽悠下很容易做出冒進的決定，把企業帶入坑中，有段時間感覺公司不搞個中台就不是軟體公司了，什麼阿裡都是這麼做的，你不做就是跟不上時代，就是技術落後，感覺搞個中台就企業瞬間要業務提升多少倍，企業就數字化了，把老闆忽悠的一愣一愣的，把務實的架構師夾在中間兩頭為難，站在一個架構師的角度，任何技術的誕生都有其特定的應用場景，脫離場景考慮架構都是耍流氓，是不專業的，這也是很多企業的技術管理者容易踩的坑，隻從技術的時髦性決定是否采用，我認為的正确思維應該是結合企業自己的業務模式和規模循序漸進的推動軟體發展和架構演進，架構演進的同時團隊能力也要演進，今天的大廠無論是國内還是國外沒有哪家是剛起步就架構一步到位的，有些知名的公司甚至經曆了上十輪的架構疊代，整個過程呈螺旋式上升，業務有先進和落後的說法，而技術也無所謂先進和落後，技術的選擇應本着滿足業務需求的同時保留适當的可延展性+成本可控的原則進行，跟風大廠也要看看自己的身闆扛得住不，大廠一次失誤最多就是損失一些錢和商機，中小公司一次失誤帶來的可能就是緻命的危險。#軟體架構# #企業中台建設# #阿裡# #程式員那些事#
