零Bug的代码是怎么炼成的？

|

码农写代码的最高境界就是：一次写成， 没有bug。

这个境界我是达不到的， 但是我能达到这个层次： 多次写成， 没有bug。

或者更准确的说法是：我已经在写代码阶段把bug都消灭了，测试团队运行完测试用例以后，发现的Bug数为零。

其实没有bug也不准确，因为测试阶段没有发现Bug 并不代表上线以后也没有Bug， 但至少证明这是一段高质量的代码。

可能有人要跳出来了：这不可能，肯定是你的功能太简单了。 实际上我最近写的这段代码应该是属于中等复杂度的：

需要从一个消息队列中获得不同类型的XML消息， 对消息进行解析，更新数据库，获取数据库中符合条件的用户， 发送邮件。

一个比较好的地方是：没有界面 ！ 其实我个人不喜欢写Web界面的，觉得很繁杂 🙂

那零Bug代码是怎么写出来的呢？ 我想了想，主要有这些关键点：

1

透彻理解需求

很多人看到需求以后， 想都不想立刻就开始编码，这是有问题的。

作为码农，虽然不是需求分析人员， 也要考虑下为什么要有这个需求 ， 这个需求有哪些主干路径， 有哪些分支路径 ， 在脑子里要形成一个图谱。

把自己假想成用户，换位思考下，看看用户会如何使用这个功能， 通常你都会发现一些意想不到的情况。

2

良好的设计

把功能划分成接口良好的模块，让每个模块各司其职，又能依靠良好的接口有效合作， 能极大的减少Bug的产生。

这考验就是基本功了 ， 没有速成大法， 只有自己慢慢苦练。

注意：我这里说的设计不一定是文档 ，有可能只是在你的脑子里。

3

处理好边界条件

据说80%的Bug是在“边界”发生的，这些边界条件包括：

输入数据不合法

数组越界

调用的方法抛出异常

文件不存在

文件权限不够

调用其他系统接口时数据未能正常返回

打不开数据库连接

数据库表在初始情况下没有值

运行时间过长导致超时

……

我经常发现， 大量的代码被用来处理边界条件， 有时候甚至比业务代码都要多。

4

充分的测试：不放过一行代码

这是我最想说的，测试不仅仅是测试人员的事情 ， 也是开发人员的事情。

一定要保证每一行代码都被你执行过，不留任何死角。

这一点非常重要， 要么你是通过写自动化测试覆盖到的，要么是手工执行测试覆盖到的。

千万不能是你觉得代码简单，不会出问题，就不管了。

5

考虑代码修改对别的模块的影响

很少代码是完全独立的，总是或多或少和别人扯上关系， 修改这样的代码就要小心了， 这也是个主要的Bug发生地。

一定要考虑代码的修改对别人的影响， 并且做回归测试。

零Bug代码会带来巨大的好处，开发完成，进入功能测试或者验收测试阶段以后， 成本会很低， 测试会很快， 因为基本上都是一次通过，没有bug 就不需要修改代码，返工的成本就不存在。

写出零Bug代码，或者接近于零Bug代码应该是每个码农的追求，其实也不太难，只要用心， 有着对需求的透彻理解，清晰的思路，良好的设计和编码，以及非常充分的测试，基本上就差不多了。

本文文字及图片出自 微信公众号

你也许感兴趣的：

共有 2 条讨论

  1. 343214234 对这篇文章的反应是笑死了
    2016-07-05 16:36

  2. 拜托你了,哪有这么简单……
    第一,就像你说的,大量的边界处理,甚至比业务代码还多,这样的代码在这一个功能中或许可以实现0bug,但是在代码中,它占用了大量的阅读空间,这将使得未来对代码的维护成本急剧增高。
    你说:没有bug为什么要维护?
    抱歉,需求总是会变得……
    所以事实上,0bug的代码,绝不是一个程序员自己所写出来的,它是整个程序所一致的。唯有在整个程序的每一个地方都采用一致性的处理手段去处理这些边界问题,才能在不影响阅读性的情况下对一切边界做到处理。
    然而任何一个大型项目,都不是一个人写的,你虽然能保障你这里不出错,你能保障其他人那里不出错吗?

    /**
    * 这个函数不会抛出任何异常
    */
    public void tester() {
    throw new RuntimeException(“哈哈,你被骗了”);
    }

    回复

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注