• 为什么交付后,软件还是会有bug ?
  • 发布于 2个月前
  • 312 热度
    1 评论
一天,有个甲方问我:“开发好的程序,为什么会有bug?” 我虽然心里暗暗觉得这真是个stupid的问题,但是我还是能够理解甲方的感受----“我付钱让你们开发的软件,为什么不做成完美无瑕的再给我?更郁闷的是,为什么日后出了问题找你们修,还要额外收费?”

嗯~ 出于对我们所提供服务的负责态度,我还是有必要跟甲方大大把这个问题解释清楚~

我先解释下“为什么交付后,软件还是会有bug?”

正面来说,就是软件是由一行行的代码组成的。程序员在编写这么多的代码过程中,难免会在逻辑上或者输入上有一些疏漏,这些疏漏就是bug了。

举个例子来类比的话,程序员写一个软件类似于作家写一本书。即便经过多人审阅,一本书出版后还是难免有错别字、逻辑上的错误、情节上的不合理等。同理,即便上线之前软件经过层层测试,最后交付之后也难免还是会有一些没注意过的细节问题。

错误其实是永远都会有的,我们需要做的只是“尽量”将它控制到最小。

再延展一点说,可以说你日常用的每一个软件,每一款APP都是有bug的,只是你没有碰到有bug的地方,或者你碰到了但是你没注意罢了。微信、淘宝也不例外哦。

多罗嗦几句,其实所有的技术都是大概率有效,而不是100%有效

工厂标准化、流水线生产,你觉得生产出来的东西应该都是一样的吧?不,只是大概率一样,还是会有很多次品,所以工厂生产产品很重注一个叫“良品率”的指标,这个指标就是说“大概率有效”里面的大概率有多大。

产品生产出来之后还要经过质检,质检之后的产品应该都没问题了吧?不,质检都是抽样质检,比如1万件产品里面检查100件,然后计算“良品率”,“良品率”达标则全部产品过关,也就是说有9900件产品其实是没有检查过的,只是根据估算应该大体没什么问题。(当然检验出来不合格的那几个一定会扔掉)所以每1万个消费者里可能有一个人会买到次品。

甚至通过了质检的产品,也有出现整体设计问题的可能。因为质检的标准是根据以前的经验制定的,可能没有考虑到近期出现的新情况,同时即便是旧有的情况,质检标准也不会面面俱到地都检查到,质检都是只检查若干个关键指标。所以我们在新闻上才会时不时地听说某个车企又召回了多少量某型号的汽车。

每一个环节都不能保证是100%没有问题的,也就是说,无论生产什么,都不能保证每个产品都达标,商家能做的就是在你买到次品之后给你换一个好的。

说到这里,是不是感觉生活顿时没有安全感了?我家的房子会不会质量不达标,突然倒塌了啊?走在马路上,会不会马路质量不达标,突然出现个大窟窿啊?你很难碰到,但是不得不说这有可能,只是可能性非常小。相比于这些致命性的问题,你遇到的更多的产品不达标通常都是“我的桌子商家说是120cm高,但是实际上只有118cm高”,“我的软件承诺支持Android, IOS两个平台,结果Android中魅族的手机使用时会出问题”等等,大多数不合格、不达标,都是可以“忍受”的小问题。

其实世界上本没有100%的安全,天上掉下不明物体砸死无辜路人的故事也是不胜枚举的。所以,无论什么产品,厂商的职责都是降低风险到最低,但不是消除风险,因为“消除风险”本不科学。

整个世界都是如此,软件开发也不例外。所以,也请各位甲方大大不要再苛求程序员写出“完美无瑕”的软件了。如果哪个程序员承诺自己的软件是“毫无缺陷”的,那他不是自大,就是骗子。

“我们可以接受出现问题,但是为什么你们修复问题还要收钱?”

首先,严正声明,我司完成的项目,都是有三个月免费质保的,头三个月修复都是不收钱的!

那为什么三个月后要收钱呢?

这里,我先抛出一个事实:即便你不更改软件的代码,你的软件也不能保证不会突然坏掉。原因是,现在的软件都是和其他软件或者服务配合着完成功能的,软件都不是完全互相独立的,其他的软件或服务如果发生了变动,就有可能会导致你的软件“坏掉”。拿目前最火的微信小程序来说,如果你实现了一个自动获取用户昵称和头像的功能,那么可以预计未来几个月你这个功能即将失效了,因为微信马上就要取消自动获取用户昵称和头像的功能了,改为要求用户明确地点击按钮,才能获取昵称和头像。你的程序可能什么都没改,日后新用户的昵称和头像就突然获取不到了。

也就是说,你的软件坏掉,并不是我们开发人员的错误,而是这个软件所依赖的其他软件做了改动而导致的。因为这是一个没有预料到的改动,开发团队需要为此投入没有预料到的人力成本,所以这部分改动需要收费。

还有一种可能,是你的应用规模变大了导致软件坏掉了。同样是实现即时通信的功能,做一个给100人用的产品,和做一个给100万人用的产品,其中的实现成本可能有数十倍的差别。软件交付后,如果您的软件使用量迎来爆发式的增长,那么很可能很快你的软件就需要改版重做了。你可能会问,难道不能一开始就设计为支持100万人的产品么?当然可以,不过您就要为100万级别的架构支付对应的项目费用了,这可能是非常贵的。对于绝大多数的甲方来说,做一个规模合适、成本不贵的系统,才是最明智的选择。等项目用户量大了,再做改版,毕竟这个时候你心里更加确定投入这么多钱是值得的了。

这种情况下,为适应新的规模带来的成本,是没有考虑在最初的外包合同中的,所以这部分适应性改动是需要额外收费的。 

另外,由于有3个月的保质期,所以实际上3个月后纯粹的遗留bug其实很少见的。这时候甲方如果再找技术团队要求修改bug,90%的情况是甲方使用不当,或者误操作导致的系统故障。这类故障本身不是技术团队的错误,但是发现错误、重现错误、调试错误却要消耗大量的时间(有时候找问题所在要一天,修改bug只要一分钟)。如果是免费的,甲方无休止地询问,技术团队也是承担不起的。所以才会有3个月后,bug修复都是需要单独收费的规定。

总结
说了这么多,也无非是想让甲方大大们体谅一下程序员们的处境。人非圣贤,孰能无过。程序员和bug的战争是无休无止的,请甲方大大们多给程序员一些耐心,让世界多一份温暖~
用户评论