因修改报表名称引发的“惨案”
临近年底，憋出了个严重BUG。 特此记录，以为警示。
背景####
为了规范导出报表，将报表名称由原来的 corp_parammd5hash.csv 改成了 corp_2017-01-10-11-12-13.csv 形式，导致了商家A下载了商家B的报表，引发严重的安全问题。
原因####
这是因为 corp_2017-01-10-11-12-13.csv 文件名没有区分度， 保存到服务器上时， 是 /path1/path2/报表文件名， 其中 /path1/path2 是根据系统当前时间戳解析得到。如果两个商家同时在 2017-01-10 11:12:13 导出，对应时间戳是 1484017933 , 那么，两个报表都会保存到文件 /148/401/youzan_2017-01-10-11-12-13.csv ；这样，当不同商家在同一时刻点导出时，就会导致报表文件覆盖，最终导致一个商家下载了另一个商家的报表，而自己的那份已经不存在了。 一个办法是增加 corp_id ， 但也解决不了同店铺报表覆盖的问题。 这是由于这个报表名称处于公共函数范围， 也影响了其他导出类型的报表文件。
这件事做得也比较急促， 出于对自己代码质量的信心，征求产品同学认可后，新旧导出报表名称改动的开发、测试、验证、发布整个过程在3-4小时内完成，没有仔细推敲原有设计，没有意识到这个改动会产生文件名冲突覆盖的问题， 也没有跟产品同学做一次同步确认，最终导致了严重BUG。
从另一个角度来看，也是前任留下的文档匮乏，对于特别要注意的地方没有任何提醒，接手的人不知道，很容易就踩坑了。 因此，当开发和维护一个系统时，一定要记得把一些关键的坑点记录下来，提醒自己，也为别人留个好路。
教训####
- 勿以事小而不慎。
- 认真记录“坑点”。
- 对外的名称修改时，切记要保持不同用户的区分度，避免安全问题。
- 评估改动时，第一个考虑应该是影响范围，而不是代码改得对不对。
- 原有代码改动时，一定要兼顾整体设计和原有设计。
- 多积累设计知识，有设计敏感度。
突然想到，任何形式的Bug或加班或非适当的劳累，都是因为我们的思维或技术或制度的局限性与现实需求的差距导致的。
好像是废话。
