需求背景
团队项目原来使用的云存储中间件已经下线了，由于历史原因未能及时将其全部迁移到新的云存储平台，进而导致部分功能在使用时出现问题。比如在某些需要上传并存放文件的场景下，会导致上传失败，影响正常的业务逻辑；在某些需要下载文件的场景下无法找到正确的路径，从而无法下载相关业务数据。这个问题之所以被发觉是因为前台客诉反馈过来：某个菜单里的导出按钮在点击后没有反应。
排查思路
收到反馈后，我的思路大概是这样子的：文章源自玩技e族-https://www.playezu.com/226521.html
首先是先评估下这个问题的影响面，我的思路也比较简单：这个问题持续了多久了？影响到了多少用户/操作的触发呢？处于业务中的那一步？文章源自玩技e族-https://www.playezu.com/226521.html
还好云存储中间件这个系统是面向内部的，因此待导出的数据并不多。并且因为它是独立于业务主流程的，是需要单独手动触发的一个非必然操作，因此并未阻碍主流程的执行，影响范围较小。文章源自玩技e族-https://www.playezu.com/226521.html
在确定了大致的影响范围之后，就要进入排查环节。文章源自玩技e族-https://www.playezu.com/226521.html
排查环节可以从日志、执行流程、业务逻辑以及第三方依赖这几个方面入手（受个人的思维局限性影响，大家有建议请指正），套上这次具体的场景，大概就是以下几个问题。文章源自玩技e族-https://www.playezu.com/226521.html
- 服务器日志中有无错误信息？
- 提交后的表单是否通过了验证逻辑并进入下载处理流程？
- 下载处理流程是怎么样的？
- 中间是否有第三方依赖？以及第三方依赖状态是否正常？
我们把这些问题解了，大概率也就找到了这个bug藏在了哪里。文章源自玩技e族-https://www.playezu.com/226521.html
工作过程
找到问题在哪后，我先去看了后台被触发的方法，以及方法内打印的日志内容：save to *** failed, service not found，然后顺藤摸瓜找到了问题的原因：调用了某个已经下线的云存储中间件。导出操作的时序图简化版如下：文章源自玩技e族-https://www.playezu.com/226521.html
导出操作时序图文章源自玩技e族-https://www.playezu.com/226521.html
在查看项目代码的时候，我发现之前有前辈做过相关工作的迁移，并且封装了几个上传到新的云存储平台的方法，大概是这个按钮不常被点击，历史迁移的时候也就给他漏了。于是结合老的文件导出的处理流程，我在已有方法的基础上新增了可以接收File类型的方法，文件存放的位置则沿用了之前前辈所使用的 bucket 和父目录。(bucket: 存放文件的某个桶，可以将不同的 bucket 理解为不同的存储空间）文章源自玩技e族-https://www.playezu.com/226521.html
新增完方法之后，为了简化该方法在使用时的成本，就在方法体内部根据 用户ID 和 UUID 自动生成了父目录下的文件子路径，从而将其封装为了仅需要一个File类型参数即可上传文件的方法。
相比于其他上传方法在调用前需要定义好几个方法参数来说，这里只需要一行代码直接save就行了。
这样乍一看感觉没什么问题，甚至在提交CR的时候我都觉得这个方法很不错，用起来可以说是干净又卫生。既然这样，我为什么还要写这篇文章呢？
问题就在于，它可能有点“干净”但并不“卫生”！
“干净”在于之前说的调用的时候只需要传入File对象即可，对已有代码块只需要改动一行就成。那为什么说它不“卫生”呢？
思考总结
在代码上线前的CR环节，师兄从代码的安全性、通用性、维护性等几个角度进行了评估，发现存在很多问题。
从安全性角度来讲：不安全。本文之前有提到 “沿用了之前前辈的 bucket”，这点就是个容易被忽略的点，自己在使用这个 bucket 的时候并没有去查看这个 bucket 中文件的访问权限问题，而是直接默认“这个项目中用到 oss 存储的地方都是这个 bucket，应该只申请了这一个 bucket ”，那我直接用也是 ok 的。
这其实是一个十分危险的想法，只把目光放到了项目上，而并未下沉到业务角度。在 CR 的过程中我们发现，之前使用这个 bucket 存放内容，是因为对应的业务方法和存放的数据都是可以对外的。而本次需求对应的业务方法，则并不对外，而是针对公司小二的，那再用这个就不合适了。
从通用性角度来讲：不通用。设计初衷是这个方法可以直接传入对象就能存储，不需要再写几行代码来定义对应的 bucket 和文件子路径；但是其实在我们舍弃掉参数入口的时候，也关掉了灵活性和通用性的大门。这样的设计意味着如果用户使用这个方法，那么文件的存储配置就必须得用你这个方法里的了，那万一人家想改改配置呢？这种情况下就造成了使用者很大的不便。
从整体维护性角度来讲：目录不易维护。前边有提到，子目录的路径是在方法体内部由登录用户的ID和 UUID 生成的。这样的目录划分方式其实并不合理，因为我们存放的是文件，而在维护存储的时候，我们可能会时不时整理/清理目录与文件。
而这个整理/清理的维度通常是从业务角度出发的，并非用户角度，比方说，我们要清理某月以前的历史退款信息。一看目录，看到的都是一堆用户的id，这个时候负责处理的同学估计就是一脸懵了。相比较而言，文件目录首级以业务进行分类，下一级以用户信息或者日期信息再分类就会稍好点。那要怎么实现呢？答案就在 “通用性” 那一条：增加方法入参，把路径定义的权限给具体的业务方法，虽然业务方法可能要多写两行代码，但是最终的效果是好的。
举个例子
以上就是这次需求处理的整个流程了，综上，给自己最大的收获就是：
- 当某个需求中使用到了自己之前没用过的依赖/中间件的时候，要先去了解这个中间件的特性，以及在这个中间件中自己团队已有的配置信息及其所代表的含义，不要盲目根据看到的代码去YY；
- 对于一个方法的设计，不要去盲目的追求简洁或者通用，要以实际业务出发去思考如何设计，否则可能会适得其反；
- 任何时候安全性一定要纳入需求处理时的考虑范畴，千万不要觉得一个功能很隐蔽就不用着重考虑它的安全性，没有人能确定迟发性的影响会“送”我们一个多大的故障。
作为新入行的新人，我的经验和思考有很大的局限性，欢迎各位前辈指正文中内容的不足或给出建议，不胜感激。