You have encountered this situation:
-
Your code is very elegant.
-
The abstraction in your code is just right, no more no less.
-
Your modules are all independent.
-
All test results are green. The code test coverage report took a full minute to open and it said 97%...
life is brilliant.
Then it happened.
A PM (product manager) came in and told you that there was a bug in the update you released last week. Whenever the user adds an item to the cart, the count in the cart is not updated for several seconds. It should have been updated immediately.
PM tells you that user complaints are flooding in, and he asks you: Can you take a look?
Of course you can take a look, after all this is what you do. Most likely someone else is at fault. But you will fix that. You are such an honest employee.
You sync the latest release on Git and start digging through the changelog. In the last release, you updated the HTTP request library to the latest version. That review took a long time. You can still remember where the exact commit of this revision was, and it was a nice day.
You switch to that commit and simulate a request to update the cart. Yes, you have fully considered the independence of the code, you can easily test in the test environment and production environment, just switch a build tag is enough.
You found that culprit. It looks like there is a regression in the HTTP library you updated. For a certain type of request, it took too long to parse the incoming JSON payload. Your application can only update that counter after the request payload has been resolved. The issue of eventual consistency has not been dealt with in the architecture, and if this design is added, it is enough to be done as a project in itself. So you can't update the counter locally and then sync it to the server.
You know it's someone else's fault. Alas, this is life.
You told the PM the reason for the incident. He patted you on the back, knowing it wasn't your fault. Can you fix this problem?
Of course.
You have considered your solution.
You cannot roll back all changes. There's a whole bunch of new code and bug fixes that depend on this new version of the library, and it's all for nothing if you roll everything back.
只 是把这个库 fork 下来然后维护一个你自己的版本看上去也不太可行。之前这个项目的维护者有一个超级完备的测试架构，会在上千台设备上测试你修复的代码。而你只有三台设备， 其中两个的操作系统版本都老掉牙了。最好还是需要他们的反馈，毕竟这是他们维护的库，他们对其内部结构很了解，而你不了解。
所以你打算这么干：
-
Fork 这个库
-
实现代码修复
-
向原始的 repo 中发一个 pull request
-
你和维护者可能需要来回几次沟通
-
最终说服他们相信你的方法才是最好的
-
代码合并
-
等着这个库发布一个新的补丁
-
在你的代码中更新这个库
-
发布产品的新版本
很简单嘛。
“好极了，”PM 说，“你觉得需要花多长时间？”
你知道这个答案。人们都说程序员不会估算时间，你可不是那种程序员。
“两周，”你眼都不眨地说，“取决于这个 PR 多久才会被接受，还有维护的人多快能发布一个新版本。”
PM 的脸色立刻就变绿了。“两周？两周？！”他重复着同样的话，好像这样能改变一样。不过他还是保持了冷静。PM 知道怎么处理负面的情绪，没什么可担心的。
“我们的用户正在流失！他们什么都不会买了，因为他们没法看到自己购物车里面的更新！我们是个电商公司！这是不可接受的！”
你看着他经历着悲伤的五个阶段（译注：否认、愤怒、讨价还价、绝望、接受）。你等着最后接受的那个过程什么时候会发生。不过并没有。他看起来停在了讨价还价的阶段。
“好吧，”你说着，深陷在你的转椅里，“让我想想。”
你会迁就他一下下，然后他可能就会离开了。你还有很多其他事情要做，你知道的。
你开始翻看源代码。这是你的特长，你的手指敲击着 IDE 的快捷键，就好像海神波塞冬驾驭着大海的波涛。
啊哈！你找到它了！有个文档中没提到的方法，可以在 JSON 解析的代码中插入一个钩子，然后用你自己的实现来替换它！
不 过等等。这看起来太丑陋了。这可是个非公开的 API，说不定把它暴露出来是个意外呢。你可不想依赖这种东西，万一他们在下一个版本里把它移除掉了怎么办？那样你就得把这套东西整个都重写一遍了。谁想 这么干啊？不过这确实比自己维护一个没测试过的分支要快一些。不过还是太丑陋了。
不要。
你可不想因为商务决策而误导你，毁了你纯净的神殿。你是神圣的守护者，对抗着那些愚昧的事物。这就是为什么他们会付你那么多钱的原因。你的责任就是拒绝这种要求。
你冲进 PM 的屋子。“答案是不要。没有什么优雅的方法来解决它，我不相信丑陋的旁门左道。抱歉。”
他的反应和你预料中的一样。
“你告诉我有个方法可以做到，不过你不想这么做就因为它不够优雅？我们的用户正冲我们叫嚣着，威胁我们要改用我们竞争对手地产品，而你就不愿意修复这个问题，就因为它不够优雅？“
你失败了。
这 人懂什么软件工程？你只用代码就凭空创建了这个奇妙的世界。高度可扩展的系统，可以抵抗住来自前苏联集团中所有黑客发向你的 DDoS 攻击。你是个艺术家，而芯片就是你的画布。你已经无数次地阅读了《代码整洁之道》，你对它的了解甚至超过了你对自己 GitHub 密码的印象。
“没 错！”你喊道，“我不会用这种垃圾来玷污我们的代码库！我花了好几个月才构建出这些东西！产品里的每一行代码都是我的心血！它们能够正常运行的唯一原因不 是你，和你没关系！是像我这样的人们维持着软件的运行，是像我这样的人们，不得不在你和你的那些‘商业功能’完成之后去清理那些乱七八糟的东西！”
你冲出了那儿。你需要喝点什么。这样的人简直就是业界的祸根。他们觉得自己那些花哨的 MBA 证书能让他们知道该如何创造出伟大的软件，而我们这些开发者却不知为什么忽略了这种方法。
你昂首阔步地走进休息区，那是你每天享用那些美食家们推荐的午餐的地方。还有咖啡，不限量的、美味的、滋润着你的灵魂的咖啡。你值得这种享受，因为你是个知识工作者。
你冲了一杯 java 咖啡，想找个地方坐下。
然后你看到了他。
你的公司中最资深的程序员。
这 家伙是个彻头彻尾的核心人员，是那种“我在上厕所的工夫就能写出一个编译器”的程序员。在黑客出现之前他就已经是名黑客了。你想要成为这样的人。他就像是 指环王里面的甘道夫。这里所有人在所有时候都尊敬和畏惧着他。不过他很和蔼，总是会帮助那些孩子们。他应该愿意听听你和 PM 之间发生的事情。毕竟，他是你这一伙的。
于是你坐到他旁边。他正享受着咖啡，正在看着什么 Haskell 中抽象的数据类型之类的东西。
没错，就得和这样的人聊聊。
你把自己的壮举告诉了他。他耐心地听着，偶尔点点头，问了些问题。他的肢体语言是向后靠着。从他的眼神中你能看得出来，他以前也经历过这种事儿。
你终于说完了。
好累。
你感觉肩上的分量轻了一些。
他看上去陷入了沉思，好像正在谨慎地选择着词汇。
你等着他会大笑着宣布“干的好，孩子！”，然后你们会一起再冲杯咖啡。他会给你讲一个他所经历过的类似的故事，在那一天，他如何斥责一个愚蠢的 PM。
你曾经梦想过这一天。你们会用咖啡碰杯，就像那些在战场上取胜的战士那样。至少，在电影里他们是那么干的。当然，他们通常用的是啤酒，而不是咖啡。
在感情上，你是这么希望的。
你等待着……
继续等待着……
他直直地看向你的双眼，穿透了你的灵魂。那些和电脑一起奋斗过的岁月让他的目光变得如此难以忍受，不过他使用了什么魔法，让你无法移开你的眼睛。
他只说了一件事。
“我们的工作并不是喝喝咖啡敲敲代码。我们的工作是编写能够正常运行的软件。”
然后他就走开了。
你呆住了一分钟。在你肚子里有种什么感觉，一种空荡荡的、恶心的感觉。你开始意识到这种感觉，叫做羞愧。
你让那些你最亏欠的人失望了，那就是你的用户。
于是你回到自己的座位上，迅速搞定了那个“旁门左道”，然后发布了一个新的版本。
你向 PM 道了歉，自己有点失控了。他说没事。最后只要没事就好。
你还是 fork 了这个库，实现了一个正确的修复方式，然后提交了一个 PR。当这个库以正确的解决方法发布新版本的时候，你总是可以重构自己的代码的。