0. 前言

我在公司内部培训的时候一直都说：程序员的能力体现在各个方面，从一个很小的提问题的事情上，也能看出一个人的职业素养。这里做一个笔记，记录下今天定位和解决的一个问题。

本文中提到的issue在：Performance issue, result set processing

1. 提问的典范 {#ID1}

工作中使用到了TypeOrm这个库，在功能上确实非常强大，性能上一直都没有特别关注，到了今天遇到了个性能问题，然后就需要解决这个问题。

如何解决这个问题，可以很简单粗暴的到TypeOrm的官方issue上提问，把遇到的现象直接描述下。但如果你真的这么做了，对方可能完全无法理解你提出的问题到底是什么原因造成的，或他解决这个问题还需要从你这里得到什么额外的信息。最后来去好几次，浪费双方时间。

所以我是这么做的：

• 本地重现问题
• 隔离问题发生的情况中，和TypeOrm不相关的内容（重写一份隔离业务的超小demo，复现问题）
• 使用简化的demo重新进行测试
• 获取TypeOrm的测试数据
• 隔离TypeOrm，在数据库中直接执行查询，获取测试数据
• 比对TypeOrm的测试数据和数据库中的测试数据，定位问题在TypeOrm还是数据库
• 对简化的demo进行profile：node --prof index.js
• 解析profile数据，尝试自行理解问题发生的根本原因
• 将问题复现相关的代码和资料上传到gist，方便提issue的时候链接给库作者查看
• 在TypeOrm的官方issue上提问，并提出自己的理解和后续的诉求

可以看到我在提问之前做了巨量的准备工作，给到库作者完备的信息，提出自己的问题定位假设，并作出后续的解决诉求。那么对方就能够很快解决并处理。

2. 修BUG的典范

正如在提问的典范中预期的，TypeOrm的作者果然极速响应了这个BUG解决需求，秒发了一个0.1.14版本。

EOF