谨防新功能引入新bug

做产品或软件开发时,一个很坑但是偶尔能遇到的问题是:实现新功能时可能会引入新bug。如果测试例子不够或者复现条件苛刻,可能需要很久才发现出了问题,真是让人防不胜防。

就本站博客来说,目前已知出现过这些坑爹的事情,都是过去一两个月才被发现和解决:

  1. Goolge PageSpeed Insights分析网页加载速度,听从网站建议把 dashicon.min.css 文件移走。一个月后发现回到顶部图标异常,一番排查发现原来是css文件的锅,详情见 不要移除WordPress的dashicon.min.css文件
  2. 为了测试Nginx的fastcgi缓存效果,就在location中加了指示缓存是否命中的header。后来无意间发现一些预设的header没有出现,又是一番看官方文档加排查才发现原因竟然是新增了header的缘故。详情见 小心Nginx的add_header指令
  3. 本站主题改为BunnyPress后,不知道哪天脑子抽风在自定义中禁止jQuery。一个月后发现文章的评论功能不能用,文章下方的点赞按钮也不能正常工作。这个问题困扰了我一个多月也没找到原因,差点认为站被黑了。后来逐步对比前后台输出,才发现是jQuery没有引入导致,真是惊天大坑;
  4. 本站之前受到过CC攻击,因此研究了防CC措施,同时针对WordPress的弱点做了严格限制,详情参考 WordPress防CC攻击设置教程。在设置中,对搜索请求进行了重定向捕捉,当时不知道怎么想的,在捕捉的location中加上了 fastcgi_param REQUEST_URI /;一行。这个指令带来的后果是昨天发现搜索结果无法翻页,还以为是主题的问题。换其他主题发现问题依旧,意识到应该不是WordPress或者主题的bug。经过不断的排查,还特地去看WordPress文档进行hack修复,最终回想起防CC攻击设定的Nginx配置,原因才真相大白。这也是一个惊天巨坑,一般情况下不会碰到,也不会被注意到。

从上面例子可以看到,就是随手改一下东西,坑就已经埋下,而且还很难被发现。这些例子也让我更深刻意识到测试case和代码覆盖率在持续集成中的重要性。

留言评论

发表评论

邮箱地址不会被公开。