我也说说Bug那点事

喜之郎 发布于 2014/04/15 23:40
阅读 587
收藏 1

        工作了几年,对写代码时出现Bug已经是习已为常了。看了两个帖子面试的时候老板问我对出线上bug罚款怎么看?和哈,喷下代码质量两个帖子,觉得情绪猿的思想都好偏激。
        我只说说我自己的想法。对出现的Bug罚款这种事我想肯定是个不懂技术的管理者提出的管理办法。通过几年的编码,我发现写程序真的不可能不出现Bug。现在问题就是一个出现多少的问题。很多测试人员会抱怨开发人员自己都没测试过一遍,就交给他们测试。这无疑是开发人员不付责任的表现。然而程序员也确实可以做到像野鬼说的那样有非常强的责任感,交出的代码只有极少数Bug。

        我自己的感觉是在团队中开发人员与测试人员比例恰当的条件下,允许程序员出现一定数量的Bug可以最大的缩短项目完成时间。

        当然这个"一定数量"要项目经理合适的控制了。如果项目经理要求每个程序员都只出现极少数Bug,那么程序员将耗费大量的时间在找出这几个难以发现的Bug上,而耽误了开发时间。程序员这样搞会把测试人员的事干了一部分,因为“术业有专攻”,所以从整个项目进度来看是得不偿失。如果一个团队没有专门的测试人员,那程序员也只有这样搞了。况且对于需求的理解,每个人都不一样。自己测试自己写的代码也不合理,好比辩论赛里面自己既是正方又是反方一样的道理。一般情况,四个开发人员可以搭配一个测试人员。团队测试人员越多,“一定数量”可以稍多。如果在时间非常紧迫的情况下,开发人员当然在没有罚款的压力下有更高的产出。这是我的切身体会。然而开发人员的底线就是开发完自己测试一遍,代码能否正常运行,是否达到功能目标。
        最后我还想说,Bug没有严重级别的说法。因为一个标点符号就可以导致整个程序无法运行。所以给Bug评严重等级意义不大。当然就不存在越严重的Bug罚款越多的说法了。

        洗洗睡了。晚安。各位。


以下是话题补充:

@喜之郎:任何问题都应该以概率来算的,要杜绝一种问题,势必耗费大量的精力。允许一定概率的Bug出现才是人性化的管理,才不会给团队带来负能量。另外,Bug虽没有严重级别的说法,但是有修复的优先级的说法。因为有的Bug不修复后面的测试无法进行。 (2014/04/16 08:31)
加载中
0
周翼翼
周翼翼

我们项目都有一个"转测试"的概念, 所以开发测试,和转测试后测试部的测试是两个项目动作.

如果开发没有测试出来, 转测后测试部测出一堆问题, 开发肯定是要改进的. 而罚款只是为了逼迫开发对自己的测试工作进行改进.

BUG绝对有严重级别的区分, 但不是以引入BUG的原因(一个标点符号还是别的什么高深的错误), 而是以"影响范围"来论. 比如一个BUG导到1个人上不了网和100万人上不了网, 难道严重级别还不够明显吗?


0
雨翔河
雨翔河

无法给BUG评级,但是有时候低级错误导致的问题就不可原谅,程序员本身应该避免犯低级错误。

0
中山野鬼
中山野鬼

引用来自“周翼翼”的评论

我们项目都有一个"转测试"的概念, 所以开发测试,和转测试后测试部的测试是两个项目动作.

如果开发没有测试出来, 转测后测试部测出一堆问题, 开发肯定是要改进的. 而罚款只是为了逼迫开发对自己的测试工作进行改进.

BUG绝对有严重级别的区分, 但不是以引入BUG的原因(一个标点符号还是别的什么高深的错误), 而是以"影响范围"来论. 比如一个BUG导到1个人上不了网和100万人上不了网, 难道严重级别还不够明显吗?


开发测试,是个必要工作。开发自己都不测测,这和写个帖子不检查错别字没有区别。比如我这样,哈。不过写个帖子有错别字,多大事,开发了自己不测试,那是好大的事。。

0
修改登录密码
修改登录密码

bug发现的越早越好。如果一个bug在编码阶段被检测和解决的代价为1, 那么在测试阶段解决的代价就是8, 在试用版中解决的代价是64, 到了正式版发布后解决的代价是512。 典型的例子就是最近比较火的心血bug。可以设想如果开发者在开发中就能解决该问题,能为现在的应用程序降低多少代价。

控制bug产生的源头才是最有效的方式。把代码扔给测试人员去发现问题,是不负责任的,也是效率比较低的方式。 测试部门,并不能保证发现所有的缺陷。最重要的还是让开发者规范起来.

bug带来的后果可能非常严重。对于设计者来说可能只是修改一个变量一个符号的问题,但对于最终用户来说,可能是灭顶之灾。了解ARINC653  DO178B/C的可能会听说过很多类似的案例,机毁人亡的案例比比皆是。

所有的bug都是可以追踪的。也是可以分级的

两个码农作同样的工作, 同样的时间内,一个人完成了10万行代码,但是有1%的bug率,另外一个人只完成了5万行代码,但是有0.1%的bug率。 你认为谁的效率高?你想雇佣哪个?从我来说,我愿意雇用后者,因为他的代码质量可控程度更高, 也意味着他的水平远远高于前者



修改登录密码
修改登录密码
回复 @喜之郎 : 比尔盖次创业能成功,能证明程序创业可以成功
喜之郎
喜之郎
回复 @eel : 比尔盖次创业能成功,也很典型,那是不是能证明程序创业都能成功呢。荒谬!
修改登录密码
修改登录密码
回复 @喜之郎 : 这个例子很典型, 能帮助你清醒的认识到程序员之间的水平高低。更多的情况下,我们不是需要那种神速编码者,而是需要一个稳定的编码者
喜之郎
喜之郎
请不要举例子去论证一个命题的正确性,因为证明一个命题正确,举一万个例子也不够。
0
修改登录密码
修改登录密码

那些仅仅为了完成更多代码而把找bug的工作丢给测试部门去做的, 本身就是对自己产品不负责的表现。没有做过产品没有和客户打交道的人,是无法从项目大局上来理解这个问题的。没有改过别人代码的人, 是无法理解那种愤怒的。

作为项目管理者,更重要的是关心项目受控,而不是盲目的赶进度。赶进度只会给自己埋下更多的地雷。  我从来不要求我的工程师每天完成几百行代码。只要他们平均每天能完成30-50行高质量的代码就OK。时间预算上我会尽力帮他们争取时间,但bug绝对是一个重要考察优秀程序员的指标。每个缺陷都会根据影响的范围、后果、难度进行评价,并决定是否需要惩罚。

实话说,现在写代码谁不会写啊? 中学生码代码不比你们慢。 但区分程序员能力高低的指标之一就是调试和解决bug的能力。

修改登录密码
修改登录密码
回复 @喜之郎 : 这不是什么偏执。 俗话说快了萝卜有了泥, 质量成本时间三要素, 如果缺陷层出不穷,意味着你的开发时间就要延长,同样的成本也会增加。做过项目的人对此应该深有感触。
喜之郎
喜之郎
质量,时间,成本项目管理的三要素,要综合考虑,你太偏向质量的话,另外两个就没法保证。所有项目管理要找三者的平衡点。偏执就是走极端。
0
修改登录密码
修改登录密码

如果一个团队的产品因为某个人的bug连连而不断被退回返工测试(听说过归零测试吧),大家会怎么想? 对于bug率远远高于团队平均水平的程序员,只有请他出去了

0
修改登录密码
修改登录密码

很多程序员对bug不以为然,以为有了bug就加班通宵解决就OK了,罚款更是觉得是对自己的侮辱。如果你们能从用户的角度多考虑下,就不会这么认识了。 如果你做的软件是自动驾驶汽车上的软件,如果是导弹/飞机上的软件,如果是动车上的信号感应系统,如果是卫星/火箭控制软件,或者核电站的控制软件,你的bug造成重大事故后你还在为自己那丁点罚款哀号?  不要总是在血的教训以后才醒悟


0
喜之郎
喜之郎

引用来自“eel”的评论

很多程序员对bug不以为然,以为有了bug就加班通宵解决就OK了,罚款更是觉得是对自己的侮辱。如果你们能从用户的角度多考虑下,就不会这么认识了。 如果你做的软件是自动驾驶汽车上的软件,如果是导弹/飞机上的软件,如果是动车上的信号感应系统,如果是卫星/火箭控制软件,或者核电站的控制软件,你的bug造成重大事故后你还在为自己那丁点罚款哀号?  不要总是在血的教训以后才醒悟


你又举了些个例子,看来你还是不能理解一句话
要证明一个命题正确,举一万个例子也不够。
请认真理解一下。因为你举的都是特例。而大多数人开发的软件都不是导弹/飞机上的软件,而是像osc这样的软件,即使经常出现提交错误,也不会有多大影响。
喜之郎
喜之郎
回复 @eel : 我认为不该追责。因为openssl大概是个比较牛的人写出来的。具体有多牛我就不清楚。这种程序给人类带来的利益远大于这个Bug带来的后果。用这么久才出一个Bug,这概率已经相当低了,人之常情,完全可以理解。
修改登录密码
修改登录密码
我举的例子是有点特殊了. 就以osc这类网站来说吧,假如某个漏洞导致大量用户密码和隐私被窃, 你又如何看待这样的bug? 你觉得加班改两行代码程序员就没有责任了? 如果openssl是个商业化软件,你认为出现心血漏洞程序员该不该追责?
返回顶部
顶部