• 自己写的 Bug 流着泪也要改完
  • 发布于 2个月前
  • 147 热度
    0 评论
虽然今天仅仅是 1 月份的第四周,但其实今年的工作已经开始收尾了。从下周一开始,你就会发现周围的同事逐渐变少。对于大多数漂泊在一线城市的程序员来说,一年回家的次数屈指可数。所以,很多人已经归心似箭了...

扯远了,回到正题。

年底了,公司新模块开发暂时停止。所以这两天就没有开发任务,一直在调 Bug。

作为一个程序员,我是本能的反感 Bug。

代码提测时,最害怕的就是测试退回,给我反馈各种问题。

这不,这两天闲了,把之前遗留的不着急或者偶现的 Bug 都翻出来了,一个个的 Debug 调试。。。

真的是把我虐的欲仙欲死,所以才有感而发想写这篇文章。

我们到底能不能写出没有 Bug 的程序呢?

答案是:非常非常困难。

就算你的编程功力足够深,编码习惯也非常好,测试用例也很完整。但只要项目的规模稍微大一点,逻辑稍微复杂一点,会避免不了漏掉一些特殊场景或者极端情况下才出现的问题。

拿我自己举个例子吧。

最近涉及到一个网络模块的业务场景,我刚开始只考虑到了 Wifi/4G 的网络正常或断网的情景。我疏忽了 Wifi 突然断开切换成 4G 或者 4G 进入室内,自动连上 Wifi 的情况。

我在自己自测的时候,完全没有想到这个情景。自测下来很完美,一点问题都没有。

提测之后,啪啪啪打脸。

还有很多其他欠考虑的场景,我就不一一举例了,毕竟不是什么光彩的事情。

我就在想,平时编程的过程中,我们如何才能尽量减少 Bug 的产生呢?

我想到的有以下几个点:

1、正式开发前,做好准备工作。一个开发任务分配下来,不要直接上手就写。可以先在自己的小本子上画画写写,勾勒出大概的项目设计,业务难点。有没有重点需要攻克的技术,提前跟组长或技术经理报备好。这样再着手写代码,就不容易出现卡壳,影响心情,导致 Bug 的产生。

2、提前做好项目的任务规划,合理安排开发时间,减少加班的次数也能一定程度上少写一点 Bug 。毕竟有哪个程序员愿意天天加班呢?

3、开发过程中,要及时测试。不要等到全部的功能写完在一起测试,这样很容易出大问题。最好的方式就是做完一个小功能,就自己先跑起来,点点看看。及时测试,及时发现问题。早发现,早解决。

4、要重视 IDE 的报错或者警告,不要觉得能跑起来,就没问题。可能当前开发的部分还无关痛痒,但是多积累几个警告以后,可能会引发更大的问题。所以每当遇到 IDE 报错的时候,自己一定要点开看看,不要就随他去了。

5、整个功能写完以后,先自己多自测。全面的考虑使用场景,只要能想到的特殊环境都要测试一下看看,不要想着有些环境很少有人用,就不测试。往往这些场景下的漏洞,就可能引发崩溃。

6、自己平时有事没事就可以进行 Code Review。但是看自己的代码容易出现当局者迷,所以最好找个要好的同事,互相 Review 代码。省的在提交之后,被组长 Review 不通过,打回重写。。。

7、常见的 Bug 或者已经犯了几次的问题一定要记录下来,空下来的时候,经常多翻翻。好记性不如烂笔头

8、可以向资历老,技术牛的同事请教下经验,一般程序员还是乐于助人的多,不会藏着掖着。开发经验多了,避免不了遇到的Bug也会多一些。每个老师傅都会有些心得,所以需要学会向同事请教。

虽说自己现在比几年前仔细多了,但今年还是“创造”了不少 Bug ... 深知自己还差得很远,需要提高和注意的地方还有很多。

自己写的 Bug ,流着泪也要改完。

好了,我继续 Debug 了。。。

用户评论