123,123

[導(dǎo)讀]1?前言這個(gè)題目有點(diǎn)大。工作也有些年頭，從開(kāi)始入行的被動(dòng)接受，什么流行就學(xué)什么；到有一些想法，會(huì)去思考為什么使用這種技術(shù)；再到主動(dòng)去學(xué)習(xí)一些前沿框架。從開(kāi)始的不理解，事不關(guān)已高高掛起，不在其位不謀其政；到也成為了團(tuán)隊(duì)中的中堅(jiān)力量，去據(jù)理力爭(zhēng)應(yīng)該使用某些技術(shù)，把覺(jué)得好的技術(shù)安利給同...

1 前言

這個(gè)題目有點(diǎn)大。工作也有些年頭，從開(kāi)始入行的被動(dòng)接受，什么流行就學(xué)什么；到有一些想法，會(huì)去思考為什么使用這種技術(shù)；再到主動(dòng)去學(xué)習(xí)一些前沿框架。

從開(kāi)始的不理解，事不關(guān)已高高掛起，不在其位不謀其政；到也成為了團(tuán)隊(duì)中的中堅(jiān)力量，去據(jù)理力爭(zhēng)應(yīng)該使用某些技術(shù)，把覺(jué)得好的技術(shù)安利給同事，試圖引入到團(tuán)隊(duì)中；有成功有失??；也有迫于種種因素使用一些所謂“過(guò)時(shí)的技術(shù)”，有時(shí)候有在想，這種“被迫”或"過(guò)時(shí)"是“為了技術(shù)而技術(shù)”嗎？

本人從事的是 JAVA 后端開(kāi)發(fā)，從業(yè)七八年，時(shí)間不長(zhǎng)，但也經(jīng)歷了不少。

從需要使用 juqery，easyui 等各種前端技術(shù)，到前后端分離成為主流；從一開(kāi)始的 hibernate structs/structs2 框架大行其道，到后來(lái)幾乎消聲匿跡；從最初的 redis/memcache 兩者之間還能一較長(zhǎng)短，到 redis 一統(tǒng)江湖。

從 spring mvc 到言必談 spring boot，微服務(wù)。不來(lái)兩句服務(wù)化，降級(jí)限流熔斷，高并發(fā)你都不好意思出門(mén)。

后來(lái)轉(zhuǎn)戰(zhàn)“大數(shù)據(jù)”領(lǐng)域。那時(shí) mapreduce 已是明日黃花，strom 以及阿里巴巴主導(dǎo)的漢化版 jstorm 也是江河日下。而 spark 正當(dāng)其時(shí)，如日中天。遂入坑。

到 flink 異軍突起，阿里巴巴再出漢化版 blink，與 spark 分庭抗禮，直至略占上風(fēng)。后來(lái)者只知 flink，而鄙視 spark 之風(fēng)氣，怪異而可愛(ài)。

從傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)到非關(guān)系型數(shù)據(jù)庫(kù)，NOSql，NewSql，到數(shù)據(jù)湖，再到兼顧 OLAP，OLTP 的各種分布式數(shù)據(jù)庫(kù)如雨后春筍般出現(xiàn)。

這時(shí)期的數(shù)據(jù)庫(kù)已無(wú)法像傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)那樣三足鼎立（o m else）（ java 位面下），而是春秋時(shí)期百家爭(zhēng)鳴的局面，各家大廠根據(jù)自身的業(yè)務(wù)需求訂制化了許多產(chǎn)品，包括不限于 Fusion，mariadb，OceanBase，TiDB，ClickHouse，greenplum，dorisdb，kudu 等等。

對(duì)于普通開(kāi)發(fā)者，這是好事？壞事？

對(duì)于技術(shù)團(tuán)隊(duì)，這是好事？壞事？有了更多的選擇權(quán)？要學(xué)的東西更多了？

怎么選擇一種技術(shù)框架，從是否開(kāi)源，是否 KPI 開(kāi)源，開(kāi)源社區(qū)是否活躍/持續(xù)/穩(wěn)定（我沒(méi)有說(shuō)阿里，別亂說(shuō)），是否有國(guó)內(nèi)大廠使用，社區(qū)（特別是問(wèn)答社區(qū)）是否活躍，中文資料是否夠多，都是影響普通開(kāi)發(fā)者/團(tuán)隊(duì)選擇某種技術(shù)的原因。

下面將從效率（技術(shù)本身），環(huán)境（開(kāi)源，社區(qū)），團(tuán)隊(duì)（負(fù)責(zé)人/骨干的技術(shù)水平和技術(shù)偏好）三個(gè)方面來(lái)談?wù)勎业目捶ā?/span>

為避免說(shuō)教的意思，以及倚老賣老（并不老）的嫌疑，首先聲明，以上以下只代表個(gè)人觀點(diǎn)。

2 效率

2.1 沒(méi)有絕對(duì)的效率

我有點(diǎn)害怕技術(shù)討論會(huì)上，上來(lái)就說(shuō)據(jù)XX公司/官網(wǎng)測(cè)試，XX比XX效率高出5%（8%or10%...）

這就有點(diǎn)像面試中上來(lái)就問(wèn) QPS 多少。不才曾經(jīng)做過(guò)一個(gè)廣告競(jìng)價(jià)平臺(tái)，日均訪問(wèn)量幾千萬(wàn)，聽(tīng)起來(lái)好像很牛逼的樣子，但該系統(tǒng)是純內(nèi)存計(jì)算，嚴(yán)格限制單次訪問(wèn)時(shí)間，這種系統(tǒng)談 QPS 根本不具備任何橫向參考意義。

或者像面試中多次被問(wèn)到 spark/hadoop 集群多少個(gè)節(jié)點(diǎn)的問(wèn)題。我一般會(huì)回答一個(gè)大概的數(shù)字，然后補(bǔ)充一下集群 cpu cores/內(nèi)存/存儲(chǔ)空間總數(shù)，必要時(shí)補(bǔ)充集群任務(wù)數(shù)，單日/總處理數(shù)據(jù)量。如果只是性能空間并不太好的有限物理機(jī)，用容器虛擬成上千個(gè)節(jié)點(diǎn)，那就達(dá)到了大廠的集群規(guī)模了嗎？

只有在控制變量的前提下，談?wù)搯我恢笜?biāo)才有意義。

效率并非不重要。但為那點(diǎn)3%的效率犧牲其它東西，值得嗎？這是值得衡量的。說(shuō)句誅心的話，那點(diǎn)性能優(yōu)勢(shì)對(duì)于絕大多數(shù)公司，我覺(jué)得可能是你自己想多了。還不如好好優(yōu)化一下那堆shit山。

2.2 效率是否絕對(duì)重要

在RocketMq(阿里牛逼！)沒(méi)有開(kāi)源前，消息隊(duì)列一般有三種選擇 RabbitMQ，ActiveMq，ZeroMq。

三者控制變量的前提下，TPS 測(cè)試結(jié)果表明 ZeroMq 效率最高。但那些年我所待過(guò)的公司，我了解到的情況（同事，網(wǎng)絡(luò)），消息隊(duì)列基本都在 RabbitMQ，ActiveMq 兩者之間選擇，鮮少使用 ZeroMq。

這個(gè)例子可能并沒(méi)有很強(qiáng)的說(shuō)服力。但大概就是這么個(gè)意思。

3 環(huán)境

3.1 國(guó)內(nèi)開(kāi)發(fā)大環(huán)境

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

除了銀行之類的老項(xiàng)目，現(xiàn)在有新項(xiàng)目在使用 hibernate 嗎？就算有，hibernate 在國(guó)內(nèi)也早就遠(yuǎn)離了主流。

可是，在國(guó)外，hibernate 依然是絕對(duì)的主流。

在 stackoverflow 上的 tags 數(shù)量，看對(duì)比圖，hibernate 熱度碾壓 mybatis，兩者根據(jù)不是一個(gè)數(shù)量級(jí)。

按 google 搜索趨勢(shì)，過(guò)去五年，hibernate 的搜索量依然碾壓 mybatis。

同樣 google 搜索趨勢(shì)，按國(guó)家地區(qū)劃分。全球范圍內(nèi)，mybatis 熱度勝過(guò) hibernate 的，只有東亞地區(qū)。中日韓東亞三國(guó)最喜歡 mybatis。迷惑。。。

為何會(huì)有這種地區(qū)之間的巨大差異？有人說(shuō)是阿里巴巴的帶動(dòng)作用。阿里對(duì)國(guó)內(nèi) JAVA 整體環(huán)境的帶動(dòng)和影響是毋庸置疑的，但在 mybatis 之所以流行這件事情上，完全歸于阿里，也無(wú)法解釋韓國(guó)和日本同樣流行 mybatis 這件事。

不管怎么說(shuō)，不管公司，團(tuán)隊(duì)還是個(gè)人，都是一定程度上從眾的。既然大環(huán)境都在使用 mybatis，那么這樣用就不會(huì)犯大錯(cuò)。公司好招人，個(gè)人也好找工作。大家的成本都在最低，皆大歡喜。

3.2 技術(shù)社區(qū)的影響

有個(gè)笑話，外行人看到程序員在工作，覺(jué)得好牛逼，全英文的界面。知乎也常有提問(wèn)，英語(yǔ)不好，學(xué)編程可行嗎？

底下回答，很多鼓勵(lì)，英語(yǔ)跟編程沒(méi)有太大關(guān)系云云。這句話有毛病嗎？這至少透露出來(lái)兩層意思。

不是說(shuō)編程方面英語(yǔ)不重要。英語(yǔ)好，優(yōu)勢(shì)巨大。
國(guó)內(nèi)程序員很多英語(yǔ)不好。以本人常年混跡小公司的經(jīng)驗(yàn)來(lái)說(shuō)，好多程序員連 eclipse 或者 idea 上常用的界面按鈕上的單詞都認(rèn)不全。唯手熟爾。不懂就百度。這個(gè)很多，是好多，無(wú)法統(tǒng)計(jì)，但個(gè)比例絕對(duì)不低。
國(guó)內(nèi) IT 圈子是一個(gè)比較封閉的圈子。雖然，用的技術(shù)基本都是發(fā)源于國(guó)外，但國(guó)內(nèi)的規(guī)模保證了資源的足夠。比如 spark/flink 不需要去官網(wǎng)閱讀一手資料，各個(gè)論壇網(wǎng)站上公眾號(hào)各種二手三手N手的資料滿天飛。

有追求的程序員，或者大廠的大佬覺(jué)得嗤之以鼻，遇 BUG 先必稱看源碼，再次 github issue，stackoverflow，搜索必須 google，資料必須原文。
所以英語(yǔ)跟編程沒(méi)有太大關(guān)系，這不是一個(gè)疑問(wèn)，對(duì)很多程序員來(lái)說(shuō)，這就是事實(shí)。大量分布于各類中小型公司，嚴(yán)重依賴于國(guó)內(nèi)各種社區(qū)學(xué)習(xí)（copy）技術(shù)，解(zhi)決(zao)問(wèn)題，賺錢(qián)養(yǎng)家。
國(guó)內(nèi)頭部公司/團(tuán)隊(duì)用什么，大多數(shù)的公司/團(tuán)隊(duì)/個(gè)人就用什么。
這件事情的另一個(gè)力證是 spring cloud vs apache dubbo，兩者隱隱有在國(guó)內(nèi)分庭抗禮之勢(shì)。但在全球范圍呢，我就不放 google trend 圖了。有點(diǎn)欺負(fù)人。
但是因?yàn)?apache dubbo 是阿里巴巴出品，進(jìn)而影響到了國(guó)內(nèi)整個(gè)程序員圈子，社區(qū)，所以大家也逐漸愿意去用，雖然被之前的開(kāi)源社區(qū)挺尸行為傷過(guò)。就像一個(gè)渣男，但他是高富帥啊，自帶光環(huán)。

4 團(tuán)隊(duì)

4.1 團(tuán)隊(duì)負(fù)責(zé)人及核心骨干的技術(shù)積累以及技術(shù)偏好

2017年新公司進(jìn)行一個(gè)流計(jì)算項(xiàng)目。當(dāng)時(shí)整個(gè)團(tuán)隊(duì)都是新組建，尚處于磨合期。當(dāng)時(shí)我個(gè)人偏向于 spark streaming，用得比較熟，上手快，能夠提前排坑，能快速解決線上問(wèn)題。但當(dāng)時(shí)的技術(shù)負(fù)責(zé)人在召開(kāi)技術(shù)研討會(huì)，聽(tīng)取各方意見(jiàn)后，決定使用 jstorm。
我當(dāng)然服從決定。
當(dāng)時(shí)的 jstorm 尚有余暉。而且據(jù)說(shuō)那時(shí) jstorm 在開(kāi)源社區(qū)詐尸了。頗有幾分卷土重來(lái)的架勢(shì)。加上當(dāng)時(shí)負(fù)責(zé)人力排眾議，讓我覺(jué)得很安心，他應(yīng)該是很懂 jstorm 這項(xiàng)技術(shù)棧的。
后來(lái)項(xiàng)目順利上線。再后來(lái)，不出意外，運(yùn)行一段時(shí)間，遇到棘手線上問(wèn)題。幾次團(tuán)隊(duì)溝通后，我得出一個(gè)結(jié)論，決定使用 jstorm 的負(fù)責(zé)人并不了解 jstorm，甚至應(yīng)該不懂 java 技術(shù)棧（客觀白描事實(shí)，無(wú)情緒輸出，技術(shù)管理者并不一定要懂技術(shù)）；所以，整個(gè)團(tuán)隊(duì)最懂 jstorm 的好像就是我了。
肝吧，騷年。在經(jīng)歷了好幾個(gè)后半夜，并成功在國(guó)慶享受了三倍工資（并沒(méi)有）后，BUG 解決。
后來(lái)回想，如果當(dāng)時(shí)上的是 spark streaming 就不會(huì)出現(xiàn)同樣的問(wèn)題，就算出現(xiàn)這樣的問(wèn)題，憑借對(duì) spark streaming 的較深入了解，也能夠快速解決。
上述這段經(jīng)歷，我想表達(dá)什么？

一個(gè)程序員的競(jìng)爭(zhēng)力包括什么？不是會(huì)用某一種技術(shù)，也不是能夠快速上手某種新技術(shù)。

學(xué)習(xí)新技術(shù)的欲望，動(dòng)力，能力；快速上手，保證任務(wù)，這些只是基本功。對(duì)于新技術(shù)，能夠利用經(jīng)驗(yàn)，快速理解原理內(nèi)幕，預(yù)排坑道，又快又好解決線上問(wèn)題，更為重要。所以，當(dāng)決定使用某種新技術(shù)（哪怕技術(shù)并不新，如果團(tuán)隊(duì)當(dāng)中沒(méi)人使用過(guò)，沒(méi)有深刻了解過(guò)）時(shí)，并不能僅滿足于“能快速上手”。

技術(shù)本身沒(méi)有立場(chǎng)。沒(méi)有好的壞的，沒(méi)有國(guó)外的國(guó)內(nèi)的。有些技術(shù)棧，并沒(méi)有 mybatis 和 hibernater 那么懸殊，如何抉擇，很大概率就看技術(shù)團(tuán)隊(duì)的偏好，類似于 spark vs flink，spring cloud vs apache dubbo，不管誰(shuí)是勝出者，都很隱。
除了團(tuán)隊(duì)的學(xué)習(xí)成本，還要考慮其它成本.

比如，運(yùn)維成本，比如，用 scala 還是 java 開(kāi)發(fā) spark。
用 java 的好處是雖臃腫但新手外行上手超快。用 scala 好處是它是 spark 開(kāi)發(fā)語(yǔ)言，熟悉 scala 便于查看 spark 源碼，語(yǔ)法強(qiáng)大，逼格高（我真見(jiàn)過(guò) scala 開(kāi)發(fā) spark 的鄙視使用 java 的）；壞處是，語(yǔ)法強(qiáng)大，語(yǔ)法糖很爽，但有時(shí)天馬行空對(duì)于團(tuán)隊(duì)合作開(kāi)發(fā)真的是災(zāi)難。
行政成本比如招人成本。

招一個(gè)使用 scala 的程序員不難，基本上會(huì)用 java 的都能快速上手，但要寫(xiě)出沒(méi)有“java”味兒的 scala 代碼，還真不容易。（ scala 的 java 味兒，就是那種，你一看就是 java 程序員轉(zhuǎn)過(guò)來(lái)的痕跡，滿屏都快溢出來(lái)）
等等