写代码不免出点 bug,没有人可以保证自己写的代码不出问题,而那些没有被挖掘出来的 bug,便成了后来者哭笑不得的坑...

这段时间公司全面 https 改造,涉及到域名的迁移,域名的迁移不是 nginx 做个映射就完事儿了,还有各种代码的去 schema,各种组件的搬迁,算是一个大手术!我看最近百度主站也升级到了 https,期间应该出过一次问题吧,貌似回滚了一次,他们遇到的坑应该还不算多,只是 www 域升级,而不是全网。公司最近出了不少的问题,大小问题都有,表面看是前人挖的坑,实际是整体架构思考的有欠缺。

当我们放下一个项目转投下一个时,手头的东西就要转交给他人处理,或者..不再有人处理,可代码还在那里,搞不好你就引用了别人的东西,保不准哪天别人的代码里就爆出了个大 bug,当然这里的"别人"也可能是 你!我们既不希望自己是受害者,更不希望自己是施害者。

1. 如何挖坑

挖坑可不是一件简单的事情,你写出来的插件、组件、代码,很可能被很多人用到了,各种业务场景下狂奔你的代码,一堆测试人员检测你的bug,所以在项目中埋坑可不是一件容易的事情。

那么如何埋坑呢?可以参考以下方案:

  • 在一个文件中放一坨很长很长的代码,不加注释,不解耦程序
  • 把判断都放在一层嵌一层深深的逻辑里头
  • 程序中临时加入几个全局的标记变量,在很多地方改变变量的值,在很多地方使用变量的值
  • 不考虑多变的场景,不实时容错,让他按照你脑子的轨迹跑
  • 到处散播不同版本的代码,不整理统一的文档

如果这些方案还不够你挖坑,我想你团队同学的技术水平也真真是太高了。

很多时候,我们都是不经意间留下了隐患。当自己写的东西被其他人使用后,程序需要兼顾的场景就会增多,出现的问题也会变多,这个时候我们不得不完善自己的代码逻辑。结果就是,逻辑耦合度高了不少,代码层次深了不少,出错的概率也就增加了不少。

所以在设计一个功能或者组件的时候,该考虑什么,不该考虑什么,一定要理清楚。并不是所有东西都适合往代码里加,我们不是在做 ExtJS 这个整体方案,也不是编织一个底层的操作库,只是用少量的逻辑整合离散化、个性化的业务,这些逻辑越少越好,与核心逻辑无关的内容就必须抽离出来!

2. 使劲踩坑

如果说挖坑是一件很有难度的活儿,那踩坑就更难了。其实可以说难的不是踩坑,而是发现自己踩坑了。

在一堆巨量的文件中找出「因把等于号写成恒等号」造成的 bug,这不是轻松的事情,可能你在 debugger 的时候进入了别人的代码领域,对着别人巨长而又没什么注释的代码,估计当场就晕了,更晕的是,自己却还在怀疑这到底是不是这堆代码里头的问题。团队合作中,我们心里默认相信队友,队友产出的代码是没有问题可以直接拿过来使用的,所以一旦出现问题,我们怀疑更多的是自己,质疑别人需要很大的勇气,尤其是质疑那些成熟的框架,用了很多年的代码。

那么如何踩坑呢?我们可不喜欢踩坑,有的坑踩进去就跳不出来了,最后只能选择其他方案处理。很少有前端同学写程序的测试用例,可能还有一部分同学根本就没听说过什么测试用例。而在后端中(比如nodejs)没有测试用例的代码就是一堆废代码,除了自己可以拿着用用,别人根本就不敢用的。那么测试用例会考虑做那些事情呢?简单点说:

  • 写出有问题的代码,让程序按照期望的出错方式出错,如果没有,程序就有bug
  • 写出没问题的代码,让程序按照正常的流程返回正确的结果,如果没有,程序就有bug

测试用例要覆盖到程序中所有的逻辑判断,比如 if elseif else 等判断的逻辑都要覆盖进去。当我们的测试代码覆盖了100%的逻辑,那坑位就展露无遗了。

埋坑人的致命弱点就是很少对程序作出异常情况判断,只要找出程序中的异常点,试图以另类的方式触发这个异常,你就顺利踩坑了!

3. 用力填坑

首先,填坑是一种责任。

发现问题是最难的,解决问题只是时间的问题。当我们确认了一个坑之后,第一件事情就是告诉别人这里有坑,你不要踩了。但是最好再多补一句话:你先别踩,等我填好了坑你再来。我这觉得这句话真的很暖人心,程序猿之间的关怀就应该这么赤裸裸的。尽管,有的时候,这个坑不是你挖的..

当我们挖好坑,踩完坑,再埋好坑之后,回头想想自己在团队中扮演什么样的角色,挖坑者还是埋坑者?这必然是有益于成长的。