日志要认真写

曾经,我是不怎么关心程序里的日志的。每次写程序都是写完逻辑,顺带着在一些关键部位加一些日志记录。或者是在调试的过程中插入一些日志。在测试环境这么做完全没问题。因为整个环境只有我一个人在用,每次执行程序,只有那几条日志被打印出来而已。肉眼一扫就知道有没有问题了。工作中发现,很多人其实也是这样,随手写点日志,甚至根本不写日志。 糟糕的日志 直到有一天我需要检查一个问题,有反馈说某个用户收不到我们系统发出的消息。怎么回事呢?系统在线上运行了,也不能为了这一个个例停掉整个系统来调试吧?投递消息这里应该记录了日志,于是打开日志文件检查,看到了如下让人目瞪口呆的内容: [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

为什么要自己写个HTML数字键盘

我们有个面向移动端的HTML页面,使用的时候需要在一个输入框里输入些数字。一开始的时候为了快速实现功能,直接放了个input框在那里。 结果就是使用的时候需要先点击输入框,弹出键盘以后要切换到数字键盘,接着才能输入数字。但是,你永远无法预知用户如何使用你的产品,很快我们就发现有乱七八糟的字符被提交上来了。可是我们要的只是数字而已。于是,给input框绑了个事件,每次用户输入之后检查用户输入的内容,如果内容不是数字,那就不写进input框里。 如果事情就这样结束了可能还要花好久我们才能想到自己写个数字键盘。由于用户的移动设备的差异,input框检查需要兼容很多情况,各种浏览器,各种输入法。虽然我们在各种测试机上测试都没问题,但是还是有反馈说能输入框里能输入中文。甚至把input的type属性改成了number也没用。 想了想这么下去也不是办法,还不如自己写个HTML版本的键盘。这样不仅能够掌控用户操作,使体验趋于一致,还能极大减少兼容性问题。 功能要点 点击数字键的时候能够正确追加数字 只能输入一个小数点 点击删除键的时候能正确去掉尾部的字符 花边儿功能 如果内容为0,输入其他数字时变为其他数字 如果还未输入内容,点击两次0的时候只追加一个0 如果还未输入内容,点击小数点的时候在前面补0 默认只能输入两位小数 提供初始化完成的回调 提供按键按下和弹起的回调 提供键盘滑入滑出效果和调用方法 实现 从上面的功能来看,其实只是一个简单的状态机而已,并没有任何复杂的功能,实现难度简直一星。无非是写点HTML标签当作按键,每个按键上绑定点击事件,然后根据点击的按键把输入值传给状态机就可以了。 这里只有一个问题就是监听什么事件。最先想到的还是监听click事件,在PC浏览器上测试完全没问题。但是手机的浏览器对click的处理有个几百毫秒的延迟,导致用起来一点也不流畅。于是改为监听touchstart,这样就会随着点击立刻触发事件了。调试的时候可以使用Chrome来调试,打开开发者工具,然后点击上面那个手机状的小图标开启手机模式。 代码 一开始没想过独立成一个模块的。我们在前端页面里插入了Bugsnag错误上报,发现任何未catch的错误都会上报到Bugsnag,主要用来发现客户端异常。但是后来发现很多来自127.0.0.1和/Users/some-user-name/path/xxx.html发来的异常。想了想这个页面也没啥值得撸的,能扒的也就只有键盘了。恰巧也正要模块化给其他的页面用,也没什么技术难度,于是丢到了GitHub上。 仓库地址:JK-Keyboard NPM: JK-Keyboard…

Keep reading

说说测试的事

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

Keep reading