优化产品交互逻辑来提升产品性能
时间：2023-09-28 05:37:02
先说下背景
刚到公司时，就被分配到审计系统， 到的第一天比我来的早的同事告诉我，之前审核系统是一个外包项目，随着公司的发展，以及国家政策的不断变化，审核系统也变得越来越重要，审核系统的能力也要不断迭代升级，外包肯定无法满足公司的要求了，于是这个项目就从一个外包项目成功晋升为一个公司内部的核心项目了。
听说外包项目，老司机应该明白，几年前外包项目很少，特别是对国内，一般代码规范少，没有测试代码，不考虑产品质量属性，也不考虑项目扩展能力，基本快速交付，堆叠功能，因为甲方父亲一般担心，同时外包研发人员能力不均衡，外包公司为了快速获得钱，一般这类项目都是一次性的。
审核系统是给审核人员的， 其核心能力是审核内容。内容审核越快，内容发布越快。因此，这个外包项目有一个资源分配功能。简单介绍一下这个功能，就是审计师可以知道我目前有多少资源可以审核，有多少资源可以提取。同时，他也可能关心我今天审核了多少内容。
打个比方，把审核人员比作捕鱼者， 持续进审的资源比作鱼， 将我们整个审计系统的资源池比作池塘， 鱼会不断进入审进入审计系统，作为渔民的审计师，需要把鱼捞干净。渔民需要知道池塘里有木头和鱼。为了更好地提高捕捞效率，我们应该相互合作。例如，渔民 a，其他渔民在去钓他喜欢的鱼时，应该去钓其他鱼。池塘里所有的鱼都被视为待捞的鱼，而其他未捞的鱼则是可捞的鱼，捞出的鱼是可以发布或拒绝发布的资源。
- 待捞鱼数： 池塘中现有的鱼待审核的资源数
- 可捞鱼： 池塘里其他渔民没有钓鱼 【目前审计人员可以提取的资源数量不考虑其他人员在审计的资源，这里使用 redis cache 来实现的】
- 我钓的鱼数: 一切自己捞出来的鱼都会贴上钓鱼者的标记 【哪个审核员审核资源，会在库里记录，这个数字可以根据绑定关系找到】
- 今天捞取的鱼数： 所有渔民捞出的鱼 【审核资源会改变审核状态，审核状态会同步到库，这个数字可以根据审核状态找到】
鱼： 资源
捕鱼者： 审核人员
通过与产品沟通，审计人员的要求是，他们在审计资源时需要了解自己的审计情况，因此他们需要在审计入口中输出所有四个数字。最重要的是，审计人员希望入口集中，也就是说，在审计入口处，他们希望在面板上显示所有一类资源
举个例子：
- 教育类：
- 历史
- 英语
- 少儿
- 故事
- 启蒙
- …
每个项目的查询条件不同，相应的索引也不同。每个项目都应该知道这四个数字。例如，如果有20个项目，则需要 20 * 4 次的 io 查询， 最重要的是后端代码没有异步处理，项目初期可能还可以，因为数据量少，平均查询 20ms 不到，结果很快就会出来，随着数据量的增加，我来到项目组的时候，最慢的面板加载时间是 18s， 审计人员每天都在抱怨，说入口太慢了，可以给整个。
优化产品获取延迟信息
作为一名老司机，我主动接管了这项艰巨的任务。通过与产品的沟通，我发现审计师的核心需求是，在我审查了一类项目后，我想知道我接下来可以审查什么，在我审查了一段时间后，我想看看我审查了多少内容，审计负责人可能想知道整个团队今天审查了多少内容。
我们目前的实现是为了满足产品的功能要求，但面板的加载时间可以抽烟，谁能忍受，从质量属性的角度来看，它不符合产品的要求。
作为一名研发人员，他很可能会考虑在第一时间优化代码。代码必须有很大的优化空间，如添加缓存、异步请求处理等。然而，作为产品是否有优化空间，作为研发，我们也应该考虑这个问题。每次进入入口都需要检查这四个数字。
答案是不需要的。大多数审计师想要的是最有效的审计内容。因此，他最迫切、最需要的是可以提取的审计内容。因此，绝大多数审计师不关心整个审计团队今天审查了多少内容。即使他想知道他今天审查了多少内容，他也不需要每次都告诉他，但当他需要的时候，他会自己看。
因此，优化后的项目只需要一个数量，即审计人员可以审计的资源数量，其他更详细的数据可以提供跳转入口，既满足了审计人员的需求，又减少了后端查询的很大一部分压力。在这里，我们没有阉割需求，只是将一些不是当前审计人员特别迫切需要的信息向后移动。
总结，作为一个研发不能只听产品的需求，需要追求最终方，也就是业务方想要什么，产品是如何思考过程的。也就是说，要考虑功能和产品质量，包括性能、安全、测试、迭代、扩展等。
事实上，延迟获取信息反映在我们的产品优化中，例如，打开文章，文章有数百张图片，浏览器需要一次加载，不需要，可以在用户看到图片加载，因为浏览器、网络等环境因素，一次加载所有图片会有很多经验问题，我们的浏览器窗口尺寸有限，只需加载满窗大小的图片即可。以前的工作也经历过这样的事情，在手机上 app 打开一篇文章，因为文章又大又长，图片很多，需要3、4s加载出来，这还是网络比较好的情况，这种体验除非真的需求量很大，否则用户来看一次，下次肯定会换平台。
