技术团队应该具备半个月重写 ElasticSearch 的能力。

自己造轮子比使用开源软件更靠谱。

C++ 效率低，Java 过于臃肿，Go 用起来更加顺滑。

这是一位技术团队负责人的技术选型理论，在社区曾引起过一些思考与争议。认同他的人有之，嘲讽他的人更多，这说明即便是标榜理性、讲究逻辑的开发者，面对技术选型的问题时同样会陷入某种亢奋与癫狂之中。

Google 的 Flutter 不过是我原创并淘汰过的类似技术。

这是我最近看到的一条点评，这位创业者的技术选型中也出现了各种自造的轮子，每一种看上去都金光闪闪，惹人深（发）思（笑）。

类似的例子不在少数，相似的轮子不胜枚举。

硅谷巨头，互联网新贵们创造的技术驱动的商业神话，让后来者们趋之若鹜：

他们是这样想的：

因为谷歌、AWS、Facebook、阿里巴巴都在用，所以我们也要用。我们目前的业务体量虽然没到那个级别，但以后我们会有的，起步阶段做这样的选型省去了日后重构的麻烦，我简直是天才。

恕我直言，您这点业务复杂度用个微服务都嫌浪费，还整那么多幺蛾子干啥。

Gartner 每年都会发一份名为“The Hype Cycle”的分析报告，中文译名“技术成熟度曲线”，我却更喜欢它的另一个名字——“技术炒作周期”。自 1995 年以来出现在这个报告中的“前沿趋势”、“未来方向”不知凡几，失败的更是不在少数。

据粗略的统计，在炒作周期上被追踪多年的所有技术中，有 20％在还没来得及变成主流之前就过时了。在所列的 200 多种技术中，50 多种技术在炒作周期中只出现了一年，然后就消失得无影无踪。幸存者偏差让人们只记住了那些大获成功的技术，却忘了还有更多技术消亡在时间的长河里。

2020 年，36 氪一篇《中台，我信了你的邪》的文章更是彻底将中台的遮羞布给扒了个干净。文中茅台的中台项目让读者们恍然大悟，原来大家都是为了中台而中台，一不知道中台解决什么问题，二不知道中台怎么落地，选型全靠吹，落地全靠临场发挥。

中台帮不了茅台，就能帮得了中小企业了？单体都没构建好的企业 IT，就能玩好微服务了？记事本就可以记录的吞吐量，非得用 Kafka？

1986 年，软件工程圣经——《人月神话》的作者 Brooks 就曾指出：

软件的本质复杂性存在于复杂的业务领域中，技术仅是辅助工具，它解决的问题是帮助将业务领域问题映射转换成软件实现，只解决次要复杂性。由于软件本质的复杂性，真正的银弹并不存在；十年内，没有任何一项技术或者方法可使软件工程的生产力提高一个数量级。

请记住，为了跟风、炒噱头而强上、往死里吹的那不叫技术选型，叫技术造型。

技术团队，还是要扎实一点，要技术选型，不是技术造型。

要茅台，不要中台。

「Q 评论」是 InfoQ 开设的一个观点评论类栏目，如果你对软件及相关领域有深入且独到的观察与见解，并乐于分享，我们愿意为你提供一方舞台，来稿请投：editors@geekbang.com，标题请注明【评论投稿】。

技术选型，不是技术造型丨 Q 评论