程序员为何焦虑于编程语言和框架？

近日读到一篇文章，做者是作海量分布式服务器系统设计开发的，文中提到：

核心能力是什么？是架构设计，关键细节设计的能力和经验。在海量服务器设计领域，核心能力，大概包含物理设计和软件设计。物理设计包含：磁盘存储设计，内存缓存设计，核心数据结构设计，一致性问题处理，容灾设计等；软件设计方面包含：模块划分，接口定义，设计模式应用，核心数据传输结构设计等。拥有上面的核心能力，你用 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 立场。