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

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

在海量服务器设计领域，核心能力，大概包含物理设计和软件设计。物理设计包含：磁盘存储设计，内存缓存设计，核心数据结构设计，一致性问题处理，容灾设计等；软件设计方面包含：模块划分，接口定义，设计模式应用，核心数据传输结构设计等。拥有上面的核心能力，你用C/C++，Java，甚至python都可以实现。在这里，核心竞争能力跟语言其实没有多大的关系。

这个我非常同意，职业的核心在于理解项目和业务构架设计，以及各个模块的原理，作者也说了：

我上面例举的两个例子，所涉及的核心能力，都是老掉牙的东西了。像磁盘存储设计，内存缓存的设计，软件设计模式，都不是什么新鲜的东西，几十年如此了，当然会有细微层面的进化。但大致如此。

接着作者又说：

所以焦虑的同学在焦虑什么呢？我看很多同学焦虑的是，又出了新的语言，新的框架，自己要跟不上了。

我只能说，如果你在焦虑语言和框架的时候，你就已经跟不上了。

对于这点我有异议，我觉得我必须给这些同学说句话。我是这么回复作者的的：

这句话我赞同一半，要看你所处的工作方向，如果是后端开发，特别是前端开发，App开发，必须跟着框架走。只有极少数公司会从头自研框架，一个完整的项目绝对依赖无数其它的框架，如果完全脱离其它框架不停重复造轮子，肯定得编到吐血。我一个做后端高并发的朋友和你同一个观点，认为掌握了C++和计算机原理就掌握了世界。但是手写0和1并不能脱离框架做出满足客户的各类需求。

首先，我并不是反对造轮子，通过造轮子这事，可以更加深入思考底层原理，算法，会去琢磨别的开发者是怎么编，为什么这么编。

1-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开发就一个字：变！

1-2. 前端开发，哀鸿遍野

前端开发，离不开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的小改动，可能是对当前框架的做一个大的补丁。

1-3. 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)在移动世界一统江湖，千秋万代。每种框架必然在填了竞争对手的一个坑后，掉入另一个新的坑。除了做框架的那十几个公司或组织的程序员外，都是使用者而不是“核心”掌握者，而那些死掉的框架背后的“核心”程序员，算什么呢？

1. 最后

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