如果第二次看到我的文章，歡迎「文末」掃碼訂閱我個人的公眾號（跨界架構師）喲~

每週五11：45 按時送達。 當然了，也會時不時加個餐～

我的第「115」篇原創敬上

大家好，我是Z哥。

這篇文章比較長，有5200+字，不過希望你能耐心看完，特別是程式設計師。

中臺這個詞，最近兩年特別火，它的爆發源於2015年張勇在阿里發出的內部信中提到的“大中臺，小前臺”戰略。隨後吸引了很多人開始“追逐”它。也有很多人開始藉著這概念來掙錢。

任何事物一旦開始受到炒作，很容易讓人失去理性的思考。

我們先不論中臺這個概念能火多久，是不是曇花一現。

它帶來的變化，除了外界大肆宣揚的那些“好處”之外，還有什麼？可能很多人沒有考慮過，不知道你有考慮過嗎？

任何事物都是有兩面性的，並且從多個不同的角度來看待和解讀有時候差異也很大。

如果我們看不到背後更多的資訊，哪怕追逐中臺的道路是一條康莊大道，眾人皆知的那條路上會擠滿著人，競爭的慘烈程度自然不用說，很容易陷入到絕境。

與其是這樣，不如思考一下，它的背後有些什麼沒被大家重視，甚至是忽略的。其中是不是同樣藏著一些機會。

很多人認為中颱好，我們得要去向中臺演進、迭代、變化。因為，

能夠避免重複功能建設和維護帶來的重複投資
打通煙囪式系統間互動的整合和協作成本高昂，更快的響應使用者的新需求，降低試錯成本。
更易於業務沉澱和持續發展。
……

是的，沒錯，這些都是中臺概念看得到的好處。

更是在經過了阿里和馬雲的品牌背書後，把它推上了風口浪尖。

但實際上，體現中臺概念的事情，日常生活中就有很多。簡單來說就是「整合」。比如，

過去你肚子餓了，想分別吃兩家不同的店裡的美食的話你得分別跑兩個地方。而現在，外賣平臺成為了你與商家之間的“中臺”。你只要與外賣平臺打交道，不管是幾個店的食物，都能給你送來。
曾經你用手機打電話，透過電視機看劇，透過收音機聽廣播；現在智慧手機就可以全部滿足你打電話+看劇+聽廣播。這裡，智慧手機就是“中臺”。以後你就可以不用瞭解電視機、收音機怎麼調頻道了，只要在手機上切換不同的APP就好。
瑞士jundao也是一個極其厲害的“中臺”，可以開啤酒瓶、開紅酒瓶、可以切東西等等。
……

你看，減少冗餘、透過「複用」使得投入更少獲得更多，是每個正常理性人都會去考慮和樂於接受的事情，並不是什麼新鮮的東西。

那麼我們來思考一下，為什麼中臺在這個時間節點出現、被宣傳？而不是更早或者更晚？為什麼勢頭越演越烈？

其實大家作為網際網路從業者，心裡也清楚原因。自從17年開始，裁員潮開啟，並且越演越烈。而在這之前的行業熱門的關鍵字還是“融資、估值”，一幅繁榮景象。

另外，最近兩年看到企業倒閉、跑路的新聞變多了。還包括一些知名企業的財務造假。

這些負面的訊息無不體現著企業經營成本高企，入不支出的情況正在蔓延。

從市場上看，現在所謂的爆品、網紅款出現的頻次越來越快，一批爆品的崛起伴隨著另一批爆品的沒落。說明使用者的需求變化也在越來越快，更加的捉摸不定。

再看技術層面。Gartner釋出的2019年8月的技術成熟度曲線中，大量為我們熟知的新技術都處於泡沫和悲觀階段，大家所盼望的新動力源遲遲還未出現。

▲圖片來源於Gartner官網，版權歸原作者所有

在企業成本高企、市場變化速度加快、缺乏新的出路的大背景下，「提效降本」便成了大多數企業的選擇。這是中臺概念受到追捧的宏觀因素。

不過，這些最多算是「天時」和「人和」，缺少了「地利」，這個事情其實還是成不了。

這個「地利」我認為是B/S架構的蓬勃發展。

因為B/S架構讓一個軟體有了做中臺的資本，他讓軟體幾乎完全隱藏到了服務端，在客戶端只留下了小小的一個瀏覽器作為通往軟體的入口。

如此一來，企業擁有了對軟體更高的控制度、可以更自由的作出調整。

包括隨後的移動端發展，也是建立在B/S架構所延伸的思想之上，與曾經的C/S架構已經大相徑庭。

所以你也可以想象一下，假如當下還是一個C/S架構大行其道的時代，做中臺的難度相比現在必然大大增加。甚至，中臺的概念估計還沒提出來呢。

對我們程式設計師群體來說，在這滿足天時、地利、人和的“中臺”背後，還隱藏著另一股暗流在湧動。這股暗流就是我們原來的生存空間在逐漸縮小。

理由有三點。

01 中臺將“三者關係”拆分成了“四者關係”

曾經的軟體系統，只分為硬體、作業系統和軟體，其中作業系統在這裡也可以理解為是一個“中臺”。硬體提供原料，作業系統負責統一排程硬體資源，軟體決定具體用來做什麼。

但是如今這個簡單的三者關係之間插入了一個“第四者”——中臺。

本質上，中臺就是多做了一層抽象，將那些軟體中有共性的、可複用的部分提煉出來，作為一個獨立的、中心化的個體。它的作用和先前的作業系統類似，作為相對更高階的原料，對上層軟體應用提供支援。

Docker，Kubernetes這些技術，甚至包括DevOps，IaaS，FaaS、SOA、微服務這些思想概念，無不如此。

所以，原來的軟體 -> 作業系統 -> 硬體的關係，就變成了。軟體前臺 -> 軟體中臺 -> 作業系統 -> 硬體。

那麼這也就是意味著， 你原來做的工作，現在被分為了兩個部分，分別由兩個人去做，你原來的一部分工作“被抽象沒了”。從某種意義上說，你的能力覆蓋範圍更小了。

02 中臺在大公司才能發揮作用

殘酷的現實是， 中臺對規模越大的系統越有價值，反之則相反。所以，對初創的小企業、包括一些中型企業來說，做中臺的必要性沒有這麼高。

你想，一個企業裡就一兩個系統，而且一天就發生幾十幾百人次的交易、操作，此時中臺有什麼意義？還不如一個單體應用跑的順溜。

可能你會說，這樣的話最多就是沒有變化啊，在這種企業裡，還是原來軟體 -> 作業系統 -> 硬體的關係，相當於還是一個人同時負責前端+後端，能力覆蓋範圍沒有縮小。

其實你錯了，如今大企業自己內部的「中臺」正在不斷地對外輸出。你去看看阿里雲、騰訊雲這些雲商上面的產品，你會發現它們會讓很多原本你認為後端要做的事情變得都不需要做了。

而且這些高複用度的中臺產品作為產品來售賣，自然很容易形成規模效應。所以，從經濟效益上肯定比一個企業自己找幾個程式設計師開發要強。你想想，前者是批發價，後者是零售價，而且還是“私人訂製”的零售價，價效比的高低不言而喻。

03 年輕的初中級程式設計師還在不斷湧入

從我與身邊的人交流之後得到的主觀感受來看，新的初中級程式設計師數量還在不斷增加。

這就相當於原來的那鍋粥不但鍋子正在越來越小，僧反而越來越多。

可能你會說，不是有新的領域嗎？像人工智慧這些。

但是你仔細在身邊觀察一下看看，任何一個行業的發展總是往著越來越縱深方向去的，進入的難度會不斷提高。這些新擴充的領域的門檻已經天然攔掉了一部分人。

所以從這個角度來看，整個市場當中龐大的初中級程式設計師的處境就非常尷尬，因為 相對偏“勞動密集型”的工作崗位會變得越來越少（中臺趨勢將平均開發效率高了）。

而且以後的“勞動密集型”的開發工作中，越來越只剩下兩件事，把業務翻譯成程式碼（其實很多saas軟體把這部分“粥”都吃掉了），以及CRUD（包括呼叫高度封裝好的api）。所以，很多人在抱怨 CRUD太多的問題不但不會減少，還會越來越嚴重。

是不是很絕望？感覺自己以後要麼想辦法擠進巨頭公司、要麼不斷冒著成為“絕頂高手”的風險跟著行業往縱深去走，否則就只能淪落到真正的“碼農”工作。

我們來一起想想怎麼破局？

最近兩年我時不時會想到這個問題，但是我想來想去，發現只有一條路是相對平滑，適合大多數人的。

就是，「 主動擁抱業務」，做「跨界」人才。我這個號的名字裡的跨界也是由此而來。

人類文明的發展，可以想象成一個接“龍”的過程。這個“龍”可以想象成“管道”。每一個管道就是對一件事物的標準化，為的是讓後來者可以更快的經過這個管道到達“當下的最新世界”，而不用再去反覆地重新走一遍前人走過的老路。

舉個例子。比如組合語言只是為了操控計算機，而後的C語言基於它提供了更好的可移植性，再往後的C++基於C語言提供了更好的物件導向（OOP）的能力，進一步提高了程式碼的編寫效率，到如今的Java、C#之類透過語法糖，讓編碼效率再提升了一個檔次。

很多事物都是這樣慢慢演化而來的。

這些“新管道”其實就來源於我們的現實世界。現實世界中的任何一個問題被解決和提煉之後就是一節管道，拼接在所依賴的前一個問題（管道）後面，不斷累加。

中臺就是其中正在提煉和拼接的一節“管道”。

所以，面對這個趨勢，我們與其回頭看，糾結要不要去追逐中臺，做一個完成最後的管道拼接的人。不如向前看，去探尋新的問題，那裡的機會其實更多。

因此我覺得，擁抱業務，去接觸和解決現實問題反而是康莊大道；相比之下，追逐中臺，更像是去擠獨木橋。

利用前人打造的管道，去解決更難、更有挑戰的業務問題，幫助擴充業務的增量，才是我們大部分程式設計師應該去抓住的機會。如果你過去有排斥業務、不屑業務的心態我認為得轉變一下，因為這才是你最好的機會。

程式設計師這個職業已經過了野蠻生長期，未來只有那些願意去精耕細作、去披荊斬棘開路的人，才會被留下。

那麼我們可以怎麼做呢？我再分享三個小建議給你。

01 用產品思維看系統

產品思維的本質是什麼。我的理解就是： 帶著懷疑精神，不斷地尋求更優解，不斷地讓使用者更爽。

這和程式設計師思維中的「確定性」，要麼0要麼1，非黑即白是背道而馳的。產品思維沒有對與錯、好與壞，只有更好、更好、更好。

只有用產品思維來看待一個事物，你才能更深入業務，而不是停留在表面。永遠做一個“程式碼翻譯者”。

你可以試試定期做下面四件事：

梳理你當前工作所涉及的業務範圍。可以用思維導圖來做，便於更好的發散你的思維。
透過分析系統中的資料，得到對這些業務模組的當前情況的主觀判斷，標出高於預期、還是低於預期。
以你對這個業務模組的理解，找到你認為其中最應該關注和提升的環節。再想想從技術角度能夠提供怎麼樣的支援和幫助。
找產品經理聊聊自己看法，碰撞一下自己的思考中有哪些能夠得到認同。對產品經理來說，你的一些想法也會對他產生啟發，甚至被直接採納。

長期以往，你就不知不覺地深入到業務裡去了。

02 在上級的視角看系統

為什麼要從上級的視角來看？

因為他的資訊源比較廣，接收到的資訊量比你大，對事物洞察更接近本質、對重要程度的判斷比你更準確。

但真要做到換位思考其實很難，因為我們大多數人來說，見識、閱歷還不夠豐富。舉個極端的例子，假設見識、閱歷、經驗等方面與你的上級完全沒有重合的地方，那麼無論你怎麼想換位，都換位不到對方的視角上去，因為那個視角對你來說是“不可見的”。

所以，對於 做換位思考我的一個思路是：以人性為主、見識、閱歷、經驗為輔。

不管是誰，歸根到底都是人，自然就逃不開記憶體深處的人性，貪婪、嫉妒、傲慢、自私、衝動、懶惰等等。只是不同的人對其的剋制能力不同罷了。

所以當你站在人性的角度去考慮你上級利益關係，他的重視點自然就出來了。見識、閱歷、經驗這些只是為了更精準的把握這個顆粒度而已。

因此，在你基於你的本能反應做出判斷和理解之前，先緩一緩，多問自己幾個“為什麼”。

他為什麼這麼說？
他當前所重視的是什麼？
這件事做好了或者做砸了，對他的影響是什麼？

03 擁抱新技術，但要止於細節

前兩點都是為了深入業務，但是想要更好的降本提效，甚至是創造增量的話，必然離不開新技術。

新技術自然有其價值，否則也不會有人願意去將它開發出來。但是是否最終得到市場的認可，需要時間來驗證。

所以我的建議是， 如果你現在還不打算用它，那麼你不用去了解它的細節。你只要知道，它有什麼作用？長處和短處分別是什麼？這就夠了。因為如果你後續沒有機會用到它，所有對它的瞭解都浪費了。

比如，你可以先不用去了解某個機器學習演算法是怎麼推導實現的，但是你可以先記下它的優勢在哪裡？缺點是什麼？大家有提到過的使用場景有哪些？這就夠了。

我自己的習慣是，訂閱一些相關的公眾號（手機端）、加入一些圈子（手機端）、收藏一些相關的網站（電腦端），以保持新技術相關資訊的持續攝入。這裡主要要做好兩件事，

為了保證資訊接收的效率，內容高度重合的多個號只要保留一個即可。
對它能用來幹什麼以及缺點做好及時的整理和歸類，便於後續用到的時候快速做出決策判斷。（我自己用思維導圖做，你可以用任何自己喜歡的方式）

關於新技術選型可以參考我之前的文章：程式設計師與新技術之間的「愛」與「恨」。

我們的社會發展是建立在分工協作的基礎上的，分工協作的演變趨勢其實就不斷地做兩件事，「分離」和「生長」。

長到一定程度，顯得臃腫的時候就分離，各自專注一部分發展。各自繼續變得臃腫之後再次分離，不斷地的迴圈。

有點像資料結構中的“樹”的樣子。

所以，眼前的“中臺”也只是一個過渡期，不需要糾結於此，往前看才是更重要的。

好了，我們總結一下。

這篇呢，Z哥先和你聊了一下中臺本質其實就是「整合」，這個理念在日常生活中也到處可見。

其次和你聊了一下中臺得以被大肆宣揚的宏觀因素。

然後，提醒你要注意中臺發展的背後對我們程式設計師的發展會產生的影響，並建議你要重視業務，成為為業務披荊斬棘的開路人。

最後分享了三個建議，「 產品思維看系統」、「 在上級視角看系統」、「 擁抱新技術，但要止於細節」幫助你做好這點。

希望對你有所啟發。

願大家都能踩對節奏，順利進入網際網路行業的下一個階段。

程式設計師與「中臺」的愛恨交錯