转:Fix Bug的五个阶段

本文深入探讨了程序员在解决困难bug时的心路历程,将其比作哀伤与灾难过程中的Kübler-Ross模型,包括抵触、接受、投入与沮丧、愚蠢的快感和与‘完成’肉搏等阶段。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一个非常严重和困难的bug,能够成就一个饱经沧桑深受压力的有经验的专业程序员的职业生涯。经受这种考验的创伤程度,相当你受到了一次严重的身体伤害,离婚,或是家庭成为的离世。

研究人员在研究了计算机编程心理学后,得出了一个程序员们在解决一个困难的bug时的心路里程。这些不同的境界,很像为大众所知的Kübler-Ross Stages of Grief(这个模型描述了人对待哀伤与灾难过程中的5个独立阶段(否认,愤怒,耍赖,抑郁,接受)。绝症患者被认为会经历这些阶段),而且原因都很相似。就好像死亡所伴随的悲伤一样,fix一个bug是一个过程其初始化了一个事件,一开始是拒绝相信,其造就了你苦闷的情绪并开始逐步影响你的心智。这种苦闷的情结果会让你纠结要努力忍受,最终会你会找到一个满意的结果。

了解下面这几个bug-fixing的阶段,会让我们更好的生存下来,并持之以恒,最终带来……关闭我们所有的bug的结果。

第一阶段:抵触

本阶段的状态: 多疑 Skeptical. 生气 Offended. 易怒 Petulant.

1. 不理睬

也许这个bug会安静地离开。

2. 标记上“不是bug”

也许这是用户的错,或是本地配置有问题。是的,我确信就是那样,一会就会好的。

3. 就是一次小故障

我想这就是一次小故障,很奇怪地发生了一次,它不会再发生的,虽然没有搞清楚是为什么发生了,不过这就好像我们的数据库,网格,浏览器或别的什么打了几个嗝一样。一会就会好的,我确信。

4. 躲藏.

我要休几天病假,也许他们会把这个bug转给别人的。

5. 标记为“修改需求中”

你看,我是按照需求实现的。如果你们想要改这个行为和UI,就一定要修改需求。也许他们会决定就这样了。

6. 需要更多的信息

我不能确定这是一个bug,除非我能在错误日志中看到一条特定的报错信息。

7. 转给其他人

我调查这个bug中看到了其它模块中我看不懂的数据,问题很大。我应该把这个bug转给开发那个模块的人。我可以在我的模块中检查一下那个边边角角的情况,但是正确的fix应该是在别人的模块中。反正那个在别的国家,我见不着他。

第二阶段:接受

本阶段的状态: 认命 Resigned. 被打击 Defeated. 被激怒 Annoyed.

1. 接受现实

行了,行了,行了!这是我的bug,我会修正它的。

2. 把这个bug放到最后

也许,我可以在我需要fix这个bug之前找到一个新的工作。

3. 和你的经理讨价还价

好的,你看,我可以正确地fix这个问题,不过我需要一个月。也就是说,我可以给这个问题贴个创可贴,那不会真正的解决它,但是我们可以避免用户的抱怨,这可以为我们赢得几天的时间。

4. 为这个bug标记一个无耻的时间

上帝啊,我希望这时间够了。

第三阶段: 投入和沮丧

本阶段的状态: 眼花 Giddy. 头晕 Light-headed. 紧张 Nauseous.

1. 开始调查

我能搞定它,我能搞定它!只需要小小的调整一下,小小的关注一下,多一点咖啡因,再加上一点时间,我能搞定它。

2. 迷惘

Shit. 这太扯了。我居然没有一点进展。这代码真是乱。这样的代码居然能编译和运行,真TMD的神奇,我有机会能搞清楚它什么不正常吗?

3. 再次躲藏

你看,很对不起。我不得不要去切除我的阑尾。再一次,是的,既然你提到了它,我的确有两个阑尾。现在我一个也没有了,你高兴了吧?。

4. 犯贱

好吧,总之,你到底期望什么?想让我在一个没有高级调试器的环境下改这个BUG。我是什么?千里眼吗?我在我的Commodore 64上一个更好的调试器!

5. 瞎搞

看看我试试这么改?Kao,这样不行。要不然这样搞?也不行。那么那样搞呢?Shit,居然变得更糟了。

6. 绝望

我不可能fix这个bug了。我是个糟糕的程序员。我太笨了。我在这个满是聪明人的地方干什么?迟早他们会知道我的能力太差,那时我就玩完了,在这也混不下去了。

7.耻辱

我的经理问我为什么我用了一个月的时候来fix这个只需要两天就可以解决的bug?老实说,我不知道怎么去读日志信息,我搞坏了我们的编译脚本。现在,我不敢去让别人来帮我,因为这样只会让我显得更愚蠢。

8. 恐慌!

这事变得比我相像的要复杂!而我开始觉得复杂的事变得简单……而我觉得简单的事变成需要重定半打的类。为什么我以前在我的经理前拍着胸说我可以搞定这个事?

9. 通宵工作,远离朋友和家人

(语无论次的喃喃自语,一阵一阵地大声咒骂)

第四个阶段:愚蠢的快感

本阶段的状态: 感恩 Grateful. 安心 Relieved. 极端地自我欣赏 Awfully Impressed with Yourself.

1. 醒悟

哦!我终于明白怎么搞定它了……

2. 写正确的代码

我真NB,我是编码机器!

3. 测试

牛!通过一个测试。真牛!又通过一个测试了。靠!有测试失败了。这是为什么……

4. 隐藏测试失败

反正这完全是一个不重要的测试案例。没有人会检查它,这个测试真是毫无意义。

5. 提交代码

我太牛了,厨房里有个馅饼可以庆祝一下吗?

6. 关闭 bug.

我听说那里有个馅饼可以庆祝一下

第五个阶段: 与“完成”肉搏

本阶段的状态: 焦燥不安 Twitchy. 神经过敏 Nervous. 迷信 Superstitious.

1. 有人reopen了这个 Bug

真的?他们发现了你引入了另一个bug? Shit – 那只是一个不重要的案例永远不会发生的。

2. 修正以前的修正

是的,我甚至检查了员工的年龄是一个虚数的情况,就是为了防止出错。

3. 关闭 bug

是的,贱货,你被关闭了。全部都关了,再也不用心烦了。

4. 发誓以后再也不干这种事了

5. 大家都意识到你现在是那个模块的专家了

哦,不!现在他们又给了我三个那个模块的新bug

没关系,现在你只需要GOTO 第一个阶段。

此外,作为一个工作中的程序员,你会永远经历这些烂事,直到你——死亡,退休,或是被升到管理层。

转载于:https://www.cnblogs.com/shengweil/archive/2011/03/29/1998422.html

<think>好的,用户想在GitHub上进行bug修复,但不太清楚具体步骤和最佳实践。我需要结合提供的引用内容,整理出一个清晰的步骤指南。首先,用户需要明确在GitHub上提bug和修复bug是两个不同的流程。根据引用[1],提bug是通过Issues页面创建新问题,但用户更关注如何修复问题。 接下来,修复bug通常涉及代码修改。引用[3]提到Repairnator机器人使用补丁修复bug的例子,比如修改if语句的条件。这说明修复bug需要具体修改代码,然后提交。引用[2]中的git命令可能对用户有用,比如拉取远程代码而不覆盖本地修改,这有助于在本地开发时保持代码同步。 另外,引用[4]提到GitHub的AI工具可以自动修复漏洞,但用户可能想知道手动修复的流程。最佳实践应该包括创建分支、编写测试、提交说明等步骤。同时,引用[5]提到了使用git clone下载项目,这是协作开发的基础步骤。 用户可能需要了解从发现问题到提交修复的完整流程,包括如何创建Issue、克隆仓库、创建分支、修改代码、提交并推送,最后发起Pull Request。此外,代码审查和自动化工具的使用也是重要环节,需要整合进去。 需要确保回答结构清晰,分步骤说明,并引用相关参考资料。可能的问题包括如何拉取代码不覆盖本地修改,如何写提交信息,以及自动修复工具的使用等。需要将这些点自然地融入回答中,并在末尾添加相关问题供用户进一步学习。</think>### GitHub上Bug修复的最佳实践指南 #### 一、问题识别与追踪 1. **创建Issue** 在项目仓库的"Issues"标签页点击"New issue",详细描述bug现象、复现步骤和环境信息。建议附上日志截图或代码片段(如$log.error("NullPointerException")$)[^1] 2. **环境隔离** 使用git命令拉取最新代码同时保留本地修改: ```bash git stash # 暂存本地修改 git pull # 拉取远程代码 git stash pop # 恢复本地修改 ``` 该操作可避免覆盖本地调试中的代码[^2] #### 二、代码修复阶段 1. **创建修复分支** ```bash git checkout -b bugfix/login-npe # 创建描述性分支名 ``` 2. **代码修改示例** 如修复空指针异常: ```diff - if (user == null) + if (user != null && user.getProfile() != null) System.out.println(user.getProfile().getName()); ``` 这种补丁式修改是常见的bug修复模式[^3] 3. **测试验证** 建议添加单元测试: ```java @Test public void testNullUserHandling() { assertDoesNotThrow(() -> loginService.handle(null)); } ``` #### 三、提交与协作 1. **原子化提交** ```bash git commit -m "fix(auth): handle null user in login flow - 添加空值检查 - 增加错误日志记录 - 更新单元测试" ``` 2. **代码扫描集成** GitHub代码扫描工具可自动检测: $$ \text{漏洞检测率} = \frac{\text{自动修复漏洞数}}{\text{总漏洞数}} \times 100\% $$ 当前自动修复率已达66%[^4] 3. **发起Pull Request** 在PR描述中关联对应Issue(如`Closes #123`),触发CI/CD流程 #### 四、代码审查与合并 1. 通过GitHub的Review功能进行: - 行内评论(针对具体代码段) - 状态标记(Approve/Request changes) - 使用`git push -f`更新修复分支(需谨慎) 2. 合并后建议: ```bash git checkout main git pull --rebase # 使用rebase保持提交线性 git branch -d bugfix/login-npe ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值