在互联网迅猛发展的近30年里，技术革新日新月异，从前端到客户端，再到后端和存储技术，我们面临着众多选择。然而，不少公司在面对层出不穷的新技术时，却陷入了产品开发的泥潭，这些技术甚至无意中成为了业务发展的绊脚石。因此，挑选一套与团队相匹配的技术栈显得尤为关键。今天早晨，团队中一位同学的深刻提问------"JavaScript才是王道！Python差强人意，而Rust和C#则不值一提"------激发了我对这一话题的深入思考。
技术之"新"，技术之痛
互联网技术的快速发展为众多公司提供了广泛的技术选择。然而，对新技术的盲目追求往往给企业带来意想不到的挑战和阻碍。与此同时，拒绝更新技术同样会导致问题重重。新技术的确是一把锋利的双刃剑，它在为互联网公司带来机遇的同时，也带来了风险。有的公司凭借雄厚的资金实力应对这些挑战，有的则依靠技术领导者的敏锐洞察力来规避风险，而有的公司则不得不在这些挑战面前妥协。那么，我们究竟该如何理解新技术的"痛点"呢？
"新"的技术并不一定是适合的技术
互联网新技术的产生，往往并不是为了解决通用行业问题，而仅仅是解决一小部分自己的问题，或是以宣传为目的的优势。甚至只是为了以另一种自己以为更好的模式来解决相同的问题。比如Flutter。Flutter的出现无疑为移动端互联网应用技术提供了新的选择，更好的性能，更全面的跨端支持，更完善的工具链以及强大的技术支持团队。毫无疑问任何互联网公司的技术团队的终端技术团队都要思考一下Flutter的可行性。
然而在这一切的一切，Flutter真的是最好的选择么？是对于自己团队适合的选择么？真的能够给企业带来价值么？其实不然。每个技术的早期推广阶段就和商品推广宣传一样，都是挑好的来说，Flutter也是一样。咱们就来看看一个新技术是如何占领风口浪尖的。
Flutter以更新的技术实现方式，实现更好的性能，然后列出各种测试数据，与各个同类框架做对比，在CPU，内存，电量损耗，FPS几个核心指标来对比。得出结论Flutter在各个指标比RN高出20%以上。但是这个20%对比真的对于互联网产品意义很大吗？
首先，测试方式，1000甚至10000项大列表，先不说别的，如果一个技术团队在实现长列表的时候同时绘制1000个元素。这个技术人员就应该开除了，这个终端技术Leader也应该考虑换人了。这不是危言耸听，事实就是，无论你再好的技术一个长列表，你同时绘制这么多项目，对于客户哪怕是性能更好的技术也会带来相比较于虚拟列表更多的耗电量。更何况，在1000项大列表的综合，虽然表面上看起来性能高出20%，但是实际上多少偏差呢？ fps只有5帧左右。用户视觉上根本就看不出来。CPU的5%差距，但是，最高也就不到20%。这5%差距又有什么意义呢？如果说CPU达到70%左右，由于CPU超过60%以上性能会曲线下降(基于Arm架构和x86架构CPU都是如此)，下降5%意义还是蛮大的，这会减少卡顿和电量消耗。但是如果20%都不到，你降低5%属实意义不大。更何况绝大多数产品根本不可能在长列表同时绘制1000个项目。
所以，很多时候，一个新的技术宣传的时候，总是避重就轻甚至是夸大其词。很多优点其实对于企业产品来讲收益非常小，甚至是毫无用处。所以很多时候一个新技术的评测都是很片面和局限的。尤其国内很多技术文章，技术倾向性都非常严重，各个作者都期望自己通过新技术热点来建立自己在这个技术的影响力。获得更多关注。这也就导致了对于技术决策人的误判。
咱们说完了优势，再来说一些新技术避之不谈的"成本"。这也是企业最关心的，但是往往不是技术人员关心的。还是拿Flutter来说，Flutter的强大是有目共睹的，性能对于其他技术的优势也是事实，虽然可能对于很多公司的产品没什么卵用。但是任何技术都是有其"副作用"的。Flutter也不例外。
首先，Flutter本身并不仅仅是一个新框架，还采用了新的开发语言，这也就给很多团队带来了额外的学习成本和团队技术管理成本。不管怎么说，你得有人学吧，你得有人学的会吧，你得有人能坚持下去吧。如果坚持不下去，半途而废，但是你的技术已经上马了。这时候你想及时止损还是可以的。但是有一些技术Leader比较过于自信，霸王硬上弓，最后搞得大家都很难。当然对于基层开发而言，有人带着学新技术总是好的，尤其年轻人。但是业务团队伤不起，企业更伤不起，尤其是初期阶段业务高速迭代，需要快速铺市场的时候。所以这个时候，就只能招外援，对于大厂，可以用钱解决的问题都不是问题，而对于小公司，本身就资金有限，而你折腾来折腾去，团队成员好不容易成手了。就被不差钱的公司挖走了。最后伤的还是自己。
其次，Flutter与现有技术融合不太好，也就是说，你一旦选择了Flutter就只能一条路走到黑，没有退路，或者退路很坎坷。这也就导致了技术成本的隐形上升，在市面上没有得到广泛业务场景验证的阶段，很可能给产品迭代过程中某些交互带来阻碍。这个时候就需要团队投入更多人力来攻克。那么对于普通互联网公司营收都是问题，哪有足够的资源去这么折腾呢？我在大连就遇到一个这样的公司，他们使用Flutter技术，遇到了技术难题，需要一个资深人员来解决，但是大连本身Flutter人才就少，会用的都少。所以只能花大价钱去从一线城市挖人，但是即使挖来人也未必能解决问题,而工资更高，也就是所谓的物以稀为贵。换技术栈显然已经不行了。那么对于企业来讲，这就是一个非常大的成本问题。而且阻碍了业务发展。
再者，技术是有地域性的。这个可能很多人会觉得奇怪，技术不是谁都可以学吗？为啥会有地域性。技术确实会有地域性。地域直接决定这门技术在当地是否容易获取人才。比如北京，什么技术候选人都容易找到。但是我所在的大连，使用Golang，React，Flutter的公司屈指可数，那么掌握这些技术的人就业机会就少。所以，你想获取到这方面人才就难,想获得这方面技术的高级人才就更难。
所以在技术选择上，不仅仅要考虑技术的好与坏，还要考虑成熟度，工具链，技术风险，使用成本，本地市场上人才储备情况等等等等，有时候使用新技术往往会在一段时间内带来更高的技术管理成本,等你团队技术熟练度上来了，业务可能已经黄了也说不定。所以有时候保守并不一定错，但是过于保守肯定错。接下来就讲一讲技术决策人对于新技术的尴尬窘境。
明知是毒药，却不得不品尝："新"技术的双重诱惑
对于小微企业，留住人才是非常难的，很多时候培养出来就跑了。而不断的尝试新技术往往可以一定程度上帮助团队留住人，尤其是年轻人。互联网技术圈子就是这样，你用JQ都会觉得你非常LOW。用React的就是要比Vue得高一头。用Golang的就觉得比Java先进，用Nodejs的鄙视其它一切技术。互联网技术是存在鄙视链的，而且互联网技术人有着不一样的技术执拗。
所以有时候，技术决策人不断尝试新技术去折腾也是无奈之举。你不去尝试新技术，一个是自己很容易被业界淘汰，另一个就是团队不断的有人因为学不到新技术而离职。最后还是自己担责。所以对于新技术的使用上，有一些技术决策者可以很好的把握度，而有一些技术决策者就非常激进，最后自己和企业都搞得下不来台，不欢而散，屡见不鲜。
创"新"不是创造
互联网技术团队另一个特点就是什么都想自己造,也就是所谓的技术创新，技术突破。尤其终端技术圈，几乎很多公司都有自己的UI组件库，Nodejs框架，甚至跨端框架，小程序框架。然后还要单独安排几个人去维护这些框架，不仅如此，每年还要提供高绩效来留住这些人，他们一旦跑了就是一地烂摊子。但是真的有必要么？？？？？在我经历看来，很多公司都是纯纯的资源浪费，当然大厂有足够的钱去浪费,而小公司未必有足够的命去浪费。
在我途家工作期间，他们自己基于Nodejs搞了一个Vue的SSR。但是市面上已经有非常成熟的Nustjs了，并且有官方的技术支持。但是就要自己搞，而且还搞出一个篓子，内存泄露。这个玩意困扰了他们许久，我花了半年时间才解决了这个bug。但是并不是说这个bug难解决，而是这个模块不是我负责，负责的人不想我插手抢了他的业务。一直百般阻挠,总是让我提供这个测试，那个测试证据证明我的方案是对的，百般刁难。
所以很多时候，公司团队自己搞组件库，搞框架这种创新完全就是内耗。当然都是内耗么？也并不是，比如国内很多大厂都基于RN技术实现了自己内部的混合端框架，但是其目的是可以更好的嵌入很多终端监控指标采集工具，针对自己业务特点，CICD工具链更好的融合，从而提高终端的稳定性和开发效率。而且大厂也有足够的资源去做这些事情，更何况他们的团队本身就是冗余的，老板总要给手下的小弟找点事情做呀，要不然一到年底一堆人绩效不合格？
但是对于很多小微企业，本身生存就是一件很大的难题了。你还想抽出来人去搞这个？在上一家公司，他们自己搞了一个Nodejs的Web框架，也算是吸取各家所长，但是在使用的时候总是动不动就启动不起来。而且还有自内无限引用问题，最后解决不了只能让大家自己规避，所以很多时候除了问题都是你没用明白。虽然表面上说性能好。但是。。。。。。。。哪家的Web服务器会单机抗10w+的QPS呢？？？？线上实际上每台服务器300-500QPS就已经非常高了。再高的话，你老板敢让你这么搞么？更何况，搞过后端的都知道，后端的性能主要瓶颈是IO。Web框架那点性能流量稀释以后单个请求的性能差距连0.00001ms都不到，更何况跟谁比的？怎么比的？一问就是你先闭嘴。
举一个的例子，Echo和Gin，Gin使用正则匹配路由的方式实现路由，而Echo使用查找树的方式实现路由，因为正则在任何开发语言来说都是性能瓶颈，那么也就Echo的性能比Gin高不少，事实也是如此。但是使用Echo的用户也没比Gin多多少，反而Gin比Echo更用户更多。所以后端绝大多数人都是很现实的，成熟，稳定，好用，能帮自己保住饭碗才是主要的。所谓的性能更好，加两台机器比更换一个新技术成本要低的多得多。下面是第三方平台的压测数据，其中koa(golang)是我的自研框架，之所以性能比主流大神的知名框架性能更高，这完全就是因为，Web框架性能消耗最大的两个地方一个是匹配，一个是序列化，只要把这两个地方换成更高性能的实现方式即可。这有什么意义么？只是为了数值投机取巧罢了。
| name | qps | transactions/s |
|---|---|---|
| koa(golang) | 12598080 | 42014.05 |
| gin | 11936723 | 39812.96 |
| echo | 12347680 | 41179.66 |
| beego | 11051408 | 36856.09 |
| koa(nodejs) | 8042021 | 26818.72 |
所以早期国内很多网红步道Koa2的时候，都说性能比Express好。但是Koa2的CICD和开发调试都要比Express复杂的多得多，这也就带来平时开发的过程中，技术成本的隐形上升，更何况到Nodejs8+，这点性能差距已经微乎其微了。。。。。。当然有的人完全是奔着TS去的。这个也就无所谓了。而回调地狱也有很多库和polyfill去解决。所以给自己找那么多麻烦你图啥。所以有时候折腾真的不是很有必要，当然如果刚刚工作三四年的话，还是可以给自己加很多分的，对于日后进大厂还是很有帮助的。但是如果已经三十好几了。就完全没意义了。不是每个人都可以走狼叔那条路，更何况还需要他那种极高的情商。
言归正传，所以性能更好，都是噱头么？其实也不然。这个就要根据技术解决的业务场景来说，比如Kafka，这门技术的吞吐量非常高，性能也不弱，然后MQ，Redis也可以实现同样的业务目的。但是为什么在日志采集的数据接入层依然还是使用Kafka呢？答案就是在面对海量数据吞吐场景Kafka可以提供更好的支持。MQ和Redis虽然也能做到这一点，但是需要付出更多的资源，包括人力和服务器资源。所以，当选择性能作为技术选型的标准之一的时候，首先要看清楚这个性能能不能解决你自己业务中的问题。很多时候，如果为了提升这点性能，需要付出更多的技术管理成本那就是毫无意义的内耗。
再比如前端特别多的公司和团队总爱搞出UI组件库，其实大家都是相互抄，抄人家源代码改一改，换个名重新打包一下就说是自己的。有的甚至连代码都懒得抄。直接连注释都还在。但是无非就是换个皮罢了。每每看到技术社区各种同质化的UI组件库推广软文。心想的就一句话："前端娱乐圈名副其实"。
所以，创"新"不是创造，创造纯纯是内耗。追"新"不能盲目，盲目纯纯大冤种。