这是我和总工聊了一个下午之后,我的收获。但是技术规划是每个人都有自己的想法,同时和具体的团队和时机相关,再加上我自己没有实际参与任何的规划,我只是执行技术规划的其中很小的一个点,因此本文的内容一定存在争议

我不期望说很多关键词,因为关键词这部分很多大佬都有写过书。本文只聊我所看到的,和我所想到的

本文没有涉及到具体的团队和事务,都是使用其他公司和团队作为例子。如果有小伙伴觉得不该发,我将会删除本文

长远的技术规划

看标题,相信这个没有小伙伴不认同吧

但是实际上这一点的难度很大,什么是长远的?其实有一个实际可行的做法,参考大厂

例如我现在碰到了客户端,我预计我这个产品将会是 ToC 的产品,而假如我这个产品是 PC 端。那么如果我想要做技术规划,我可以怎么想?难道就是大家说 5G 火,就去投 5G 了?实际上不应该的

第一步就是找到可以参照的大厂

例如找到了 QQ 这个软件,差不多的都是 PC 端的软件,那么这个软件有哪些是可以埋到技术规划里面的?可以根据自身的团队,例如此时的软件团队还特别小。而软件的功能也不多,咱来看看 QQ 作为 PC 下一个应该可以说是最强的软件,将会具备哪些技术是可以放在技术规划里面的

  • 账号体系
  • 稳定的通讯
  • 自动更新

当然,还有很多。一个软件绝不是咱所看到的界面那么简单的功能,还有很多埋在后面看不到的功能。上面这几个项,每个做穿了都需要大量的投入

先拿第一个账号体系来说,在技术上有什么需要考虑的?首先需要有一个后台,其次这个后台需要支持各方的接入。但有这一点还不够,还需要更重要的是任何可以和用户绑定的,都可以接入到账号体系里面

因此,如果有账号需求,可以先接入其他平台的。然后自己修炼,自主研发。后续账号体系搭建起来了,就好玩了。例如我可以将等级和账号绑定,我可以将通讯记录和账号绑定。这一个账号能做的太多了。包括后面大数据的依据现有账号下的数据作出的大数据相关业务等

在做长远技术规划的时候,推荐是先拿当前的大厂的路线加上大厂所碰到的技术,再对照自身,此时可以发现有很多小点,每个点都可以做下去。这就是长远的技术规划可以做的方法

而第二步呢?如果按照第一步拆分出来太多的点都可以打,那么如何排下呢?这就需要考虑如何让技术形成规模

技术需要形成规模

如果我有很多技术,每个技术都是这个点打一些,另一个点打一些。还是用上面 QQ 的软件作为参考做的技术规划的例子

我看到了账号体系很重要,于是我就开始投入开工。但是我完全忽略了业务和团队以及人员的意向。然后我又觉得稳定的通讯非常重要,尽管现在有很多网络通讯框架,但是如果有一个非常稳的自主研发的网络通讯框架,无疑这个点就具有强大的竞争力了

而软件如果没有自动更新,那么如果软件出现问题,如何及时修复。如果没有自动更新,如何做到跟随业务变化,给用户及时更新版本。这也非常重要

于是我就写了这三个路线:

  • 账号体系
  • 市面上第三方的接入
  • 各大服务的依赖绑定
  • 多个软件之间的关联
  • 用户行为数据的关联
  • 大数据的收集
  • 稳定的通讯
  • 大吞吐量
  • 客户端高性能省资源
  • 服务器端高并发
  • 自动更新
  • 稳定的更新
  • 复杂更新策略,灰发等
  • 减少体积的更新策略,二进制差异更新等

一排下来,实施了一段时间,发现了账号体系做出来,但是没看到成效,因为依然只有一个主打的软件

而 稳定的通讯 需要大量的专业知识,团队成员撑不足,业务量也达不到能存在高并发的要求。而且当前的实现也不如网上开源的框架

自动更新做了很多,包括复杂更新策略,和减少更新体积等,但是用户量上不去,看不出意义。而团队的成员更喜欢做复杂更新策略,于是点爆了这个技能忽视了稳定的更新

以此用来说明一个什么的问题?其实太过分散了,上面三个点其实没有联系。而且也没有关注时机。是否现在技术储备和人员储备足够做稳定的通讯这件事情,是否做这个能对整个业务带来支撑的发展?这是需要考虑的,当然,只有在过去一段时间才能看清的,我这里不是说做底层的深入的组件是不合适的

另一个是自动更新这个点,具体想要给业务赋能的是什么?是否是降本的减少体积的更新策略。还是满足产品经理的复杂更新策略

但即使想通了依然几个点,依然存在一个问题就是太散了。各个规划的技术无法连起来,无法连起来意味着集团作战做不到

有集团作战是什么意思,可以使用腾讯来做例子

腾讯有 QQ 在前面顶着,即使有其他厂商作出比 QQ 好非常多倍的通讯软件,如 Telegram 等。但是腾讯一点都不慌,因为他是集团作战,不是单兵。我通讯软件打不过你,我有游戏,我有好友数据账号体系。我有全球大量服务器给你提供超快的速度。我有一个企鹅帝国

于是这就能做到碾压

回到实际的技术的例子,如果决定开始点账号体系体系了,那么可以想想,什么是可以和账号体系连起来的?自动更新?还是稳定通讯?其实看起来都不是。反而是支付和广告等

因为在拥有账号体系下的时候,很自然就想到了支付,这个和账号相关的内容。其次就是绑定账号的广告。还有就是做内容最喜欢的推荐系统等

如果有了成熟的账号体系,然后将用户生产的数据关联起来,加上其他服务等,那么将会添加用户的黏性。因此可以作为集团的作战。账号这个人人都有,但是我用我自己独立的。我还拥有很多人没有的推荐系统,这样就算打出来了组合了

再回到长远的计划的主题。如我是做视频相关行业的,此时可以对标一下抖音。我开始只是敢想到账号体系,以及可能点的推荐系统。那么我的想法只能到这里?此时才是不到一年的规划。我应该想的是更多包括两三年的规划才是

此时可以从问题出发,如果我是做视频行业的,我将会遇到什么问题?是否需要用户 UGC 让用户生产内容,如果需要,那么鉴黄鉴暴是否需要开。我是否会遇到流量费太贵的问题,我是否可以自己组建自己的一套云。如果我自己能组件一套云,那么这一套是否能做成为服务,提供给第三方。我是否会遇到视频编辑的问题,那是否可以规划做一个属于自己的视频编辑器,那这个视频编辑器又会遇到哪些问题

大概的思路是这个样子,需要注意的就是技术的规划需要让技术成为规模。这样才好成为集团作战,让整个软件团队具有更强的战斗力。即使一个点打不过,没关系,这是整个集团的作战

但这里必须小心一个问题是,无论哪个方向其实都是不确定的,有勇气是必须的。但是做砸了也是肯定的,因此规划的技术之间,相同时间的技术最好不要是存在前后关联的,如要么一起成,要么一起凉凉。如上面的账号体系加上用户推荐,如果账号体系凉凉了,那么用户推荐是否还玩的下去?如果玩不下去了,那么意味着用户推荐这个技术点的坑将会是用户推荐自身加上账号体系两个

这里有一个反面的例子,就是微软的应用商店和 UWP 应用。如果 UWP 应用能成,那么用户将会因为装 UWP 而去应用商店,于是带动了应用商店能成。如果应用商店做得好,用户喜欢去应用商店下载安装应用,那么将会带动开发商发布更多的应用到应用商店,而发布的应用有要求是 UWP 应用。此时两个技术之间就能相互带动。但是微软的小伙伴没有反过来想。如果一方不能成呢?现在是2020于是可以说2015的时候的决策是不对的,应用商店有一个技术没有打通就是稳定性。应用商店无法稳定下载应用,因此用户不乐意从应用商店下载应用,而 UWP 依赖应用商店入口,因此 UWP 缺少流量。而缺少流量会让开发商不乐意开发 UWP 应用。而 UWP 应用少了自然用户更少会喜欢去应用商店下载应用

这就涉及到一个问题,技术规划的技术需要达到的点是哪些?如上面的例子,应用商店的技术规划里面,其中存在一个核心就是稳定性,稳定性包括了系统环境和网络下载等技术点。如果咱的团队没有微软那么大,那么是否在遇到这些问题的时候,会选择自己去研发

回到账号体系里面,如果我只是简单的做账号体系,让账号体系具备的功能十分简单,让用户注册登录等。那么这个是否有意义?这个和接入第三方对比有什么优势?其实没有任何优势

我听说一句有道理的话,有时站在巨人的肩膀也是进步

如果所有东西都是第三方的,那么软件团队的路在哪?都是在上层的业务,浪花过去之后就在沙滩上做一条鱼?反过来,啥都想自己搞,没资源,做出来比别人差

这是一个神坑的问题,我参与过很多次技术改进的开发工作,其中我弄砸的也有很多。有一些深刻的感觉是自己能努力做的,实际上不如别人家的。但是如果全部用别人家的,又没有任何竞争力

此时就需要聊到将技术打穿

将技术打穿

在技术规划里面,我十分认同总工大大和我聊的,技术的长时间投入的点

其实现在开放的技术里面,很难存在能快速进入某个领域同时能作出碾压其他厂商的功能。除非这个领域是蓝海(没啥竞争力)或者这个领域凉凉了,如做 2G 通讯

回到开始的例子里面,咱说到了如果技术规划里面写了一项是 稳定的通讯 这个技术。那么什么是稳定的通讯这个技术?其实要求很简单,就是我和端和服务器等的通讯是稳定的

如果开始决定了投入这项技术,那么需要有一个决心就是这个技术应该是需要打穿的。无论是决策的大佬还是开发的小伙伴,都应该有一个决心

因为这确实是一个神坑,有很多团队都有小伙伴在这个领域里面砸了几年,几十年都有

因此在发现了某个技术是命脉级的,而且有小伙伴敢投入,那么必须要有一个决心。这个决心可不是说说而已,我都是做一线的开发,我自己的感觉是不是所有的小伙伴都喜欢投入到专注某个事情上。特别是有些技术投入是看不到未来和看不到路的,越走到技术的深海越是这样。所以开发人员是否匹配很重要,尽可能不要指派

在决定做了就不要放弃,此时更多需要的是管理大佬的支持,例如业务需求的分配的量。如果我在做长期技术的投入,而这边有不断的其他业务的需求的打断,此时的技术进度将会很有趣

反过来说,到什么时候才能放弃或将人抽走。要么是开发人员报告说,觉得可以了,接入业务开跑,开跑,跑了一段时间,稳定了。此时相当于这项技术吃透了。要么是开发人员报告说,做不下去了,当然这需要经过一段的时间,例如一年,做了一年发现这个方向必须换,那么此时才能换

能做到将技术打穿了,才能在某个领域里面做到碾压

尽管技术需要成规模,但如果这个规模都是平淡的,那么也很难有竞争力。例如其他厂商通过集成第三方的服务,也能做到成规模,那么此时靠什么打?此时就靠一个做穿的技术做尖刀

以做视频产品的例子,也许大家都在做视频产品,但是我有一个技术够强,那就是我是强客户端,我的稳定性通讯做的特别强,我能让你在啥网络环境下都能刷视频。就靠这个点,就能打出来了

再举现实的例子,因为我没有参与技术的规划,我是执行具体的某项技术规划的内容。有关注我博客的小伙伴可以看到,博客里面大部分都是打穿一个技术点的成体系的博客,例如高性能的笔迹,这个涉及到了整个 WPF 触摸和 WPF 的渲染。可以看到我博客里面这两方面的技术博客都是非常多的。又例如 Roslyn 预编译,有差不多 50 篇博客。这些点能形成软件团队的强战斗力,但每个点都需要真的打穿,如果只是简单的投入,那么其实上完全不如接第三方

我师傅和我说一个反例,就是基于统计的翻译的这个技术,有些公司在这领域砸了几十年,但是有了人工智能,瞬间颠覆了原有的技术。因此,这方面也需要小心

回顾一下

第一步技术需要有长远的规划,做长远的规划才知道自己可以选哪些技术点

第二步就是看哪些技术能形成规模,这样才能做到集团作战

第三步就是决定投入技术了,是否能识别哪些技术是值得做穿的,是否有决定打穿这个技术


本文会经常更新,请阅读原文: https://blog.lindexi.com/post/%E5%85%B3%E4%BA%8E%E6%8A%80%E6%9C%AF%E8%A7%84%E5%88%92%E7%9A%84%E6%83%B3%E6%B3%95.html ,以避免陈旧错误知识的误导,同时有更好的阅读体验。

如果你想持续阅读我的最新博客,请点击 RSS 订阅,推荐使用RSS Stalker订阅博客,或者前往 CSDN 关注我的主页

知识共享许可协议 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。欢迎转载、使用、重新发布,但务必保留文章署名林德熙(包含链接: https://blog.lindexi.com ),不得用于商业目的,基于本文修改后的作品务必以相同的许可发布。如有任何疑问,请 与我联系

无盈利,不卖课,做纯粹的技术博客

以下是广告时间

推荐关注 Edi.Wang 的公众号

欢迎进入 Eleven 老师组建的 .NET 社区

以上广告全是友情推广,无盈利