项目经理叫你改 Bug,后来就发生了……

简介:

你曾经碰到过现在这种情况:

你的代码非常优雅。

你代码中的抽象刚刚好,不多不少。

你的模块都各自独立。

所有的测试结果都是绿色的。代码测试覆盖率报告花了整整一分钟才打开,上面显示着 97%……

生活很美好。

然后事情就这么发生了。

一个 PM(产品经理)跑进来,跟你说上周你发布的那个更新里面有个 bug。不论什么时候,只要用户在购物车里添加了一件商品,购物车中的计数过个好几秒才会更新。本来应该立即更新的。

PM 跟你说用户的抱怨如潮水般用来,他问你:你能看一眼么?

当然你能看一眼,毕竟这是你做的东西。很可能是其他什么人犯了错。不过你会修复这个问题的。你就是这么正直的员工。

你在 Git 上把最新的发布版本同步下来,然后开始研究变更日志。在上一个发布版本中,你把 HTTP request 库更新到了最新版。那次审核过了好长的时间。你还能记得这次修改确切的提交所在,那天的天气不错。

你切换到那次提交,然后模拟了一下更新购物车的请求。不错 ,你已经充分考虑到了代码的独立性,可以很容易地在测试环境和生产环境中进行测试,只需要切换一个构建标记就够了。

你找到了那个罪魁祸首。看起来你更新的那个 HTTP 库有个回归(regression)。对于特定类型的请求,它花了太长的时间来解析传入的 JSON 负载。你的应用只能在请求负载解析完成之后才能更新那个计数器。在架构上还没有处理最终一致性的问题,要加上这种设计的话,本身就足够当成一个项目来做了。所以你没法在本地先更新计数器随后再同步到服务器上。

你知道这是别人犯的错。唉,这就是生活。

你把事情的原因告诉了 PM。他拍了拍你的背,知道这不怪你。你能把这个问题修复么?

当然。

你已经考虑好你的解决办法。

你不能把变更都回滚。有一大堆新的代码和 bug 的修复都依赖于这个新版的库,要是你把所有东西都回滚的话,这些就都白干了。

只是把这个库 fork 下来然后维护一个你自己的版本看上去也不太可行。之前这个项目的维护者有一个超级完备的测试架构,会在上千台设备上测试你修复的代码。而你只有三台设备,其中两个的操作系统版本都老掉牙了。最好还是需要他们的反馈,毕竟这是他们维护的库,他们对其内部结构很了解,而你不了解。

所以你打算这么干:

Fork 这个库

实现代码修复

向原始的 repo 中发一个 pull request

你和维护者可能需要来回几次沟通

最终说服他们相信你的方法才是最好的

代码合并

等着这个库发布一个新的补丁

在你的代码中更新这个库

发布产品的新版本

很简单嘛。

“好极了,”PM 说,“你觉得需要花多长时间?”

你知道这个答案。人们都说程序员不会估算时间,你可不是那种程序员。(《为什么软件开发周期通常是预期的两三倍?》)

“两周,”你眼都不眨地说,“取决于这个 PR 多久才会被接受,还有维护的人多快能发布一个新版本。”

PM 的脸色立刻就变绿了。“两周?两周?!”他重复着同样的话,好像这样能改变一样。不过他还是保持了冷静。PM 知道怎么处理负面的情绪,没什么可担心的。

“我们的用户正在流失!他们什么都不会买了,因为他们没法看到自己购物车里面的更新!我们是个电商公司!这是不可接受的!”

你看着他经历着悲伤的五个阶段(译注:否认、愤怒、讨价还价、绝望、接受)。你等着最后接受的那个过程什么时候会发生。不过并没有。他看起来停在了讨价还价的阶段。

“好吧,”你说着,深陷在你的转椅里,“让我想想。”

你会迁就他一下下,然后他可能就会离开了。你还有很多其他事情要做,你知道的。

你开始翻看源代码。这是你的特长,你的手指敲击着 IDE 的快捷键,就好像海神波塞冬驾驭着大海的波涛。

啊哈!你找到它了!有个文档中没提到的方法,可以在 JSON 解析的代码中插入一个钩子,然后用你自己的实现来替换它!

不过等等。这看起来太丑陋了。这可是个非公开的 API,说不定把它暴露出来是个意外呢。你可不想依赖这种东西,万一他们在下一个版本里把它移除掉了怎么办?那样你就得把这套东西整个都重写一遍了。谁想这么干啊?不过这确实比自己维护一个没测试过的分支要快一些。不过还是太丑陋了。

不要。

你可不想因为商务决策而误导你,毁了你纯净的神殿。你是神圣的守护者,对抗着那些愚昧的事物。这就是为什么他们会付你那么多钱的原因。你的责任就是拒绝这种要求。

你冲进 PM 的屋子。“答案是不要。没有什么优雅的方法来解决它,我不相信丑陋的旁门左道。抱歉。”

他的反应和你预料中的一样。

“你告诉我有个方法可以做到,不过你不想这么做就因为它不够优雅?我们的用户正冲我们叫嚣着,威胁我们要改用我们竞争对手地产品,而你就不愿意修复这个问题,就因为它不够优雅?“

你失败了。

这人懂什么软件工程?你只用代码就凭空创建了这个奇妙的世界。高度可扩展的系统,可以抵抗住来自前苏联集团中所有黑客发向你的 DDoS 攻击。你是个艺术家,而芯片就是你的画布。你已经无数次地阅读了《代码整洁之道》,你对它的了解甚至超过了你对自己 GitHub 密码的印象。

“没错!”你喊道,“我不会用这种垃圾来玷污我们的代码库!我花了好几个月才构建出这些东西!产品里的每一行代码都是我的心血!它们能够正常运行的唯一原因不是你,和你没关系!是像我这样的人们维持着软件的运行,是像我这样的人们,不得不在你和你的那些‘商业功能’完成之后去清理那些乱七八糟的东西!”

你冲出了那儿。你需要喝点什么。这样的人简直就是业界的祸根。他们觉得自己那些花哨的 MBA 证书能让他们知道该如何创造出伟大的软件,而我们这些开发者却不知为什么忽略了这种方法。

你昂首阔步地走进休息区,那是你每天享用那些美食家们推荐的午餐的地方。还有咖啡,不限量的、美味的、滋润着你的灵魂的咖啡。你值得这种享受,因为你是个知识工作者。

你冲了一杯 java 咖啡,想找个地方坐下。

然后你看到了他。

你的公司中最资深的程序员。

这家伙是个彻头彻尾的核心人员,是那种“我在上厕所的工夫就能写出一个编译器”的程序员。在黑客出现之前他就已经是名黑客了。你想要成为这样的人。他就像是指环王里面的甘道夫。这里所有人在所有时候都尊敬和畏惧着他。不过他很和蔼,总是会帮助那些孩子们。他应该愿意听听你和 PM 之间发生的事情。毕竟,他是你这一伙的。

于是你坐到他旁边。他正享受着咖啡,正在看着什么 Haskell 中抽象的数据类型之类的东西。

没错,就得和这样的人聊聊。

你把自己的壮举告诉了他。他耐心地听着,偶尔点点头,问了些问题。他的肢体语言是向后靠着。从他的眼神中你能看得出来,他以前也经历过这种事儿。

你终于说完了。

好累。

你感觉肩上的分量轻了一些。

他看上去陷入了沉思,好像正在谨慎地选择着词汇。

你等着他会大笑着宣布“干的好,孩子!”,然后你们会一起再冲杯咖啡。他会给你讲一个他所经历过的类似的故事,在那一天,他如何斥责一个愚蠢的 PM。

你曾经梦想过这一天。你们会用咖啡碰杯,就像那些在战场上取胜的战士那样。至少,在电影里他们是那么干的。当然,他们通常用的是啤酒,而不是咖啡。

在感情上,你是这么希望的。

你等待着……

继续等待着……

他直直地看向你的双眼,穿透了你的灵魂。那些和电脑一起奋斗过的岁月让他的目光变得如此难以忍受,不过他使用了什么魔法,让你无法移开你的眼睛。

他只说了一件事。

“我们的工作并不是喝喝咖啡敲敲代码。我们的工作是编写能够正常运行的软件。”

然后他就走开了。

你呆住了一分钟。在你肚子里有种什么感觉,一种空荡荡的、恶心的感觉。你开始意识到这种感觉,叫做羞愧。

你让那些你最亏欠的人失望了,那就是你的用户。

于是你回到自己的座位上,迅速搞定了那个“旁门左道”,然后发布了一个新的版本。

你向 PM 道了歉,自己有点失控了。他说没事。最后只要没事就好。

你还是 fork 了这个库,实现了一个正确的修复方式,然后提交了一个 PR。当这个库以正确的解决方法发布新版本的时候,你总是可以重构自己的代码的。
文章转载自 开源中国社区 [http://www.oschina.net]

相关文章
|
7月前
|
测试技术
测试提交的bug开发不认可怎么办?
测试提交的bug开发不认可怎么办?
190 0
|
SQL JSON 前端开发
【改BUG】项目遇到的奇葩bug
【改BUG】项目遇到的奇葩bug
|
缓存 JavaScript 小程序
接手前同事代码,特别烂,各种BUG,看麻了。。。
接手前同事代码,特别烂,各种BUG,看麻了。。。
|
监控 安全 架构师
抱歉,你测试的项目上线之后bug太多了!
抱歉,你测试的项目上线之后bug太多了!
|
Java 应用服务中间件 Docker
同事嫌我改Bug慢,原来是没掌握这些代码Debug技巧
代码Debug调试是研发工程师日常工作中必不可少的重要组成部分。进行代码Debug调试的目的无非就两个,一个是自我检查代码逻辑是否有问题,便于自己将Bug消灭在测试介入之前;另一个是进行线上问题排查定位,找到实际在跑业务的过程中出现的Bug。
同事嫌我改Bug慢,原来是没掌握这些代码Debug技巧
|
测试技术
软件测试面试题:软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?
软件测试面试题:软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?
343 0
|
算法
写Bug时,需要注意的几点 02
写Bug时,需要注意的几点 02
115 0
|
运维 监控 IDE
同事牛逼啊,写了个隐藏 bug,我排查了 3 天才解决问题!
最近线上监控 SFTP 连接频繁爆表,通过重启某个系统,连接数迅速下降,系统就能恢复正常,初步判断是应用程序连接未关闭的问题导致的。
同事牛逼啊,写了个隐藏 bug,我排查了 3 天才解决问题!

相关实验场景

更多