63集短剧《大魔术师》完整版,日韩av黑人

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

1 前言

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

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

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

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

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

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

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

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

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

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

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

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

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

為避免說教的意思，以及倚老賣老（并不老）的嫌疑，首先聲明，以上以下只代表個人觀點。

2 效率

2.1 沒有絕對的效率

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

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

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

只有在控制變量的前提下，談?wù)搯我恢笜瞬庞幸饬x。

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

2.2 效率是否絕對重要

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

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

這個例子可能并沒有很強的說服力。但大概就是這么個意思。

3 環(huán)境

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

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

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

可是，在國外，hibernate 依然是絕對的主流。

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

按 google 搜索趨勢，過去五年，hibernate 的搜索量依然碾壓 mybatis。

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

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

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

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

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

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

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

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

4 團隊

4.1 團隊負責人及核心骨干的技術(shù)積累以及技術(shù)偏好

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

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

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

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

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

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