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

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

核心能力是什么?是架构设计,关键细节设计的能力和经验。在海量服务器设计领域,核心能力,大概包含物理设计和软件设计。物理设计包含:磁盘存储设计,内存缓存设计,核心数据结构设计,一致性问题处理,容灾设计等;软件设计方面包含:模块划分,接口定义,设计模式应用,核心数据传输结构设计等。拥有上面的核心能力,你用 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。

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

每种框架必然在填了竞争对手的一个坑后,掉入另一个新的坑。除了做框架的那十几个公司或组织的程序员外,都是使用者而不是“核心”掌握者,而那些死掉的框架背后的“核心”程序员,算什么呢?

 

写在最后

 

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

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

这些人,难道不是“核心”?

作者简介:李辉,德国硕士毕业后,在软件咨询业工作多年,涉猎前后端及移动开发构架。现在德国博世智能家居部门任高级软件工程师。*作者独立观点,不代表 CSDN 立场。

转载于:https://www.cnblogs.com/zgq123456/p/10128185.html

展开阅读全文
评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符

Git 实用技巧

11-24
这几年越来越多的开发团队使用了Git,掌握Git的使用已经越来越重要,已经是一个开发者必备的一项技能;但很多人在刚开始学习Git的时候会遇到很多疑问,比如之前使用过SVN的开发者想不通Git提交代码为什么需要先commit然后再去push,而不是一条命令一次性搞定; 更多的开发者对Git已经入门,不过在遇到一些代码冲突、需要恢复Git代码时候就不知所措,这个时候哪些对 Git掌握得比较好的少数人,就像团队中的神一样,在队友遇到 Git 相关的问题的时候用各种流利的操作来帮助队友于水火。 我去年刚加入新团队,发现一些同事对Git的常规操作没太大问题,但对Git的理解还是比较生疏,比如说分支和分支之间的关联关系、合并代码时候的冲突解决、提交代码前未拉取新代码导致冲突问题的处理等,我在协助处理这些问题的时候也记录各种问题的解决办法,希望整理后通过教程帮助到更多对Git操作进阶的开发者。 本期教程学习方法分为“掌握基础——稳步进阶——熟悉协作”三个层次。从掌握基础的 Git的推送和拉取开始,以案例进行演示,分析每一个步骤的操作方式和原理,从理解Git 工具的操作到学会代码存储结构、演示不同场景下Git遇到问题的不同处理方案。循序渐进让同学们掌握Git工具在团队协作中的整体协作流程。 在教程中会通过大量案例进行分析,案例会模拟在工作中遇到的问题,从最基础的代码提交和拉取、代码冲突解决、代码仓库的数据维护、Git服务端搭建等。为了让同学们容易理解,对Git简单易懂,文章中详细记录了详细的操作步骤,提供大量演示截图和解析。在教程的最后部分,会从提升团队整体效率的角度对Git工具进行讲解,包括规范操作、Gitlab的搭建、钩子事件的应用等。 为了让同学们可以利用碎片化时间来灵活学习,在教程文章中大程度降低了上下文的依赖,让大家可以在工作之余进行学习与实战,并同时掌握里面涉及的Git不常见操作的相关知识,理解Git工具在工作遇到的问题解决思路和方法,相信一定会对大家的前端技能进阶大有帮助。
©️2020 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值