程序员的焦虑从何而来？

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

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

所以焦虑的同学在焦虑什么呢？我看很多同学焦虑的是，又出了新的语言，新的框架，自己要跟不上了。我只能说，如果你在焦虑语言和框架的时候，你就已经跟不上了。

欢迎加入学习群【892643663】，获取全套免费C/C++企业实战级课程资源（素材+源码+视频）和编译大礼包

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

后端开发，乱中求稳

比如做后端的用 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 自身标准不停变化，浏览器标准不停变化。

你想以一己之力做个还算完美的前端框架，全国到现在也只有 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 天生就不是一个省油的灯。

欢迎加入学习群【892643663】，获取全套免费C/C++企业实战级课程资源（素材+源码+视频）和编译大礼包

随着厂家的加盟，史上最恐怖的 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++程序员往往语重心长地教育其它领域的程序员，做系统底层核心才是正统。从业多年，我从一开始的站在鄙视链中，到现在对各类语言和框架心存敬意，是因为我亲身体会到了构架各方面的各种痛苦。

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

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

欢迎加入学习群【892643663】，获取全套免费C/C++企业实战级课程资源（素材+源码+视频）和编译大礼包

编程语言 程序员 c语言 C 语言

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。