技術(shù)選型，不是技術(shù)造型
技術(shù)團(tuán)隊(duì)?wèi)?yīng)該具備半個(gè)月重寫 ElasticSearch 的能力。
自己造輪子比使用開源軟件更靠譜。
C++ 效率低，Java 過于臃腫，Go 用起來更加順滑。
這是一位技術(shù)團(tuán)隊(duì)負(fù)責(zé)人的技術(shù)選型理論，在社區(qū)曾引起過一些思考與爭議。認(rèn)同他的人有之，嘲諷他的人更多，這說明即便是標(biāo)榜理性、講究邏輯的開發(fā)者，面對技術(shù)選型的問題時(shí)同樣會陷入某種亢奮與癲狂之中。
Google 的 Flutter 不過是我原創(chuàng)并淘汰過的類似技術(shù)。
這是我最近看到的一條點(diǎn)評，這位創(chuàng)業(yè)者的技術(shù)選型中也出現(xiàn)了各種自造的輪子，每一種看上去都金光閃閃，惹人深（發(fā)）思（笑）。
類似的例子不在少數(shù)，相似的輪子不勝枚舉。
硅谷巨頭，互聯(lián)網(wǎng)新貴們創(chuàng)造的技術(shù)驅(qū)動(dòng)的商業(yè)神話，讓后來者們趨之若鶩：
- Google 在用 MapReduce，我們也要上！
- LinkedIn 在用 Kafka，我們也要上！
- Facebook 在用 Cassandra，我們也要上！
- 阿里巴巴在搞中臺，我們也要上！
- ……
他們是這樣想的：
因?yàn)楣雀?、AWS、Facebook、阿里巴巴都在用，所以我們也要用。我們目前的業(yè)務(wù)體量雖然沒到那個(gè)級別，但以后我們會有的，起步階段做這樣的選型省去了日后重構(gòu)的麻煩，我簡直是天才。
恕我直言，您這點(diǎn)業(yè)務(wù)復(fù)雜度用個(gè)微服務(wù)都嫌浪費(fèi)，還整那么多幺蛾子干啥。
Gartner 每年都會發(fā)一份名為“The Hype Cycle”的分析報(bào)告，中文譯名“技術(shù)成熟度曲線”，我卻更喜歡它的另一個(gè)名字——“技術(shù)炒作周期”。自 1995 年以來出現(xiàn)在這個(gè)報(bào)告中的“前沿趨勢”、“未來方向”不知凡幾，失敗的更是不在少數(shù)。
據(jù)粗略的統(tǒng)計(jì)，在炒作周期上被追蹤多年的所有技術(shù)中，有 20％在還沒來得及變成主流之前就過時(shí)了。在所列的 200 多種技術(shù)中，50 多種技術(shù)在炒作周期中只出現(xiàn)了一年，然后就消失得無影無蹤。幸存者偏差讓人們只記住了那些大獲成功的技術(shù)，卻忘了還有更多技術(shù)消亡在時(shí)間的長河里。
- 2017 年，大家說 AI 元年“又一次”來到了，創(chuàng)業(yè)者們一窩蜂地在各個(gè)領(lǐng)域以各種姿勢生蹭 AI 技術(shù)，凡人飲水處，皆言人工智能；
- 2018 年，做 AI 的剛有點(diǎn)聲色，大家說現(xiàn)在已經(jīng)是區(qū)塊鏈的時(shí)代了，不做區(qū)塊鏈項(xiàng)目連投資都拿不到；
- 2019 年，中臺突然又爆火，大家說不做中臺會死，做中臺同樣是死，等死？
2020 年，36 氪一篇《中臺，我信了你的邪》的文章更是徹底將中臺的遮羞布給扒了個(gè)干凈。文中茅臺的中臺項(xiàng)目讓讀者們恍然大悟，原來大家都是為了中臺而中臺，一不知道中臺解決什么問題，二不知道中臺怎么落地，選型全靠吹，落地全靠臨場發(fā)揮。
中臺幫不了茅臺，就能幫得了中小企業(yè)了？單體都沒構(gòu)建好的企業(yè) IT，就能玩好微服務(wù)了？記事本就可以記錄的吞吐量，非得用 Kafka？
1986 年，軟件工程圣經(jīng)——《人月神話》的作者 Brooks 就曾指出：
軟件的本質(zhì)復(fù)雜性存在于復(fù)雜的業(yè)務(wù)領(lǐng)域中，技術(shù)僅是輔助工具，它解決的問題是幫助將業(yè)務(wù)領(lǐng)域問題映射轉(zhuǎn)換成軟件實(shí)現(xiàn)，只解決次要復(fù)雜性。由于軟件本質(zhì)的復(fù)雜性，真正的銀彈并不存在；十年內(nèi)，沒有任何一項(xiàng)技術(shù)或者方法可使軟件工程的生產(chǎn)力提高一個(gè)數(shù)量級。
請記住，為了跟風(fēng)、炒噱頭而強(qiáng)上、往死里吹的那不叫技術(shù)選型，叫技術(shù)造型。
技術(shù)團(tuán)隊(duì)，還是要扎實(shí)一點(diǎn)，要技術(shù)選型，不是技術(shù)造型。
要茅臺，不要中臺。
