Bugfix随想录

从敲下第一个字符开始,八阿哥(Bug)就是磨人的小妖精,形影不离,简直比真爱还要真爱。

随着项目的扩大,功能的增加,Bug出得越来越快,越来越多,Buglist变的越来越长。

慢慢地,项目的节奏明显变慢,Feature越来越难增加,Bugfix的时间越来越长,团队逐渐变得死气沉沉,原本温顺的程序猿变得暴躁,进而演变成团队成员流动性提高,流失率提高。


总结我个人的工作经验,以及参照业内的一些文章,这种变化的轨迹也非常典型。

1、一个新Feature会与已有的Feature产生联系,也会依赖于已有的组件。而这些旧Feature或组件,因为有Bug还没处理好,接口不稳定,行为不可控。一个依赖于不稳定的系统的系统,必然是不稳定的。

2、一个依赖于不稳定的组件而组成的系统,要让其相对稳定地工作,必然需要在其内部添加修正,也就是workaround。其内部逻辑,需要实现原本不应当自己来承担的逻辑。

3、前两步还会继续滚起来,继而演变成workaround的workaround的workaround。

这时候问题来了:原有的带Bug的组件,是否应该调整或修复呢?


这是一个两难的境地:

1、调整,那么workaround就会失效。workaround的workaround的workaround也会失效。

2、不调整,那么按照以往的步骤,一个新Feature的实现,需要对其所依赖的所有组件进行修正,节奏只会越来越慢。


当开发节奏变的缓慢,这是一个非常不好的征兆,因为一旦开发节奏变的缓慢,除非进行根本性的改变,否则只会越来越慢。这不是一种时间可以解决的问题。打个比方,一辆自行车,就算是全世界最好的自行车运动员来骑,比速度也比不过一辆汽车,比行程更是完全不能比。


而面临这个两难境地,决策通常有两种:

1、放慢、甚至停下步伐,回顾、整理以前的实现和需求,进而制定改进计划和方案。但这样会面临市场和用户的压力。

2、招聘更多的工程师来进行修复工作。前几天看到一个新闻,Facebook的iOS工程师有429个人。


这里着重讨论一下第二种方案,也就是大多数公司会采用的方案。

这种方案有效,需要建立在几个前提上:

1、Bug修复的速度,赶得上Bug出现的速度。

2、Bug修复的收益,大于成本。


这里先插入一段,一个有工作经验的工程师,从第一天进入公司开始,到他能贡献代码,需要经历多少步骤。

1、每个产品都有BaseCode,熟悉这个BaseCode的结构和逻辑,需要时间,少则1个月,多则半年,视具体项目大小而定。这段期间,看文档,和老司机聊天是主要工作。看代码的作用,可以说几乎为0。

2、经过了熟悉阶段后,可以进入到边角性的修复工作。一般从修复和主要功能无关的UI开始。

3、再过了一段时间,等工程师对产品的后台逻辑有了更深入的了解之后,就可以开始从事一些相对核心的主干功能的修复。


好比手术一样,一个主刀医师切你一条血管,只需要几秒钟。但他要知道切那条,怎么切,需要几年。


简单来说,一个有行业经验的新员工,从第一天加入公司,到他可以修复相对重要的Bug,中途至少,需要几个月的时间。


熟悉代码库的逻辑,有几个东西起着重要作用。

一、需求文档,但这个非常可能落后于进度;

二、实现的结构的描述文档,这个在国内的大环境下,就是呵呵呵呵,几乎没有;

三、老员工的口述,但由于进度逼迫,他们一般会用来处理非常紧急且致命的Bug,同时,由于他们是对整个项目最熟悉的人,最赶的任务,最迫切的任务,都会交给他们。


回顾一下上个问题,通过招聘更多的工程师,能解决Bug积累的问题的前提,有几个:

1、Bug修复的速度,赶得上Bug出现的速度。

2、Bug修复的收益,大于成本。


我们再来看看这两点能否被满足。

老成员一直保持高强度的输出状态,由于一直赶进度赶任务,没时间重构,没时间补文档,也没时间和团队的成员同步设计概况和进度。而新成员,因为对代码库的结构和功能预期不熟悉,所以无法有效地分担相对重要的开发和修复工作。更可怕的是,在不熟悉代码结构和功能的情况下,任何的修复,都可能引入更多的Bug。所以第一点,不能被轻易满足。

要熟悉一个乱糟糟的代码库,对比起一个结构清晰的代码库,更需要时间,项目越大,功能越多,这个时间就越长。而软件开发的成本,最大的开销,是人力成本。目前一个有3年工作经验的工程师的价格,按照目前市场的价格,至少至少1万元起。对公司而言,算上社保公积金等等,公司的开销至少1万5以上。假如一个这样的工程师,进入团队,熟悉一个代码库,需要3个月。3个月之后,他走不走,是否能了解清楚代码库,另说。也就是说,这个人要发挥作用,公司至少至少要花接近5万元。而这个项目本身值多少钱呢?影响客户有多少呢?

招更多的人来填坑,各位要不要拿出计算器计算一下成本收益呢?


是不是所有的Bug都需要被修复呢?这个问题的深层意思是,“Bug修复的数目,是不是越多越好”。

我的答案是“否”。大部分的Bug产生的原因,可以归入以下几类:1、需求描述不清,理解、实现有二义性;2、代码的变化,没赶上需求的变化;3、需求之间产生内在冲突,实现了A,就不能实现B。而需求的描述,很大部分又是以“看得见”的方式来描述的,说简单点,就是界面上、用户操作顺序上去描述的。而这又是很容易被修改的部分。“加个简单的按钮,这里默认值不对”,这种大多数可以归入1或2。这种Bug是产生得最多的,也是最容易修改的,只是需要时间去找到实现的细节。

需求间的冲突,这种是最难搞的。说实话,我觉得这种不能算入Bug,因为实现了A,就不能实现B,实现了B,就不能满足A,无论代码怎么写,都是错。这类Bug往往又是很多Bug的深层原因。

如果一味地追求Bug的修复数目,那么很容易得到一种情况,简单的表面的Bug抢着干,也频繁地出,深层的Bug没人赶动。如果把KPI考核引进来,把Bug的修复数目(而不是影响程度)作为一个比重不低的标准,问题会变得更加复杂。

需求间的冲突,在项目合并和对接的时候,会更容易暴露。

我最讨厌无底洞般的Bugfix的地方,在于根源性的Bug没人敢动,因为牵连甚广,而大多数的小修小补,并不会解决影响体验、或者是直接决定用户买不买账的的根源性问题。也就是说,虽然大家都很努力,但是并没有什么用,到头来只耗费了时间,能否感动自己还是一个未知数。

就拿Evernote为例,曾有几次我动过购买高级账号的念头,因为它的浏览器插件、Mac下的客户端,真的解决了我很多问题。但最终,阻碍我购买的,原因就一个:它的编辑器有Bug。这个Bug有多影响体验呢?举个简单的例子,我选定一些字,设置了格式,undo在redo,结果居然不一样?就更别说莫名其妙的锁进和空行问题了。Evernote放着这个编辑器不管,转而去开发协作,甚至加入了团队IM功能。只要分析一下,开发团队协作,无论怎么搞,归根到底还是要回到编辑功能上去。一个笔记软件的编辑器不稳定,你围绕着这个不稳定的编辑器,无论你周边做的多么成功,附带功能多么完美,用户并不买账。


而软件一但走到这个地步,说句不好听的话,很有可能回天乏力。


软件和建筑很类似,都有结构,有规模,都需要精妙的设计和准确的实现。区别在于,一个建筑工人不大可能轻易毁掉一动大楼的根基,而工程师,要毁掉一个软件的结构,只需要删掉一行。


软件项目是一个系统工程,尤其是在当下这个什么都联网的年代。因为一个软件的设计,需要考虑自身的需求,在互联网时代,更需要考虑他人的需求。一个软件的价值,在于它对数据的操控能力。这种操控能力,建立在需求、实现的条理性和精确性之上。而要得到这种条理性和精确性,需要用系统的眼光去看待问题。而系统,是不可能通过散沙般的组织方式得到的。


互联网的世界,是赢者通吃,弱者渣渣都没得剩。因为一切都联网了,联网需要标准和统一。


我一直提倡,不要盲头跑,如果出发的方向错了,跑得越快,错得越远。

你可能感兴趣的:(Bugfix随想录)