目录

　　快的不一定是好的

　　工作流程

　　假设与求证

　　正文

　　最近的一段时间里，做了不少工作，也踩过不少坑，这里记录一下其中的一些失误。

　　快的不一定是好的

　　做过一个病患主数据批量创建的程序。功能测试通过了，但是效率很不理想，数据量较大的时候，会出现GUI的超时。为了解决这个问题，我做了两项工作：1，建立缓存，提高不同的数据文件中的条目的关联速度。2，把创建过程转到后台作业，避免超时。

　　调优工作完成后，很高兴地告诉相关人员测试。当时我们天真地以为，经过修改后的程序将可以一次性导入所有数据，因为后台作业是不会受到10分钟超时的限制的。谁料，在数据量增加到一定程度后，发生了红红的DUMP，提示内存不足。

　　这时我才意识到服务器为我的后台作业分配的内存是有限的（理所当然）。而程序会占用过多的内存，原因除了有上传的数据量本身过大之外，也与用于缓存的哈希表、未被适时free的内表有关。

　　实际上，既然程序转为后台运行后，用户的客户端和电脑都可以关闭，成功后也会有邮件提示，因此完全不需要有人值守，这时其速度已经不是很重要。调优的目标应当从减少总时间向减少总运行次数转变。在这种情况下，之前为了提高速度而建立的缓存表，反而成为了“负优化”...总之，这里得到的教训是：既要关注时间，也要关注空间。

　　工作流程

　　有一个利用服务器存放临时文件的程序，在测试系统测试通过，上传到生产机后，却无法正常工作。

　　经过排查，我发现，原来，我们的开发机、测试机均只有一个应用服务器（ApplicationServer以下简称AS），生产机却有3个AS。在开发机与测试机中，程序写入临时文件的AS，即是执行后台作业的AS，因此可以正常读取到数据；在生产机中，用户登录的AS和后台作业被调度到的AS有时（多数时候）不是同一个AS，这种情况下，后台作业进程自然便读取不到文件了。

　　打电话给BASIS，询问哪个目录能用，得到的却是让我意外的回应：“谁允许你动服务器了？经过我同意了吗？”。虽然感到意外，但想想事情的确如此，如果我能提前和其沟通好，说不定就会知道生产机的不同之处，从而避免该问题的发生。

　　事情最后以将程序改为通过数据库存放临时数据的方式解决了。但是这件事情也给了我深刻的教训：了解清楚工作流程是很重要的，不应该任意地在开发者的领地边界之外进行活动。

　　假设与求证

　　踩坑多的人，难免会对脚下疑神疑鬼。昨天，我接到一个关于开票屏幕文本显示错误的问题，简单查了下代码后，我发现存在问题的是数据库中的数据。原来是一个转账程序出了错，生成的凭证有误，导致负责显示文本的程序没有读到正确的数据。之后，和FI顾问一起调整程序，确认修改后的转账程序无误，便通知向我反馈该问题的人，告诉她该问题已解决。

　　谁知，今早对方又向我提出开票屏幕文本错误，我问了下情况，似乎这笔转账是在我修正转账程序之前做的。于是我便毫不客气地提出是数据错误，显示程序无误。谁知，经过调试，发现原来程序真的有个不明显的bug...这下感觉好丢人...细细想来，其实自己完全没理由那样反驳别人。因为程序原本不是自己写的，自己对财务方面的知识也不怎么了解，在这种情况下，不经过小心的求证，便把自己的假设当作事实来抛出，实在是有点过分的大胆，失于轻浮了。我一向没什么急智，因此，还是不要假装成是聪明人为好。