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