技術選型，不是技術造型

技術團隊應該具備半個月重寫 ElasticSearch 的能力。

自己造輪子比使用開源軟件更靠譜。

C++ 效率低，Java 過於臃腫，Go 用起來更加順滑。

這是一位技術團隊負責人的技術選型理論，在社區曾引起過一些思考與爭議。認同他的人有之，嘲諷他的人更多，這說明即便是標榜理性、講究邏輯的開發者，面對技術選型的問題時同樣會陷入某種亢奮與癲狂之中。

Google 的 Flutter 不過是我原創並淘汰過的類似技術。

這是我最近看到的一條點評，這位創業者的技術選型中也出現了各種自造的輪子，每一種看上去都金光閃閃，惹人深（發）思（笑）。

類似的例子不在少數，相似的輪子不勝枚舉。

硅谷巨頭，互聯網新貴們創造的技術驅動的商業神話，讓後來者們趨之若鶩：

他們是這樣想的：

因為谷歌、AWS、Facebook、阿里巴巴都在用，所以我們也要用。我們目前的業務體量雖然沒到那個級別，但以後我們會有的，起步階段做這樣的選型省去了日後重構的麻煩，我簡直是天才。

恕我直言，您這點業務複雜度用個微服務都嫌浪費，還整那麼多么蛾子幹啥。

Gartner 每年都會發一份名為“The Hype Cycle”的分析報告，中文譯名“技術成熟度曲線”，我卻更喜歡它的另一個名字——“技術炒作週期”。自 1995 年以來出現在這個報告中的“前沿趨勢”、“未來方向”不知凡幾，失敗的更是不在少數。

據粗略的統計，在炒作週期上被追蹤多年的所有技術中，有 20％在還沒來得及變成主流之前就過時了。在所列的 200 多種技術中，50 多種技術在炒作週期中只出現了一年，然後就消失得無影無蹤。倖存者偏差讓人們只記住了那些大獲成功的技術，卻忘了還有更多技術消亡在時間的長河裡。

2020 年，36 氪一篇《中臺，我信了你的邪》的文章更是徹底將中臺的遮羞布給扒了個乾淨。文中茅臺的中臺項目讓讀者們恍然大悟，原來大家都是為了中臺而中臺，一不知道中臺解決什麼問題，二不知道中臺怎麼落地，選型全靠吹，落地全靠臨場發揮。

中臺幫不了茅臺，就能幫得了中小企業了？單體都沒構建好的企業 IT，就能玩好微服務了？記事本就可以記錄的吞吐量，非得用 Kafka？

1986 年，軟件工程聖經——《人月神話》的作者 Brooks 就曾指出：

軟件的本質複雜性存在於複雜的業務領域中，技術僅是輔助工具，它解決的問題是幫助將業務領域問題映射轉換成軟件實現，只解決次要複雜性。由於軟件本質的複雜性，真正的銀彈並不存在；十年內，沒有任何一項技術或者方法可使軟件工程的生產力提高一個數量級。

請記住，為了跟風、炒噱頭而強上、往死裡吹的那不叫技術選型，叫技術造型。

技術團隊，還是要紮實一點，要技術選型，不是技術造型。

要茅臺，不要中臺。