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
