0. 前言

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

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

1. 提问的典范

工作中使用到了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