程式設計師為什麼焦慮於程式語言和框架？

　　近日讀到一篇文章，作者是做海量分散式伺服器系統設計開發的，文中提到：

　　核心能力是什麼？是架構設計，關鍵細節設計的能力和經驗。在海量伺服器設計領域，核心能力，大概包含物理設計和軟體設計。物理設計包含：磁碟儲存設計，記憶體快取設計，核心資料結構設計，一致性問題處理，容災設計等；軟體設計方面包含：模組劃分，介面定義，設計模式應用，核心資料傳輸結構設計等。擁有上面的核心能力，你用 C/C++，Java，甚至 Python 都可以實現。在這裡，核心競爭能力跟語言其實沒有多大的關係。

 

　　這個我非常同意，職業的核心在於理解專案和業務構架設計，以及各個模組的原理，作者也說了：

　　我上面例舉的兩個例子，所涉及的核心能力，都是老掉牙的東西了。像磁碟儲存設計，記憶體快取的設計，軟體設計模式，都不是什麼新鮮的東西，幾十年如此了，當然會有細微層面的進化。但大致如此。

　　接著作者又說：

　　所以焦慮的同學在焦慮什麼呢？我看很多同學焦慮的是，又出了新的語言，新的框架，自己要跟不上了。我只能說，如果你在焦慮語言和框架的時候，你就已經跟不上了。

　　對於這點我有異議，我覺得我必須給這些同學說句話。於是給作者留了言。我是這麼說的：『這句話我贊同一半，要看你所處的工作方向，如果是後端開發，特別是前端開發，App 開發，必須跟著框架走。只有極少數公司會從頭自研框架，一個完整的專案絕對依賴無數其它的框架，如果完全脫離其它框架不停重複造輪子，肯定得編到吐血。我一個做後端高併發的朋友和你同一個觀點，認為掌握了 C++ 和計算機原理就掌握了世界。但是手寫 0 和 1 並不能脫離框架做出滿足客戶的各類需求。』

　　首先，我並不是反對造輪子，通過造輪子這事，可以更加深入思考底層原理，演算法，會去琢磨別的開發者是怎麼編，為什麼這麼編。

　　後端開發，亂中求穩

　　比如做後端的用 Spring 框架，必須要研究 IOC、DI、AOP 這些原理，還可能會自己手寫一個仿 Spring 的 REST 框架。精通原理會讓你在框架更新時更快地理解變動，和更快地開發，但這並不能減輕各類框架更新時所帶來的痛苦。比如 Spring MVC 從 1 到 2, 3，5，每一次迭代都會有相應的相容問題，你的專案必定依賴數以百計的第三方庫和框架，任何一次官宣迭代都是切膚之痛。

　　從 Spring MVC 到 Spring Boot，這種跨越式的換代更是給後端開發帶來巨大挑戰，更別提 Spring Boot 向 Spring Cloud 微服務的轉變。

　　又或者長期專案中，任何一個小的第三方庫，都可能因為停止更新，或安全隱患帶來無窮無盡的專案重構。你會問，為什麼不自研？

　　專案不會給很多時間和預算，從頭開發。時間成本定死，給你自己造輪子的試錯機會就少。你可以開發一兩個輪子，但開發幾百個輪子是幾乎不可能的任務，小團隊不可能！你可能一個兩個輪子造的非常完美零瑕疵，但是其餘每個輪子的各個方面都考慮到零瑕疵，這也是幾乎不可能的任務。業務需求變化非常大，比如開始設計是圓形，可能最終要六角形輪子。很有可能專案釋出後，客戶又要從六角形輪子變為五角形輪子（尤其在 UX 層面）。另一個例子，訊息佇列，比如金融業有用 RabbitMQ 的習慣，目前看好像 Kafka 效能優於 RabbitMQ，金融為什麼不用。因為 RabbitMQ 推出事務性功能時，Kafka 還沒有，而金融業開發特別強調原子性。但隨著 Kafka 日益完善，很可能金融業開始使用 Kafa 替代 RabbitMQ，這對程式設計師又是挑戰。有人要問為什麼不開始就自研 MQ？

　　中國那麼大，也就阿里才自研了一個 RocketMQ，去哪兒自研了一個 QMQ。而且去哪兒也說了為什麼自研：『MQ 在當時也有很多開源的選擇：RabbitMQ, ActiveMQ, Kafka, MetaQ(RocketMQ 的前身)。首先因為技術棧我們排除了 erlang 開發的 RabbitMQ，而 Kafka 以及 Java 版 Kafka 的 MetaQ 在當時還並不成熟和穩定。而 ActiveMQ 在去哪兒網已經有很多應用在使用了，但是使用過程中並不一帆風順：當機，訊息丟失，訊息堵塞等問題屢見不鮮，而且 ActiveMQ 發展多年，程式碼也非常複雜，想要完全把控也不容易，所以我們決定自己造一個輪子。』

　　構架師選擇框架，第一要素肯定是足夠地茁壯健康。但是就算當時再怎麼茁壯健康，過三五年可能也就是羸弱之軀。因為硬體和網路是不斷迅速發展的，這和底層硬體原理萬年不變不同，構架於底層系統之上的應用框架，迭代速度非常快，框架與框架之間切換間隔也越來越短。

　　所以不少領域的程式設計師才會抱怨跟不上了。

　　為什麼說前端和 App 開發的程式設計師更愛抱怨，因為這兩個領域和底層系統開發以及後端開發相比，更心累。底層系統和後端開發一般是著重一個字：穩，但是前端和 App 開發就一個字：變！

　　前端開發，哀鴻遍野

　　前端開發，離不開 JavaScript、CSS 和 HTML。你可知 05 年 AJAX 剛興起到如今各類前端框架百花爭鳴，中間經歷多大變化？首先是 JS、CSS、HTML 自身標準不停變化，瀏覽器標準不停變化。

　　前端框架從最早的 prototype，到 jQuery，到 Bootstrap，到 Ext JS、Angular、React、Vue。精通 JS 底層的人我見過很多，手寫框架的也很多，但所有人都非常頭疼各類瀏覽器相容性，包括各個框架大版本的相容性，沒有人有精力完善一個完美的框架。比如 Angular 1、2、3 幾乎都是不向下相容的，換你你想不想死？所以當 Vue 作者說要重構 3.0 版本，底下哀嚎一片，我很理解。

　　你想以一己之力做個還算完美的前端框架，全國到現在也只有 Vue 一個，何況還有個 team。對於做商業專案的大多數程式設計師，一邊寫業務程式碼，一邊寫框架？沒幾家能做到，百度、騰訊和阿里，才有自己獨立的前端框架的，而且都是深耕五年以上。

　　而且甲方非常容易對 UX 這個層面指手畫腳，一天換四五個設計非常正常，但是程式設計師就難受了，一個 UX 的小改動，可能是對當前框架做一個大的補丁。

　　App 開發，痛徹心扉

　　最早 Symbian 系統一家獨大，BlackBerry 和 Windows Mobile 吃剩飯時，世界還是一片祥和，程式設計師就三種，一種是會 Symbian C++的，一種是會 JavaME 的，剩下一種會 C#。然後 iOS 和 Android 帶著 Windows Phone 突然出來攪局了，本來是件好事，世界以後無非也就是兩種系統嘛（BlackBerry 和 WP 忽略不計），大不了會 Symbian C++轉行 Objective-C，會 JavaME 的轉行 Android，會 C# 的繼續 .Net。

　　但 Android 天生就不是一個省油的燈。

　　隨著廠家的加盟，史上最恐怖的 Android 系統“碎片化”來了。這意味著 App 開發必須在系統框架這個層面上被迫變化。Android 從 1.0 到 Pie，每一次系統變化，都是非常大的變化，變化到 Google Android 開發團隊自己都在不停地打自己的臉，上個版本說好的 API，這個版本就不能用了，或者你得繞著彎子用。

　　你的團隊可能做了一個很不錯的框架，下個版本，哎呦我去，部分功能被標記為 Deprecated 或者直接禁用了。這也就是 Android 的開源庫在 Github 上一般活不過三年的原因。

　　軟體是一層，硬體碎片化更恐怖，哪一家移動開發公司不是要買幾百臺各類 Android 手機做測試，做各類補丁。這種情況下，你再提自己造輪子？連下輛車長什麼樣都不知道，你還造輪子？

　　關鍵是 Google 自己都認為這輛車有點造殘了，乾脆做一倆新的吧，叫 Fuchsia，如果有一天 Google 宣佈 Android 閉源或者不再更新，而轉向 Fuchsia，同時 App 開發轉向 Flutter 時，對那些抱怨跟不上的程式設計師，你還要批評是因為沒掌握核心？

　　再說 iOS，iOS 程式設計師在早期還笑得出來，這兩年也笑不出了，隨著機型的增多，加上蘋果開始力推 Swift，並且逐漸降低對 Objective C 的支援，他們也漸漸體驗到什麼叫碎片化了。而且每一代 iOS 系統更新，也開始出現 Android 類似的框架相容問題。

　　最後不得不提的 Hybrid App，和跨平臺 HTML5 小程式。從 Cordova、ionic、React 再到各大流量渠道推出的內建“小程式”，期間無數跨平臺框架，前赴後繼地嘗（xī）試（shēng）在移動世界一統江湖，千秋萬代。

　　每種框架必然在填了競爭對手的一個坑後，掉入另一個新的坑。除了做框架的那十幾個公司或組織的程式設計師外，都是使用者而不是“核心”掌握者，而那些死掉的框架背後的“核心”程式設計師，算什麼呢？

　　寫在最後

　　程式開發圈內一直有個認識誤區，各種語言或者各個技術層面之間相互鄙視，而處在鄙視鏈頂端的（有女朋友的）C 或 C++程式設計師往往語重心長地教育其它領域的程式設計師，做系統底層核心才是正統。從業多年，我從一開始的站在鄙視鏈中，到現在對各類語言和框架心存敬意，是因為我親身體會到了構架各方面的各種痛苦。

　　正如汽車生產商的通用方案是在不同系列的車型裡使用同一種發動機，發動機固然是核心，但沒有底盤，車體構架，內飾，電路，中控等工程師，就不能生產一個完整的產品。而且一旦某種車型停產，發動機可能會在新車型中繼續沿用，而其他工程師勢必要投入一個全新的設計工程中。

　　這些人，難道不是“核心”？

　　作者簡介：李輝，德國碩士畢業後，在軟體諮詢業工作多年，涉獵前後端及移動開發構架。現在德國博世智慧家居部門任高階軟體工程師。