技术团队应该有半个月重写ElasticSearch的能力。自己发明轮子比使用开源软件更可靠。C++效率低，Java太臃肿，Go用起来更流畅。这是一个技术组长的技术选型理论，在社区引起了一些思考和争议。有人认同他，更多的人嘲笑他，可见即使是标榜理性、讲究逻辑的开发者，在面对技术选型问题时，也会陷入某种兴奋与疯狂之中。Google的Flutter只不过是我创建并退休的类似技术。这是最近看到的一条评论。这位创业者在他的技术选型中也有多种自制轮子，每一种看起来都是金黄色的，耐人寻味（笑）。类似的例子还有很多，类似的轮子更是数不胜数。硅谷巨头和互联网新贵创造的技术驱动的商业神话吸引了后来者：谷歌正在使用MapReduce，我们也应该这样做！LinkedIn正在使用Kafka，让我们开始吧！Facebook正在使用Cassandra，让我们开始吧！阿里巴巴在中国和台湾搞，我们也想搞！……他们是这样想的：Google、AWS、Facebook、阿里巴巴都在用，我们也应该用。虽然我们现在的业务量还没有达到那个水平，但是我们以后会有的。在初始阶段做出这样的选择，省去了以后重构的麻烦。我简直就是个天才。恕我直言，使用微服务会浪费您的业务复杂性，那么您要这么多飞蛾做什么？Gartner每年都会发布一份名为“TheHypeCycle”的分析报告。中译为“技术成熟度曲线”，但我更喜欢它的另一个名字——“技术炒作周期”。1995年以来，这份报告中出现的“前沿趋势”和“未来方向”并不多，失败的也不少。据粗略统计，在炒作周期上多年追踪的所有技术中，有20%还没来得及成为主流就已经过时了。在列出的200多项技术中，有50多项技术在炒作周期中出现仅一年，就消失得无影无踪。幸存者偏差让人只记住那些已经成功的技术，而忘记了还有更多的技术已经消亡在时间的长河中。2017年，大家都说AI元年“又来了”。创业者在各个领域的各个岗位涌向AI技术。普通人喝水的地方，全是人工智能；，大家都说现在是区块链时代，不做区块链项目连投资都拿不到；2019年，中泰突然爆发。死，等死？2020年，36氪在《中台，我信了你的邪》的一篇文章，彻底抹杀了中台的遮羞布。文章中，茅台的中台计划让读者恍然大悟，大家做中台都是为了中台。一来他们不知道中台能解决什么问题，二来他们也不知道中台如何实施。.如果中泰不能帮助茅台，它能帮助中小企业吗？如果不构建良好的企业IT，你能玩好微服务吗？记事本可以记录吞吐量，一定要用Kafka吗？1986年，软件工程圣经的作者——《人月神话》指出，软件的本质复杂性存在于复杂的业务领域，技术只是辅助工具。它通过帮助将业务领域问题映射到在软件中实现来解决问题，只解决了较小的复杂性。由于软件固有的复杂性，没有真正的灵丹妙药；没有任何技术或方法可以在十年内将软件工程的生产力提高一个数量级。请记住，为了跟风炒作噱头，这不叫技术选型，这叫技术造型。技术团队还是要扎实。它需要技术选型，而不是技术建模。要茅台，不要中台。
