技术选型,不是技术造型
技术团队应该具备半个月重写 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 就曾指出:
软件的本质复杂性存在于复杂的业务领域中,技术仅是辅助工具,它解决的问题是帮助将业务领域问题映射转换成软件实现,只解决次要复杂性。由于软件本质的复杂性,真正的银弹并不存在;十年内,没有任何一项技术或者方法可使软件工程的生产力提高一个数量级。
请记住,为了跟风、炒噱头而强上、往死里吹的那不叫技术选型,叫技术造型。
技术团队,还是要扎实一点,要技术选型,不是技术造型。
要茅台,不要中台。
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341