程序员焦虑语言和框架，是因为没掌握核心？

近日看了一篇公众号的文章“写给期待年薪百万的IT同学”，作者是做海量分布式服务器系统设计开发的，文中提到：

核心能力是什么？是架构设计，关键细节设计的能力和经验。

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

又或者长期项目中，任何一个小的第三方库，都可能因为停止更新，或安全隐患带来无穷无尽的项目重构。你会问，为什么不自研？

1. 项目不会给很多时间和预算，从头开发
2. 时间成本定死，给你自己造轮子的试错机会就少。
3. 你可以开发一两个轮子，但开发几百个轮子是几乎不可能的任务，小团队不可能！
4. 你可能一个两个轮子造的非常完美零瑕疵，但是其余每个轮子的各个方面都考虑到零瑕疵，这也是几乎不可能的任务
5. 业务需求变化非常大，比如开始设计是圆形，可能最终要六角形轮子
6. 很有可能项目发布后，客户又要从六角形轮子变为五角形轮子（尤其在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，到Extjs，Angular，React， Vue。精通js底层的人我见过很多，手写框架的也很多，但所有人都非常头疼各类浏览器兼容性，包括各个框架大版本的兼容性，没有人有精力完善一个完美的框架。比如Angular 1、2、3几乎都是不向下兼容的，换你你想不想死？所以当Vue作者说要重构3.0版本，底下哀嚎一片，我很理解。

你想以一己之力做个还算完美的前端框架，全中国也就尤雨溪一个，何况他还有个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程序员在早期还笑的出来，这两年也笑不出了，随着机型的增多，加上苹果开始力推Swift，并且逐渐降低对Objective C的支持，他们也渐渐体验到什么叫碎片化了。而且每一代iOS系统更新，也开始出现Android类似的框架兼容问题。

最后不得不提的Hybrid App，和跨平台HTML5小程序。从Cordova，ionic，React再到各大流量渠道推出的内置“小程序”，期间无数跨平台框架，前赴后继地尝(xī)试(shēng)在移动世界一统江湖，千秋万代。每种框架必然在填了竞争对手的一个坑后，掉入另一个新的坑。除了做框架的那十几个公司或组织的程序员外，都是使用者而不是“核心”掌握者，而那些死掉的框架背后的“核心”程序员，算什么呢？

最后

程序开发圈内一直有个认识误区，各种语言或者各个技术层面之间相互鄙视，而处在鄙视链顶端的（有女朋友的）C或C++程序员往往语重心长地教育其它领域的程序员，做系统底层核心才是正统。从业多年，我从一开始的站在鄙视链中，到现在对各类语言和框架心存敬意，是因为我亲身体会到了构架各方面的各种痛苦。

正如汽车生产商的通用方案是在不同系列的车型里使用同一种发动机，发动机固然是核心，但没有底盘，车体构架，内饰，电路，中控等工程师，就不能生产一个完整的产品。而且一旦某种车型停产，发动机可能会在新车型中继续沿用，而其他工程师势必要投入一个全新的设计工程中。

这些人，难道不是“核心”？

 

发布于CSDN公众号：程序员为什么焦虑于编程语言和框架？