1 前言

这个题目有点大。工作也有些年头,从开始入行的被动接受,什么流行就学什么;到有一些想法,会去思考为什么使用这种技术;再到主动去学习一些前沿框架。

从开始的不理解,事不关已高高挂起,不在其位不谋其政;到也成为了团队中的中坚力量,去据理力争应该使用某些技术,把觉得好的技术安利给同事,试图引入到团队中;有成功有失败;也有迫于种种因素使用一些所谓“过时的技术”,有时候有在想,这种“被迫”或"过时"是“为了技术而技术”吗?

本人从事的是 JAVA 后端开发,从业七八年,时间不长,但也经历了不少。

从需要使用 juqery,easyui 等各种前端技术,到前后端分离成为主流;从一开始的 hibernate+structs/structs2 框架大行其道,到后来几乎消声匿迹;从最初的 redis/memcache 两者之间还能一较长短,到 redis 一统江湖。

从 spring mvc 到言必谈 spring boot,微服务。不来两句服务化,降级限流熔断,高并发你都不好意思出门。

后来转战“大数据”领域。那时 mapreduce 已是明日黄花,strom 以及阿里巴巴主导的汉化版 jstorm 也是江河日下。而 spark 正当其时,如日中天。遂入坑。

到 flink 异军突起,阿里巴巴再出汉化版 blink,与 spark 分庭抗礼,直至略占上风。后来者只知 flink,而鄙视 spark 之风气,怪异而可爱。

从传统关系型数据库到非关系型数据库,NOSql,NewSql,到数据湖,再到兼顾 OLAP,OLTP 的各种分布式数据库如雨后春笋般出现。

这时期的数据库已无法像传统关系型数据库那样三足鼎立(o+m+else)( java 位面下),而是春秋时期百家争鸣的局面,各家大厂根据自身的业务需求订制化了许多产品,包括不限于 Fusion,mariadb,OceanBase,TiDB,ClickHouse,greenplum,dorisdb,kudu 等等。

对于普通开发者,这是好事?坏事?

对于技术团队,这是好事?坏事?

有了更多的选择权?要学的东西更多了?

怎么选择一种技术框架,从是否开源,是否 KPI 开源,开源社区是否活跃/持续/稳定(我没有说阿里,别乱说),是否有国内大厂使用,社区(特别是问答社区)是否活跃,中文资料是否够多,都是影响普通开发者/团队选择某种技术的原因。

下面将从效率(技术本身),环境(开源,社区),团队(负责人/骨干的技术水平和技术偏好)三个方面来谈谈我的看法。

为避免说教的意思,以及倚老卖老(并不老)的嫌疑,首先声明,以上以下只代表个人观点。

2 效率

2.1 没有绝对的效率

我有点害怕技术讨论会上,上来就说据XX公司/官网测试,XX比XX效率高出5%(8%or10%…)

这就有点像面试中上来就问 QPS 多少。不才曾经做过一个广告竞价平台,日均访问量几千万,听起来好像很牛逼的样子,但该系统是纯内存计算,严格限制单次访问时间,这种系统谈 QPS 根本不具备任何横向参考意义。

或者像面试中多次被问到 spark/hadoop 集群多少个节点的问题。我一般会回答一个大概的数字,然后补充一下集群 cpu cores/内存/存储空间总数,必要时补充集群任务数,单日/总处理数据量。如果只是性能空间并不太好的有限物理机,用容器虚拟成上千个节点,那就达到了大厂的集群规模了吗?

只有在控制变量的前提下,谈论单一指标才有意义。

效率并非不重要。但为那点3%的效率牺牲其它东西,值得吗?这是值得衡量的。说句诛心的话,那点性能优势对于绝大多数公司,我觉得可能是你自己想多了。还不如好好优化一下那堆shit山。

2.2 效率是否绝对重要

在RocketMq(阿里牛逼!)没有开源前,消息队列一般有三种选择 RabbitMQ,ActiveMq,ZeroMq。

三者控制变量的前提下,TPS 测试结果表明 ZeroMq 效率最高。但那些年我所待过的公司,我了解到的情况(同事,网络),消息队列基本都在 RabbitMQ,ActiveMq 两者之间选择,鲜少使用 ZeroMq。

这个例子可能并没有很强的说服力。但大概就是这么个意思。

3 环境

3.1 国内开发大环境

最典型的例子就是 mybatis vs hibernate.

除了银行之类的老项目,现在有新项目在使用 hibernate 吗?就算有,hibernate 在国内也早就远离了主流。

可是,在国外,hibernate 依然是绝对的主流。

在 stackoverflow 上的 tags 数量,看对比图,hibernate 热度碾压 mybatis,两者根据不是一个数量级。

按 google 搜索趋势,过去五年,hibernate 的搜索量依然碾压 mybatis。

同样 google 搜索趋势,按国家地区划分。全球范围内,mybatis 热度胜过 hibernate 的,只有东亚地区。中日韩东亚三国最喜欢 mybatis。迷惑。。。

为何会有这种地区之间的巨大差异?有人说是阿里巴巴的带动作用。阿里对国内 JAVA 整体环境的带动和影响是毋庸置疑的,但在 mybatis 之所以流行这件事情上,完全归于阿里,也无法解释韩国和日本同样流行 mybatis 这件事。

不管怎么说,不管公司,团队还是个人,都是一定程度上从众的。既然大环境都在使用 mybatis,那么这样用就不会犯大错。公司好招人,个人也好找工作。大家的成本都在最低,皆大欢喜。

3.2 技术社区的影响

有个笑话,外行人看到程序员在工作,觉得好牛逼,全英文的界面。知乎也常有提问,英语不好,学编程可行吗?

底下回答,很多鼓励,英语跟编程没有太大关系云云。

这句话有毛病吗?

这至少透露出来两层意思。

  • 不是说编程方面英语不重要。英语好,优势巨大。
  • 国内程序员很多英语不好。以本人常年混迹小公司的经验来说,好多程序员连 eclipse 或者 idea 上常用的界面按钮上的单词都认不全。唯手熟尔。不懂就百度。这个很多,是好多,无法统计,但个比例绝对不低。
  • 国内 IT 圈子是一个比较封闭的圈子。虽然,用的技术基本都是发源于国外,但国内的规模保证了资源的足够。比如 spark/flink 不需要去官网阅读一手资料,各个论坛网站上公众号各种二手三手N手的资料满天飞。

有追求的程序员,或者大厂的大佬觉得嗤之以鼻,遇 BUG 先必称看源码,再次 github issue,stackoverflow,搜索必须 google,资料必须原文。

所以英语跟编程没有太大关系,这不是一个疑问,对很多程序员来说,这就是事实。大量分布于各类中小型公司,严重依赖于国内各种社区学习(copy)技术,解(zhi)决(zao)问题,赚钱养家。

国内头部公司/团队用什么,大多数的公司/团队/个人就用什么。

这件事情的另一个力证是 spring cloud vs apache dubbo,两者隐隐有在国内分庭抗礼之势。但在全球范围呢,我就不放 google trend 图了。有点欺负人。

但是因为 apache dubbo 是阿里巴巴出品,进而影响到了国内整个程序员圈子,社区,所以大家也逐渐愿意去用,虽然被之前的开源社区挺尸行为伤过。就像一个渣男,但他是高富帅啊,自带光环。

4 团队

4.1 团队负责人及核心骨干的技术积累以及技术偏好

2017年新公司进行一个流计算项目。当时整个团队都是新组建,尚处于磨合期。当时我个人偏向于 spark streaming,用得比较熟,上手快,能够提前排坑,能快速解决线上问题。但当时的技术负责人在召开技术研讨会,听取各方意见后,决定使用 jstorm。

我当然服从决定。

当时的 jstorm 尚有余晖。而且据说那时 jstorm 在开源社区诈尸了。颇有几分卷土重来的架势。加上当时负责人力排众议,让我觉得很安心,他应该是很懂 jstorm 这项技术栈的。

后来项目顺利上线。再后来,不出意外,运行一段时间,遇到棘手线上问题。几次团队沟通后,我得出一个结论,决定使用 jstorm 的负责人并不了解 jstorm,甚至应该不懂 java 技术栈(客观白描事实,无情绪输出,技术管理者并不一定要懂技术);所以,整个团队最懂 jstorm 的好像就是我了。

肝吧,骚年。在经历了好几个后半夜,并成功在国庆享受了三倍工资(并没有)后,BUG 解决。

后来回想,如果当时上的是 spark streaming 就不会出现同样的问题,就算出现这样的问题,凭借对 spark streaming 的较深入了解,也能够快速解决。

上述这段经历,我想表达什么?

  • 一个程序员的竞争力包括什么?不是会用某一种技术,也不是能够快速上手某种新技术。

    • 学习新技术的欲望,动力,能力;快速上手,保证任务,这些只是基本功。对于新技术,能够利用经验,快速理解原理内幕,预排坑道,又快又好解决线上问题,更为重要。所以,当决定使用某种新技术(哪怕技术并不新,如果团队当中没人使用过,没有深刻了解过)时,并不能仅满足于“能快速上手”。
  • 技术本身没有立场。没有好的坏的,没有国外的国内的。有些技术栈,并没有 mybatis 和 hibernater 那么悬殊,如何抉择,很大概率就看技术团队的偏好,类似于 spark vs flink,spring cloud vs apache dubbo,不管谁是胜出者,都很隐。

  • 除了团队的学习成本,还要考虑其它成本.

    • 比如,运维成本,比如,用 scala 还是 java 开发 spark。

    • 用 java 的好处是虽臃肿但新手外行上手超快。用 scala 好处是它是 spark 开发语言,熟悉 scala 便于查看 spark 源码,语法强大,逼格高(我真见过 scala 开发 spark 的鄙视使用 java 的);坏处是,语法强大,语法糖很爽,但有时天马行空对于团队合作开发真的是灾难。

    • 行政成本比如招人成本。招一个使用 scala 的程序员不难,基本上会用 java 的都能快速上手,但要写出没有“java”味儿的 scala 代码,还真不容易。( scala 的 java 味儿,就是那种,你一看就是 java 程序员转过来的痕迹,满屏都快溢出来)

    • 等等

作者:是春壹呀

来源:cnblogs.com/eryuan/p/15223921.html