程序員爲何焦慮於編程語言和框架？

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

核心能力是什麼？是架構設計，關鍵細節設計的能力和經驗。在海量服務器設計領域，核心能力，大概包含物理設計和軟件設計。物理設計包含：磁盤存儲設計，內存緩存設計，核心數據結構設計，一致性問題處理，容災設計等；軟件設計方面包含：模塊劃分，接口定義，設計模式應用，核心數據傳輸結構設計等。擁有上面的核心能力，你用 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 一、二、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++程序員每每語重心長地教育其它領域的程序員，作系統底層核心纔是正統。從業多年，我從一開始的站在鄙視鏈中，到如今對各種語言和框架心存敬意，是由於我親身體會到了構架各方面的各類痛苦。

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

這些人，難道不是「核心」？

做者簡介：李輝，德國碩士畢業後，在軟件諮詢業工做多年，涉獵先後端及移動開發構架。如今德國博世智能家居部門任高級軟件工程師。*做者獨立觀點，不表明 CSDN 立場。