熬夜搞了一张鼠标垫，不得不说，ps的内容识别真的强大。之前的破了，买个新的，壁纸换了、座右铭没换。

一、背景

简单记录一下，今天白天发生的事。

老板通知周六要加班，打乱了全盘计划。我本来周末打算好好搞下编译期注解，这下全盘计划给我打乱了。甚至不能睡懒觉。

不生气，是假的。带着脾气去加班。

结果，还被老板批评，被批评代码如下，逻辑也很简单，按顺序上传文件，按顺序返回服务端存储的文件路径，用于后续的数据新增时绑定。“你批量上传文件，使用multipart/form-data不会导致文件乱序吗？”

public List<String> fileUpload(@RequestParam("file") MultipartFile[] files) {
    //若图片保存过程出现异常，返回ERROR，前端做提示
    return new ArrayList<String>();
}

我说不会啊，然后老板不信，老板说，“你要考虑这种情况，如果网络传输不稳定，会不会有这种情况？”

听到这里，我大概就知道了，此时不能跟老板犟了，要拿出证据。我就说了句，“我试一下”。

查阅的方式也很简单，直接Google搜索 HTML标准 即可。

并且用实践进行n次测试不会有问题。

最后我证明了我的做法不会存在问题。其实不管formdata算法吹得再怎么天花乱坠，单线程还不是一样要顺序forEach。

但仔细一想，毕竟不是一个成熟的做法。这种会导致服务端的文件堆积，难道还要加个定时任务，定时清理，那就太臃肿了。

换个做法，文件名以数据编号命名，编辑时进行覆盖，删除时事务控制一起删除。只要在业务接口处做好处理，完全可以避免不必要的文件上传。定时任务都省了。

最后的代码结构

1
2
3

public ObjectTest objectEdit(ObjectTest, MultipartFile file) {
    return new ObjectTest();
}

不过今天虽然被大佬批评了，但还是觉得收获比自己学习来的大一点。尤其第四点。

独立思考能力。别人说的不一定对，需要自己摸索。就比如大佬说formdata会乱序，但要自己想，对不对。
及时发现可能存在问题能力。像老板一样，看到web传输过来的数组，第一反应会不会后端乱序导致与前端对应出现问题。虽然不会，这样的做法自然也可以，但最好添加映射关系。
肯容纳别人指出错误的态度，如果没有这样的态度，手下怎么能容纳一群优秀的人呢？给老板说了他基础知识掌握的有问题，老板没生气，还仔细学习了下。这种态度我没有，我可能更像湖北工业大学那个老师，被学生在图书馆指出声音太大了，因为抹不开面子，进而强词夺理、诋毁学生。
软件设计规范的深入。都知道对修改关闭、对扩展开放，但为什么，就不太清楚了。今天获得了一个强力的理由。对于一个大型项目，顶级接口一旦修改，牵一发动全身，会导致原本已测好的代码修改后进行的维护、测试，造成一大笔开销，此时应该寻求扩展。至于这个如何扩展，就要开动脑筋了（此时不得不提，spring设计的优秀之处。当然了好的规范也只是针对好的项目）

找明论据证明我的正确