0

dogstar - 暗夜在火星的个人页面

 3 years ago
source link: https://my.oschina.net/dogstar/blog/5062306
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

悖论:Bug越多越好

对于互联网技术外行的人来说,直觉上理解,肯定是Bug越少越好的,说明 这个人做事稳定,质量高。

如果你去问测试人员,一位技术开发工程师是Bug越多越好,还是越少越好?测试人员会告诉你,肯定是Bug越少越好,因为他做的功能都符合测试用例和产品需求的要求,千行代码缺陷少,质量高,返工率低。

但作为技术人员的我,发现一个悖论:Bug越多的程序员越厉害。

Bug数量在直观上是反映质量的水平,看似Bug和质量成反比,Bug越少质量越高,Bug越多质量越低。

我们也可以从另外一个新颖的视角来观察。Bug数量在一定程度上和程序员的工作产出、负责的业务范围、承担的责任和沟通对接的密集度有关。简而言之,Bug数量和程序员的效率、能力、职责有关,而且成一定的正比。

下面我来解释下。

再次回顾对Bug的定义

关于Bug,百度百科的定义是:

bug是计算机领域专业术语,bug原意是“臭虫”,现在用来指代计算机上存在的漏洞,原因是系统安全策略上存在的缺陷,有攻击者能够在未授权的情况下访问的危害。

7c4559f638da4e26b18724c2d98686b4~tplv-tt-shrink:640:0.image

图片来源网络

在日常项目开发中,在平时工作中,根据Bug产生的时机和环境,我们可以把Bug细分为:线下缺陷、线上问题、线上故障

线下缺陷,是指在未上线前,主要在测试阶段,在进行功能验收时,由测试工程师发现和提出、记录的Bug缺陷。这时依据产品需求原型、测试用例,在技术人员完成开发并提测后,测试工程师通过软件界面进行操作和人工验收,若发现功能缺失、逻辑错误或显示错乱等问题,则记作Bug,并提给技术人员进行修复。

线上问题,是指发生在正式环境,也就是生产环境,因为会直接影响真实用户的使用和体验,并且对正常的业务运营流程有所影响,需要进行尽快的修复。但影响的范围只是局部功能界面、个别或少数的用户、或极端的非正常场景分支,通常由内部人员或用户发现,然后反馈和收集起来。

线上故障,是情节最为严重、影响范围最大、损失最高的,它发生在正式环境,可能会对公司的收益、服务的客户群体、企业品牌形象、数据库信息等造成不可逆转或不可挽回的损失。例如,系统宕机、停止服务、无法响应、信息泄露等。

在本次所说的Bug数量,主要是指:Bug数量=线下缺陷数量+线上问题缺陷数量,不涉及线上故障。因为线上故障是需要严肃对待的,关乎企业层面的SLA服务水平协议,也就是通常所说的99%、99.9%、99.99%、99.999%。

虽然本次暂时不讨论线上故障这个沉重的话题,但我们应该清晰,Bug的修复成本,越往后代价越高。

563572f15ada4ec1ac9611bd990f7ee4~tplv-tt-shrink:640:0.image

例如,前几天发生的Salesforce全球大宕机事件,

eba225badf784859a2c75d5e3cb029b2~tplv-tt-shrink:640:0.image

又如最近因微信无法支付而导致美团的故障。

47fef453fdab48188b9fa61afedd470f~tplv-tt-shrink:640:0.image

厉害的程序员都有哪些硬核技能

硬核技能1、效率高,产出高

高效的程序员,有时能一个人顶好几个人。他能快速理解业务需求,结合自己对技术的掌握,有效应用,并和项目成员充分沟通,按计划推进的同时,主动给予反馈。

产出高,意味需求开发速度快,在同一时间段内能完成和交付的任务、需求、项目和版本就会比旁边的人多,需要对接的测试人员也会更多,由此接到的线下缺陷Bug数量也会多。

这并不是指为了追求速度而罔顾质量,还要分析线下缺陷Bug数量的归因,到底是数据问题,还是环境问题,还是代码问题,还是误报或确实是很隐晦的问题。如果分析下来,最后主要归因分类都不是代码问题,那证明这位程序员确实很高效也很高质量。

小结:缺陷Bug数量越多,反映技术人员效率越高,但还要分析Bug归因作为佐证。

硬核技能2、在公司任职时间长,对核心业务有深厚的理解

技术人员有两大优势,一方面是技术优势,一方面是业务优势。

在公司任职时间越长,对企业的核心业务就会越为熟悉,并且会比新人、以及其他同伴更清楚特定行业领域业务鲜为人知的逻辑、规则和设计。这是稀缺性和权威性的代表。

自然而然,当新人有不懂时,针对线上问题,就会首先想到负责核心业务的核心人员。即便是老员工,在碰到线上问题时,也会把这个问题记录下来并转交给有经验的核心技术人员进行处理。

所以,程序员的线上问题Bug数量越多,有可能并不是他自身的技术问题,而是由于公司和团队需要他的丰富经验和深厚的知识来解决线上发生的问题。

我有一段真实的亲身经历。曾经在某租车平台任职时,几乎我们每天遇到的关于国际租车的用户案例都是不一样的,原因千变万化。Bug数量按负责人统计下来,很明显看到第一位程序员负责的Bug最多,几乎相当于后面全部人的Bug的数量之和。原因是这位程序员,他工作经验丰富,从系统的早期搭建开始就一直参与其中,不仅对技术、对业务、对各部门的人员,还对各种“疑难杂症”都有解决的妙招。所以,很多搞不定的问题或棘手的难题都丢给他。所以,他的Bug最多,也是最为重要的灵魂人物。

小结:线上问题Bug数量越多的程序员,对核心业务的理解越深厚,并且会掌握鲜为人知的专家知识。

硬核技能3、人源广,影响力强

还有一种情况是,程序员人缘好,平时工作中也非常乐意帮助别人解决一些非本职岗位的问题。当其他技术人员有解决不了的问题,或者有测试人员提了一个Bug却找不到负责人来解决时,又或者产品有一个很小的尿点需求时,都会来找他帮忙解决。

这时,线上或线下Bug就会转给这位受欢迎的程序员来解决。能者多劳。

小结:非本职岗位的Bug越多,程序员的影响力越强。

用YesDev统计和跟踪缺陷

YesDev是面向软件研发的项目协作套件,你可以使用它来进行问题、缺陷、Bug的管理、跟踪和统计。

创建问题并指派

在YesDev的顶部菜单,有添加 新问题的快捷入口。

9aca81e49a0e44c489591dd811a95874~tplv-tt-shrink:640:0.image

在问题描述中,你可以直接粘贴截图,非常方便。然后指派给对应的技术人员。

2e85f66ffa2b476498630ad86f41db1d~tplv-tt-shrink:640:0.image

负责人收到邮件通知并修复问题

负责问题的人员,会收到相应的邮件通知。类似:

857a3aab577047be886414f9c1a315cd~tplv-tt-shrink:640:0.image

修复后,可以关闭问题。随后,创建人核对验收关关闭问题。

查看我负责的问题和查看我创建的问题

bb450a90625a4558bc95a4d945c4c887~tplv-tt-shrink:640:0.image

缺陷统计

缺陷统计,常用的统计数据,可以分为:

  • 按产品统计
  • 按负责人统计
  • 按创建人统计
  • 按项目统计
  • 按需求统计
  • 按优先级统计
  • 按归因统计
  • 按解决时长统计
c16beefd702a4962b38028494bea0a92~tplv-tt-shrink:640:0.image

根据经验总结,在按负责人统计时,前面1~3位的人员是BUG数量最多的人,通常相当于后面长尾全部人员的BUG数量之和。下面是我们团队的真实统计数据,BUG数量越多的技术人员,他们的贡献力度就越高。

e7c408a15ed445f2b9cd3574a2af412c~tplv-tt-shrink:640:0.image

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK