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

最新推荐文章于 2023-10-26 13:49:39 发布

CSDN资讯

最新推荐文章于 2023-10-26 13:49:39 发布

阅读量1.4k

点赞数 1

本文链接：https://blog.csdn.net/csdnnews/article/details/85043124

版权

640?wx_fmt=gif

640?wx_fmt=jpeg

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

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

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

640?wx_fmt=jpeg

但 Android 天生就不是一个省油的灯。

随着厂家的加盟，史上最恐怖的 Android 系统“碎片化”来了。这意味着 App 开发必须在系统框架这个层面上被迫变化。Android 从 1.0 到 Pie，每一次系统变化，都是非常大的变化，变化到 Google Android 开发团队自己都在不停地打自己的脸，上个版本说好的 API，这个版本就不能用了，或者你得绕着弯子用。

640?wx_fmt=jpeg