请选择行业
请选择职位
请选择省份
请选择城市

最近工作中的一些教训

时间: 2018-05-09 15:10   作者: 氢氦   点击次数: 
 

  目录

  快的不一定是好的

  工作流程

  假设与求证

  正文

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

  快的不一定是好的

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

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

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

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

  工作流程

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

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

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

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

  假设与求证

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

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

打印本页 | 加入收藏

上一篇:面试的5个小技巧    

关闭  
主要城市: 北京 上海 杭州 广州 南京 武汉 长沙
全部城市: