朋友被老板吐槽发版速度太慢

开篇之前我先问大家一个问题。你们团队的 app 要实现一个功能的时候，一般是不是按这种方式来考虑的：优先考虑把功能放在 H5 里实现，如果不行的时候再考虑用客户端来实现。

之所以按这个优先级来做决策，是因为客户端和 H5 相比起来劣势太多了。随便举几个例子。

• 增大安装包体积。安装包体积增加有不少弊端，首先就是带宽成本高。每次发版都消耗你一大推的流量。还有就是拉新困难，在推广的时候，你让用户下载十分钟，用户直接就点取消就走了。

• 升级版本困难。用 H5 开发一个新功能，一发布，全网就都生效了。而用客户端，你等去吧，没个几个月根本就覆盖不全。

• 多次开发。在一家公司里，往往 ios 和 Android 都是不同的团队。一旦放在客户端，就意味着得实现两遍。虽然现在有了 Flutter，但是覆盖还是全。

但是有些功能又必须得放在客户端里实现，比如需要很强的缓存能力、需要访问通讯录、调用硬件、访问蓝牙啥的，再或者比如想要流畅的体验。这些功能 H5 都是无法支持的。

碰着这些情况，功能就必须得放在客户端组去搞。即使是有上述困难也得硬着头皮上。我的这位朋友和我吐槽了他们公司的问题，虽然用 H5 实现了一部分，但是还是有大量的功能都得放到客户端上实现。

我的一位在金融机构当技术总监的朋友所负责的产品就是这样，过多的功能都搅在客户端里实现。天天被老板批评发版太慢，朋友吐槽说根本快不了，每次发版可能得把多个团队的功能合并进来，你也不知道哪个组的代码有问题，所以测试得非常严谨才行。

不光是测试，还得经过过各种小流量的灰度。根本不敢快，否则一旦有问题的包放出去，收都收不回来。如果出上两次线上问题，团队的年终奖就别想要了。

然后我和他说，这种问题在服务器端也曾经存在过。这个问题的根源就是软件行业工程里面的“高耦合”。过多的功能都耦合在一个 app 里出现各种各样的问题是必然的。

在过去服务器端也是所有功能都用单体的方式来实现，也是大量的功能都耦合在一起。一旦某个代码有问题，可能全网就都崩溃了。但现在已经很好地解决了。

早在十多年前，腾讯内部就秉承大服务小做的方式来对服务进行拆分。在今天，更是有了微服务以及各种配套的基础设施来 对服务器端进行解耦。所以现在服务器端无论是发版速度，还是稳定程度都比十年前要好了很多。

在客户端上，这个问题确实不好解决。但是忽然转念一想，哎，你们的迭代频率特别高的功能是不是用小程序就能实现呀？像微信支付宝那样，把各种外围的功能都以小程序的方式来提供。

一部分是稳定的、最常用的、也是久经考验的交易和行情功能，其他功能可以是敏捷变化的小程序。小程序可以由不同的团队独立开发，自由发布，不会影响核心功能

这样，就既能享受客户端的高权限，就又能拥有快速的发版速度。但仔细一想，这个思路挺不错，但是想实现一个小程序平台，估计投入不少，你老板不一定能同意。

一个月后，我都快把这件事要忘了，朋友开心地给我发了一条微信。非常开心地和我说：“咱们上次讨论的问题有解了。” 我还以为他说服老板让他开发小程序平台了呢。结果他丢给了我一个图片和一个视频（https://www.finclip.com/）。原来业界早就有公司这样做了。

他和我说，如果这套方案实施成功了的话，以后新功能的发版的速度将大大提升。一来大量外围的功能都可以小程序化了，不再需要等待主版发版。第二就是天然支持 iOS、Android、Windows、Mac多个平台，一次开发，四处部署。

而且这套方案还有个优点，天然兼容微信小程序，这样他们公司客户的微信小程序也都能迁移过来，帮助加强他们 app 的能力。

他又丢给我一个视频。

看完以后感觉确实是一个不错的方案。我说你小子挺鸡贼呀，不用自己开发转而去找了市场上成熟的东西。

不过能抓到老鼠的就是好猫。这样的话，成本确实比自己开发成本低多了。这总监的思路和咱搞技术的脑袋就是不一样。技术有了问题更多的是想咋去实现，而总监是想着如何整合资源。真得跟他学学。

最近我看 FinClip 官方还有一个抽奖活动，手机号注册登录就能抽一次，感兴趣的同学可以试试手气。

点击阅读原文，赶紧领取你的盲盒礼物吧～