PM 叫你去改一个 Bug,后来……

Anup Cowkur 59 人浏览 收藏 0
PM 叫你去改一个 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。当这个库以正确的解决方法发布新版本的时候,你总是可以重构自己的代码的。


注:本文转载自Anup Cowkur,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如有侵权行为,请联系我们,我们会及时删除。

热门文章

最新文章



返回顶部