职场故事 (3) 小试牛刀

很快接到了一个新任务。有一个 screen显示大公司(有几百个子公司)的信息，要花一分多钟才能把数据load出来。而其他的screen 通常都只需要几秒钟。我的任务是让这个screen load得快一些。

我的 lead建议我做paging, 每一页只显示一部分子公司，这样load一页就不会太慢了。可是我觉得这样不能解决全部问题，因为有些sorting的功能还是需要所有子公司的信息。于是我决定仔细看code，找出问题究竟在哪里。连续看了两天，终于看出问题来了。原来程序里有一个循环，load每个子公司的信息都要查询一次数据库。即使每次查询只要0.1秒，600个子公司就需要60秒，即一分钟。所以我觉得是要把这一部分程序改成一次查询就把所有子公司的信息都load出来。

决定好了我就开始改程序。但紧接着发现一个查询还不行，要分成几个，因为load的信息比较复杂，一个查询不好写。这也许就是为什么原作者调用了一个现有的查询，只是把它简单地写到了循环里。因为改了查询，还要改数据结构，这样才能把几个查询的结果很快连接起来。改完程序后速度确实有提高，但感觉还是不理想。再仔细读code，发现后端有个数据库程序运行很长时间。再把这段程序看一遍，发现它也有同样的问题，而且还返回了很多不需要的数据。我跟DBA沟通之后简化了这段程序。等一切都改好，原来load这个screen需要一分多钟，现在只需要7秒。

我非常兴奋，但知道任务还没有结束，我还需要把这个screen上每个功能测试一遍，保证没有产生新的问题。等我仔仔细细确认无误后，我才把程序交给QA测试。最后没什么问题，顺利上了production。记得在一次小组会上我提到了这个速度的大幅提高，有一个人说用户应该请我吃饭，我只是笑笑而已。我想我在意的是我只想把工作完成好，使用户满意是我们工作的基本目标。

一切看起来是这么顺理成章，但现在我从一个过来人的角度看，还是能看出一些问题。现在知道水有多深之后，我也不敢轻易大改程序，因为可能会产生新的问题，让用户无法使用。当初真是有初生牛犊不怕虎的劲头。还有就是有些领导为谨慎起见，可能也不会同意一个新人就这么大改程序，这也可以理解。说到底我的领导还是给了我一定的自由度，也给了我充分的信任。我才应该要感谢他们。