乐趣区

程序员的修炼我们为什么会编写BUG

jiezi

在最近的一周, 我维护的业务系统出现了很多坏毛病, 一周七天 crash 掉了 4 次, 每次都需要都是因为一点很小的问题, 触发了蝴蝶效应, 导致整个系统全盘崩溃, 于是产生除了叙述本篇的想法, 当然这并不是为了掩盖我在 Coding 上的一些细节处理和职责疏忽，只是为了从根本的细节上去分析这些问题。

(一、) 为什么会产生 BUG

首先我们需要尝试理解一下什么 Bug?

关于 bug 的解释

bug 是指任何计算机程序或硬件系统中的错误，故障或缺陷。错误会产生意外结果或导致系统意外运行

简单来说:bug 就是程序出了问题, 产生了意外的结果, 没有按照预期的结果去运行。

产生 Bug 的原因有很多种:

  • 开发者水平太低
  • 不同的编译及运行环境
  • 与需求方沟通不到位
  • 马虎大意、考虑不周
  • 放飞自我,Coding 全靠自嗨
  • 选择了错误的或者运行不稳定的第三方库

以上原因总结, 主观和客观因素都会影响到 Bug 的产生, 正如误差不可避免一般, 我们应该对自己写出的代码进行测试、分析、” 沟通 ”.

(二、) 如何尽量避免 Bug

鉴于以上 bug 产出的原因, 我们可以通过这些一些对策来避免 Bug 的产生, 下面是一些常见原因分析和处理对策。

1. 开发者水平太低

在进行系统的构建中, 部分开发者可能通常因为开发经验过少, 或者语言不熟悉, 会编写错误的代码, 然后未经过代码测试和审计, 便进行提交和上线操作, 导致了异常的引发

解决方案:

  1. 如果是语法错误, 可通过一些 ide 的代码检测器, 或者语法检查来检测代码可否正常运行.
  2. 如果是 PHP 等弱类型语言, 可使用静态代码扫描工具来发现程序中明显的语法错误.
  3. 编写足够的测试用例, 覆盖整个模块的语句
  4. 请求你的伙伴进行 CodeReview(代码审计), 来改善代码的质量和发现代码中的缺陷

2. 不同的编译及运行环境

因为业务的拓展和服务支持, 需要部署多个不同的运行环境中, 如: 转账系统，你在测试环境中转账了 1000 元给用户小明, 小明却在生产环境中收到了这 1000 元, 并成功进行提现, 往往因为没有环境判断, 导致了失误的操作!

解决方案:

1. 在代码中多进行注释说明, 标明哪些函数会在其他环境中操作和运行

2. 加强环境逻辑判断

以下是我在使用的一些标注和说明, 其他开发者或我本人再次阅览该代码时, 就会得到一个清晰的运行结果.

 /**
 * 执行该函数时, 会根据 env 环境进行处理, 详细如下
 * prod(生产环境): 会启动队列对视频进行转码、截图、写入到生产数据库中操作.
 * staging(预演环境): 不会启动队列, 但会写入 staging 数据库中
 * test(测试环境): 会启动队列对视频进行转码、截图、写入到测试数据库中操作.
 */
$video = $this->uploadVideo($file);
$queue = $this->videoQueue($video);

3. 与需求方沟通不到位

这是经常程序员与产品对撕的一个很重要原因,TA 想要 A, 而你却做出了 B, 于是你们产生了很大的争论

解决方案:

  1. 多进行沟通, 需求进行反复确认, 不要上手就进行编码, 先进行分析。
  2. 通过 PM 系统, 留存需求规划与变更记录, 以便每一次业务更改, 都得能与系统中的问题对上号.

4. 马虎大意、考虑不周

编码时以为问题很小, 修改代码, 不走调试与测试流程, 直接上线.

解决方案:

  1. 不要盲目过于自信, 相信自己的主观判断, 一定走测试流程, 确保改动无误!(这是我之前经常犯的错, 然后系统出了问题, 我的 fix commit 从 1 变成了 N ….)
  2. CodeReview(代码审计), 这是一个最好的办法, 当然需要耗费不少的人力, 但是能最大的去降低缺陷和错误.

5. 放飞自我,Coding 全靠自嗨

解决方案:
无

这类朋友不适合做开发者, 适合去做创造者!

6. 选择了错误的或者运行不稳定的第三方库

有时候为了省略接入时间, 往往会忽略掉一些大型库, 因为业务的支持只用到了一小部分, 所以我们有时候会去选择一些 mini 库, 最后由于不稳定或方案不成熟, 出现错误的运行结果

解决方案:

  1. 如果业务级别比较高的话, 不建议采用冷门或者无人问津的 mini 库使用, 因为出现问题的损失会更大.
  2. 进行反复测试, 开发人员对核心代码进行阅览, 确保正常无误.
  3. 自我组织编写或实现, 但是学习和开发成本比较高, 小型规模不建议采取.

(三、) 多与代码进行 ” 沟通 ”

“橡皮鸭调试法”是我在阅读《编写可读代码》一书中看到的一个技巧, 我在一个人开发的时候会使用这个技巧, 我认为是一个不错的选择.

(四、) 总结

我们为什么会编写 BUG, 如果没有 BUG? 开发和测试不就失业了吗? 当然这只是一句玩笑话。
在此引用知乎上一句很有意思的话.

编码也亦如此, 因为很多主观和客观的因素, 导致程序执行了错误的逻辑, 产生了不如预期的结果, 作为一个合格的开发人员, 我们应该尽力确保程序稳妥运行, 减少失误和异常。

正如 CZG 提到的 ” 你写的每一行代码，都是你的名片 ”, 我们每个人都义务去维护好这张名片, 让其他人对这张名片充满敬畏之心, 而不是 ”what shit code”, 诸君共勉！

退出移动版