乱讲

日志要认真写

曾经,我是不怎么关心程序里的日志的。每次写程序都是写完逻辑,顺带着在一些关键部位加一些日志记录。或者是在调试的过程中插入一些日志。在测试环境这么做完全没问题。因为整个环境只有我一个人在用,每次执行程序,只有那几条日志被打印出来而已。肉眼一扫就知道有没有问题了。工作中发现,很多人其实也是这样,随手写点日志,甚至根本不写日志。 糟糕的日志 直到有一天我需要检查一个问题,有反馈说某个用户收不到我们系统发出的消息。怎么回事呢?系统在线上运行了,也不能为了这一个个例停掉整个系统来调试吧?投递消息这里应该记录了日志,于是打开日志文件检查,看到了如下让人目瞪口呆的内容: [2015-12-01 14:54:33][INFO] send message ok [2015-12-01 14:54:33][INFO] send message fail [2015-12-01 14:54:33][INFO] send message ok [2015-12-01 14:54:34][INFO] send message ok [2015-12-01 14:54:34][INFO] send message fail [2015-12-01 14:54:35][INFO] send message ok 这谁写的日志给我站出来!你语文是体育老师教的吗? 老师从小就教导我们,叙述事情要讲清楚时间,地点,人物,事件。这一条日志你只写了个事件,时间都是框架帮你写好的,然后事件你还没讲清楚。有十个模块在发消息,我怎么直到这些日志是哪个模块写的?就算只有一个模块在记录这些日志,怎么能知道是发给谁的消息成功或者失败了?发送失败了,那么原因是什么? 详细的日志 有些同学没有意识到日志的作用。日志是用来记录事情的。…

Keep reading

说说测试的事

我是一个不专业的程序员。每次接到新的题目,在纸上画画逻辑,想想手头现有的资源,琢磨琢磨程序结构,然后就直接把代码写出来了。写完以后一般是在命令行或者网页上走一遍。发现哪里不对再到代码里打点,插日志,然后再走一遍。就这样一遍一遍重复,最后自己认为没问题了,“走起,上线!” 时间没过多久,接到新的需求说要在上次的功能上加点儿东西。Easy,加!嗯,这里这个流程可以封装一下,于是封装了一个函数。接着开始实现新的需求。写完了以后在命令行或者网页上走一遍新的需求,发现没问题,“走起,上线!” 过了不一会儿接到消息说,原来运行正常的某个功能不好使了。你们这帮人,错就说错在哪,不好使是什么意思?打开日志一看,还真不好使了。于是又补了点儿日志,查查到底怎么个情况。噢,原来上次封装的那个函数那里出了点问题,改吧。改完再走一遍原来的流程,发现没啥问题,“走起,上线!” 又过了一会儿,说刚刚做的新需求又出问题了……你这不是跟我闹呢么! 人肉测试 前面写得有点夸张,真是这样的话早被开除800回了。这里问题也很明显:每次实现功能之后,没有进行系统完整的测试就匆忙(哪来的自信)上线了。我需要些测试来保证程序的质量。 于是我想了个办法,把需要测试的功能点列个表,每次做完的时候要逐个检查每项功能是否正确。怎么检查?当然是网页上的流程就去点网页,命令行的流程就去执行命令行,涉及到数据的再去检查数据库记录咯!一开始,这个方法是有效的,直到每次上线前我要检查500个功能点…… 你不说你是程序员么 检查一个功能点要1分钟的话,检查500个功能点就要500分钟,一天都过去了还上不了线只能加班。如果每天都有新需求过来,每天都要上线的话……太可怕,不敢想。我们这儿没有专职的测试人员,只能写程序的程序员自己来测试功能,等等…… 对啊,我不是程序员么?既然我能写程序,为啥我就不能写个程序去测试我的程序呢?这样就不用每次上线之前都手动检查之前的功能点了啊!说干就干,不能整天把时间浪费在点网页上(甚至有些移动端的网页还要掏出手机来各种操作,简直了)! 说干就干的单元测试 我想,至少要保证程序的每个小单元正确,这样把它们拼装起来才能正确吧!于是,找个了文件,…

Keep reading