首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >程序员对于编程语言和框架焦虑感,累了,跟不上了?

程序员对于编程语言和框架焦虑感,累了,跟不上了?

作者头像
一墨编程学习
发布2018-12-27 15:57:39
6910
发布2018-12-27 15:57:39
举报

出了新的语言,新的框架,自己要跟不上了?如果你的焦虑感来自语言和框架的时候,就要看你所处的工作方向,如果是做开发,特别是前端开发,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。

但 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)在移动世界一统江湖,千秋万代。

后端开发,乱中求稳

比如做后端的用 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 开发就一个字:变!

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2018.12.19 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云开发 CloudBase
云开发(Tencent CloudBase,TCB)是腾讯云提供的云原生一体化开发环境和工具平台,为200万+企业和开发者提供高可用、自动弹性扩缩的后端云服务,可用于云端一体化开发多种端应用(小程序、公众号、Web 应用等),避免了应用开发过程中繁琐的服务器搭建及运维,开发者可以专注于业务逻辑的实现,开发门槛更低,效率更高。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档