优化产品交互逻辑来提升产品性能

先说下背景

刚到公司的时候，被分到做审核系统， 到的第一天比我来的早的同事告诉我，之前审核系统是一个外包项目，随着公司的发展，以及国家政策的不断变化，审核系统也变得越来越重要，审核系统的能力也要不断迭代升级，外包肯定无法满足公司的要求了，于是这个项目就从一个外包项目成功晋升为一个公司内部的核心项目了。

一听说外包项目，老司机们应该都懂，前些年的外包项目做的好的很少，尤其是针对国内的，一般都是代码规范少，无测试代码，不怎么考虑产品质量属性，也不怎么考虑项目的扩展能力，基本都是以快速交付，堆叠功能为主，因为甲方爸爸一般要的都比较着急，同时做外包的研发人员能力上也参差不齐，外包公司为了快速拿到钱，一般这种项目都是一次性的。

审核系统是给审核人员用的， 它的核心能力就是审核内容，能够越快速的审核内容，意味着能越快的发布内容。于是在这个外包项目里就有一个资源分发的功能，简单介绍这个功能就是，审核人员能够知道我当前有多少资源可审，有多少资源可拉取到，同时他可能也关心，我今天审核了多少内容等。

打个比方，把审核人员比作捕鱼者， 源源不断进审的资源比作鱼， 把我们的整个审核系统的资源池比作池塘， 鱼会源源不断的进到审核系统，作为捕鱼者的审核人员需要把这些鱼捞干净。捕鱼者需要知道现在池塘里有木有鱼，为了更好的提升捞取效率，大家应该彼此协作，比如捞鱼者 a，去捞他看上的鱼的时候，其他的捕鱼者应该去捞取别的鱼。把所有池塘中的鱼看做待捞取的鱼，而别人未在捞的鱼则为可捞取的鱼，捞出来的鱼即为可发布出去或者拒绝发布的资源。

1. 待捞取的鱼数： 池塘中现存的鱼【待审核的资源数】
2. 可捞取的鱼： 池塘中别的捕鱼者未在捞的鱼 【当前审核人员可拉取的资源数，不考虑其他人员在审的资源，这里是用 redis cache 来实现的】
3. 本人捞取的鱼数： 凡事本人捞取出来的鱼都会打上捞鱼者的标记 【资源是由哪个审核人员审的，会在库里做记录，可根据绑定关系查出这个数】
4. 今天捞取的鱼数： 所有捕鱼者捞取出来的鱼 【审核过资源会变更审核状态，审核的状态会同步到库中，可根据审核状态来查出这个数】

鱼： 资源
捕鱼者： 审核人员

通过跟产品沟通，审核人员的要求是，他们在审核资源的时候需要知道他们审核的情况，所以才需要在审核的入口处把这个四个数目全部输出出来，而且最主要的时候，审核人员希望入口是集中的，也就说在一个审核入口的地方希望将一类资源全部展示在一个面板中

举个例子：

1. 教育类：
   • 历史
   • 英语
   • 少儿
     • 故事
     • 启蒙
   • …

每个条目的查询条件不一样，对应的索引也不尽相同，每个条目都要知道这个四个数目，打个比方有20个条目，那么就需要 20 * 4 次的 io 查询， 最主要的是后端的代码还没有做异步处理，项目初期可能还好，因为数据量少，平均一个查询 20ms 都不到，基本很快就能出来结果，随着数据量越来越多，我来到项目组的时候，最慢的面板加载时间是 18s， 审核人员天天叫苦不迭，说这个入口太慢了，能不能给整整。

延迟信息获取优化产品

做为一名老司机，主动接下了这个艰巨的任务，通过跟产品的沟通发现，其实审核人员核心的诉求是，我审核完一类条目，想知道我接下来可以审核哪些内容，以及我可能审核完一段时间后，想看看自己审核了多少内容，审核负责人可能想知道今天整个团队审核了多少内容。

我们现在的实现从功能上是满足产品要求，但是这个面板加载的时间都可以抽根烟了，谁受得了了，从质量属性上来说，它是不满足产品要求的。

作为研发人员很可能第一时间就想着去优化代码，代码肯定是有很大优化空间的，比如加缓存，异步请求处理等等。但是产品上是否有优化空间了，作为研发也应该去思考这个问题，这里是不是每次进入入口都需要查出这四个数了。

答案是并不需要，大部分审核人员想要的，是最高效率的审核内容，因此他最迫切最需要的是可以拉取的审核内容，因此绝大多数的审核人员他并不关心今天整个审核团队审了多少内容，哪怕他想知道自己今天审核了多少内容，也并不需要每次都告诉他，而是他有需要的时候自己去看。

因此优化后的条目上，只需要一个数目了，那就是审核人员可审核的资源数，而其他更详细的数据，可以提供一个跳转入口，这样既满足了审核人员的诉求，又减少了很大一部分后端的查询压力，这里我们并没有阉割需求，只是把一部分不是当前审核人员特别迫切想要的信息往后移了。

总结，作为一名研发不能光听之任之产品的需求，需要刨根问底追求最终方，即业务方想要什么，产品又是怎么个思考过程的。即要考虑功能，也要考虑产品的质量，包括性能，安全，测试性，迭代，扩展等。

其实延迟获取信息在我们的产品优化上很多地方都有体现，举个例子，比如打开一篇文章，文章里有上百张图片，浏览器需要一次性加载进来吗，并不需要，可以在用户看到某张图片的时候再去加载，因为浏览器，网络等环境因素，一次性加载所有图片会出现很多体验上的问题，而我们浏览器的窗口大小是有限的，只要加载满足布满窗口大小的图片就可以了。之前的工作也经历过这样的事情，在手机 app 上打开一篇文章，因为文章很大很长，图片也较多，需要3，4s中加载出来，这还是网络较好的情况，这种体验除非真的是强需求，否则用户来看了一次，下次肯定就换平台了。