在分享完订单导出业务后，小组同学启哥提出了个优化建议： 他认为写文件和排序文件是可以并发的。但是我却很粗暴地回复了他。
他觉得：可以在多线程里把大文件拆分成多个小文件，然后给小文件标记，最后合并排序。 而我觉得没有必要。当时我的言论非常激烈：
我说，目前来看，格式化报表和写文件目前耗时并不多； 他说，假如大流量导出情形下，这个耗时更大了呢？ 我便答： 没有假设，如果有，那就测量，用数据来说话。
我说，多线程情形下，标记文件然后还要合并和排序，反而会造成很大的复杂度。为一个本来简单的事情弄得那么复杂，完全没有必要。但他似乎觉得那并没有什么难度。可能他还没有意识到大流量下一次导出请求的并发IO操作（再加上同时进行的其他小流量导出的IO访问）已经很复杂超出我的理解范围了。
我说，你要做这个优化，究竟要解决什么问题呢？做任何优化是为了解决问题。你究竟是要解决什么问题呢？ 有点歇斯底里的感觉。
为什么我当时那么生气而且粗暴呢？ 仔细反思了下：
他的优化建议没有切中要害。 从耗时分析中明显看出，格式化报表文件和写文件只花了6s左右，总耗时52s，就算把6s提升到2s，提升的性能优化不过7.7%。如果是大流量导出，这个优化会明显吗？ 不会。 因为并发情形下，IO操作可能会非线性增长，但是CPU的操作并不会。 更重要的是，这样的优化只会把事情弄复杂。提升4s也是有很大代价的：1. 格式化和写文件将更加复杂而难以理解，难以维护，2. 不容易排查问题。 不必要的并发会增大复杂度，一旦订单之间的信息错乱，就可能给商家造成资损，而且这样的错误很难排查。你会顶着每一秒的资损扩大，去排查那细微的不知道在哪里的错误； 3. 它并不是瓶颈所在。如果只是看到优化的空间就去盲目优化，却不综观全局，从整体上把握，优化容易“捡了芝麻丢西瓜”。
导出服务有其它薄弱环节，不希望耗费时间在这个暂时并不重要的优化上。
有更重要的事情要做，从整体价值上远远高于这个暂时来说并不重要的优化。
但是，无论我的想法多么合理，粗暴地打断启哥对我的建议，是非常伤害他的行为。 事实上，我可以采取更友好的方式：
- 仔细想清楚并阐述利弊；
- 仔细与他讨论他的方案，从中发现可借鉴可汲取的部分； 从讨论方案中也可以学到很多有益的东西；
- 友好地告知：即使最终不会采用他的方法，但愿意与他讨论优化方案。
总之，这次沟通是我做出的非常暴力的一次，极大的毛刺！ 在这里深刻反省下！