开发者社区> scottx> 正文

我修复的印象最深的一个bug

简介: 我们写程序的,应该把自己当成一个工匠,去雕刻我们自己编写的程序。对于任何一行代码都应该当成是一个可以把玩,推敲的工艺品。
+关注继续查看

倒上茶水一杯,看着这个主体《我修复的印象最深的一个bug》,顿时陷入长久思绪当中。自从业十多年以来,写过的代码无数。当然,属于自己挖坑自己填的bug也修复过,捣鼓祖传代码的bug也修复过,在修复bug的同时给后人挖坑的事也没有少干过。具体有多少,可能无法用数字来衡量,不知道有多少的bug被close或者从close到reopen再到close.


如果非要说修复的印象最深的一个bug, 那可能是大约10年前的一次事故Bug. 当时我们负责给某工厂的生产系统上线BOM生产系统。产品生产前,各个零件的组合方式以及属性选择全部通过我们提供的业务系统进行统一编排。编排审批完成后,将会有打印机将各种生产表单分发到各个生产岗位进行生产。当时的我和另外一位同事所在的小组,负责了某一个模块的开发,当时也不像现在的前后端分离,基本就是谁负责一个模块,谁从头到底进行开发,会从从Model,Controller,View 一条龙服务到底。


当时模块当中有一个表单里面有一个关键指标的下拉框,用户可以通过选择“是/否”来设定其属性。当开发完成后,提交测试也完成测试,再到上线,交付使用。一切看起来就想日常片段一样的索然无谓和自然,无非就是一个简单表单的CURD,真的是too sample。


然而,在交付后的第二周,收到工厂侧传来一条内部的通报通知。厂家的某位员工因为在创建生产计划表单时,因为关键指标选择错误,而导致一批产品报废,造成了严重的生产事故。而在整个系统的审核人员也受到相应的通报批评。因为平时和业务部门的人还比较熟,这2位收到通报的伙伴还在和我吐槽,创建表单的人说的百分之百选择的选项是 “否”;审核表单的人也打保票的说审核时,选项看到的绝对是“否”,但是为什么最后在生产指令打印到生产岗位时,显示的选项为“是”,他们也觉得无法相信,最终只能认为是同时走神造成的。听到此处的我当时还觉得居然有如此不可思议的事情发生,在替他们惋惜过后,直觉告诉我,肯定是程序哪里有问题。


随即,打开VS Stidou2010(当时使用的一个IDE),开始分析涉及到该关联字段的页面(.aspx)和逻辑文件(.aspx.cs),并且通过在测试环境结合数据库进行排查。最终,发现了问题的所在,原来在创建/修改页面的选项“是/否” 所对应的值是 0/1, 审核页面的选项“是/否” 所对应的值是 0/1。 然而在最终的生产指令打印文件的逻辑当中,对于选项“是/否”的对应值为 1/0。所以,这也能解释为什么创建人和审核人看到的都是“否”, 然而生产岗位看到的数据为 “是”了。随机马上发起一个 hot fix 将代码修改合并,等待下一次迭代窗口期。


果真,在迭代后的不久,第二次生产计划又在同样的表单下进行创建。之前的2位伙伴此时同样按照之前的选项进行选择,并相互确认,并找其他人一起验证了他们在系统上的选项。最终,这次的生产指令没有出错。看到这个结果,之前的2位伙伴更加坚定了上一次的失误是他们自己选错了。(我们的版本发布后,普通用户只会知道我们更新了哪些功能,并不知道具体的内容。就如现在知名APP的更新日志只会写上“更新了某些功能,优化了某些XXX”一样)。


至此,该bug成功被解决掉了。我们开发组也受到了相应的处罚。但是这个bug的故事却一直让我记忆很深刻。印象最深的bug,修复并不是修复了多么大的一个系统,并不是个人的能力多么牛逼解决了一堆人不能解决的问题。我想,对于我而言,这个bug让我印象深刻,原因有三。


其一,作为开发人员搞出来的,对用户造成了一定的损失,而且还让用户打心里的认为是其自身失误造成,这一点就心里过不去。 


其二,就是由于这个Bug的原因真的很简单,没有多么高深的技术。然而他就是错了,还造成了损失。


其三,是自事故之后对自身的思考,为什么会出现这种问题?说100%写代码不出问题,那是不可能的,但是如何保证尽量少出这种错误?


第三个原因是这么多年一直在不断提醒我的,如果在当时所有的事情做到了下面几个步骤。约莫也不会有那次事故了吧。

  1. 对于Key/Value 的约定,在团队一定需要有一个约定俗成的规矩,并在团队每个人心里。最好意思就是字面意思,比如isDelete => yes/ no , 每个人看到这个,能想到的对应值就应该是1/0 。 可见定义的重要性,特别是深入人心的职业性定义。

  1. 如果还在从事前端页面的开发, 对于功能的验证一定不能仅仅局限于页面上显示的。因为页面上显示的不一定是最终存储的数据。强烈建议如果还在做前端的同学,一定要去数据库里面二次验证自己的数据。

  1. 测试的流程完整性,还是提倡一条龙服务,不能门前雪各自扫,如果某个功能是你做的,那测试应该最好覆盖到整个流程。切记不能整体流程出错时,甩出一句“我这里是好的”,“他给我的就是这样的数据”。开发好的功能,一定要向前,向后进行测试。

  1. 不怕流氓怕武术,就怕开发会业务。当完成一个功能的时候,是否能够站在业务的角度和场景去验证功能是否正常,也是非常重要的。

这便是我修复的印象最深的一个bug,可能他并不是一个负载很高的系统,可能他不是用了很牛逼的技术。但是这个bug却带给我了扪心一问。

“我们写程序的,应该把自己当成一个工匠,去雕刻我们自己编写的程序。对于任何一行代码都应该当成是一个可以把玩,推敲的工艺品。”

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
如何优雅的完成订单异步处理
本篇文章主要内容 为何我们需要对下订单采用异步处理 简单的订单异步处理实现 非异步与异步下单接口的性能对比 一个用户抢购体验更好的实现方式
4 0
【设计模式自习室】详解代理模式
《设计模式自习室》系列,顾名思义,本系列文章带你温习常见的设计模式。主要内容有: 该模式的介绍,包括: 引子、意图(大白话解释) 类图、时序图(理论规范) 该模式的代码示例:熟悉该模式的代码长什么样子 该模式的优缺点:模式不是万金油,不可以滥用模式 该模式的应用案例:了解它在哪些重要的源码中被使用
4 0
划重点!你还在困惑MySQL中的"锁"吗?
最近在学习查找MySQL中"锁"的相关资料时,发现网上各种言论观点杂乱不堪且版本混乱,很容易让人深陷其中、很是蒙圈。笔者认真研读了MySQL8.0官方指导手册,并广泛搜集各家观点,整理了一份参考性较强的关于MySQL中"锁"机制的知识点合集,以供参考学习。
3 0
源码分析ElasticJob选主实现原理
源码分析ElasticJob选主实现原理
3 0
享元模式 Flyweight Pattern:减少对象数量
主要内容有: 该模式的介绍,包括: 引子、意图(大白话解释) 类图、时序图(理论规范) 该模式的代码示例:熟悉该模式的代码长什么样子 该模式的优缺点:模式不是万金油,不可以滥用模式 该模式的应用案例:了解它在哪些重要的源码中被使用
4 0
如何使用注解优雅的记录操作日志
本文讨论如何优雅的记录操作日志,并且实现了一个SpringBoot Starter(取名log-record-starter),方便的使用注解记录操作日志,并将日志数据推送到指定数据管道(消息队列等)
3 0
源码分析ElasticJob分片机制
源码分析ElasticJob分片机制
4 0
MySQL选错索引导致的线上慢查询事故
本文的主要内容: 故障描述 问题原因排查 MySQL索引选择原理 解决方案 思考与总结
4 0
源码分析ElasticJob故障失效转移
源码分析ElasticJob故障失效转移
4 0
+关注
scottx
专注移动互联网广告
23
文章
1
问答
文章排行榜
最热
最新
相关电子书
更多
JS零基础入门教程(上册)
立即下载
性能优化方法论
立即下载
手把手学习日志服务SLS,云启实验室实战指南
立即下载