Cherry-picking 与科学方法

软件应该被视为计算机科学的一部分，而科学需要证据。

乔治·内维尔-尼尔

亲爱的 KV，

我花了过去三周时间尝试从一个分支拣选提交更改到另一个分支。我什么时候应该放弃并合并？

深陷泥潭

亲爱的深陷泥潭者，

我曾经和一位朋友从蒙特雷的计算机会议上一起开车回家。碰巧这位朋友非常喜欢新鲜的樱桃，当他看到一个小摊位在卖一篮篮樱桃时，他停下来买了一些。这位朋友的另一个特点是，他从不错过划算的买卖。因此，在与樱桃卖家讨价还价时，很明显，买一整箱樱桃比只买一篮更划算，即使那才是我们真正想要的。然而，由于不想错过划算的买卖，我的朋友买下了一整箱，我们就这样出发了——边吃边聊。又过了 45 分钟才到家，在那段时间里，我们吃掉了超过半箱的樱桃。有好几个月，我连看都不想看任何与樱桃口味有关的东西；而今天，当有人说“cherry-picking（拣选提交）”时，那不会让我联想到加州海岸边，那些家境优渥的孩子在周六早上扮演农夫的快乐景象——我只感到恶心。

所有这些都让我想到了你的来信。总是很难说别人应该在什么时候“放弃并去做 X”，无论 X 是什么，但在某个时候，你会知道——发自内心深处，在你作为工程师的那个地方——最初只是想快速拣选提交一些内容，结果却变成了一场可怕的泥泞跋涉，除了约翰迪尔拖拉机，没有什么能把你拉出来。阳光下的快乐时光已经结束，开始下雨，你感到寒冷，只想回家。那就是停止并重新尝试的时候了。

我知道这可能是不言而喻的，但我们大多数人最终陷入拣选提交泥潭的真正原因是，我们没有定期合并我们正在工作的代码。我们让树的头部，或者 git 的尖端，或者人们可能想用的任何愚蠢的短语，离我们越来越远，我们等待合并的时间越长，我们将遭受的痛苦就越多。避免陷入樱桃园的最佳方法是，在你的项目需要与开发树的头部重新同步时，准备好一个已合并和测试的分支。我知道这比将自己隔离在一个角落里，只专注于下一个版本的工作要付出更多努力，但最终它会为你节省很多麻烦。下次的问题将不再是“我什么时候停止拣选提交？”，而是简单地“新分支何时准备好接收我们已经完成的工作？”

亲爱的 KV，

我刚开始为一个新项目负责人工作，她有一个非常烦人的习惯。每当我修复一个 bug 并将修复提交到我们的代码仓库时，她都会问：“你怎么知道这已经修复了？”，或者类似的问题，质疑我对系统做的每一项更改。就好像她不信任我能做好我的工作一样。我总是在修复 bug 时更新我们的测试，这应该足够了，你不觉得吗？她想要什么，正式的正确性证明？

我凭直觉就知道

亲爱的我凭直觉就知道者，

从事软件工作不仅仅是凭直觉知道代码是正确的。实际上，从事软件工作的任何部分都不应该基于直觉，因为毕竟，软件应该被视为计算机科学的一部分，而科学需要证据。

我对当前这批缺陷跟踪系统有一个问题——相信我，这只是我对它们的问题之一——它们在跟踪你为修复 bug 所做的工作方面做得不好。大多数缺陷跟踪器都有许多 bug 可以经历的状态：新建、打开、已分析、已修复、已解决、已关闭等等，但这只是修复 bug 或对任何规模的程序做任何其他事情的故事的一部分。

程序是你或团队通过编写代码来实现的某种系统的表达。因为它是一个系统，你必须有一种方法来推理该系统。现在很多人会跳起来大喊“类型系统！”“证明！”，以及其他大多数在职程序员都不知道并且不太可能接触到的东西。然而，有一种更简单的方法来解决这个问题，它不依赖于花哨或深奥的编程语言：使用科学方法。

当你处理问题时，你应该以一种反映科学方法的方式来做。你可能对问题是什么有一个想法。把这个写下来作为你的理论。理论解释了关于系统的某些可观察的事实。基于你的理论，你开发一个或多个关于问题的假设。假设是解决问题的可测试的想法。假设的好处在于它是真或假的，这与我们布尔程序员的头脑非常契合：要么/或者，非黑即白，真或假，没有“灰色地带”。

这里的关键是将所有这些都写下来。当我年轻的时候，我从不写东西，因为我认为我可以把它们都记在脑子里。但那是胡说八道；我无法把它们都记在脑子里，而且我不知道我忘记了哪些，直到我当时的老板问了我一个我无法回答的问题。没有什么比在回答关于你正在做的事情的问题时，知道自己脸上露出了茫然的表情更糟糕的了。

最终，我开发了一个做笔记的系统，这让事情变得容易一些。当我有一个关于问题的理论时，我创建一个标题为 THEORY 的笔记，并写下我的想法。在下面，我写下我所有的测试（我称之为 TEST，因为像任何优秀的程序员一样，我不想一直输入 HYPOTHESIS）。我目前使用的笔记系统是 Emacs 中的 Org 模式，它可以让你创建可以绑定到快捷键的序列，从而让你快速更改标签。对于 bug，我有一些标签，称为 BUG、ANALYZED、PATCHED、| 和 FIXED，而对于假设，我则有 PROVEN 或 DISPROVEN。

我总是保留已证明和未被证明的假设。我为什么要同时保留两者？因为这样我就知道我尝试了什么，以及什么有效，什么失败了。当你有一个有强迫症的老板，或者，正如他们喜欢被称为“注重细节”的那样，这被证明是非常宝贵的。通过保留你的成功和失败，你总是可以回顾，比如在三个月后，当代码以一种与你关闭的 bug 非常相似的方式崩溃时，并查看你上次测试了什么。也许其中一个假设会被证明是有用的，或者也许它们只会提醒你你尝试过的愚蠢的事情，这样你就不会浪费时间再次尝试它们。无论如何，你应该将它们存储起来，备份起来，以某种版本控制的方式。我的都放在我的个人源代码仓库中。你有自己的仓库，对吧？对吧？！

喜欢它，讨厌它？请告诉我们

[email protected]

KODE VICIOUS，凡人称之为乔治·V·内维尔-尼尔，为了乐趣和利润而从事网络和操作系统代码的工作。他还教授各种与编程相关的课程。他的兴趣领域是代码探险、操作系统和重写你的烂代码（好吧，也许不是最后一个）。他获得了马萨诸塞州波士顿的东北大学计算机科学学士学位，并且是、Usenix 协会和 IEEE 的成员。他是一位狂热的自行车爱好者和旅行者，目前居住在纽约市。

最初发表于 Queue 第 11 卷，第 4 期—
在数字图书馆中评论这篇文章

更多相关文章

凯瑟琳·海耶斯, 大卫·马龙 - 质疑评估非加密哈希函数的标准
尽管加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。存在许多由各种安全要求驱动的加密哈希标准，但在非加密方面，存在一定程度的民间传统，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布是有道理的，但当面对具有特定模式的数据集时，这可能是一个挑战。

妮可·福斯格伦, 埃里尼·卡利亚姆瓦库, 阿比·诺达, 米凯拉·格雷勒, 布莱恩·霍克, 玛格丽特-安妮·斯托里 - DevEx 实践
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，开发者体验 (DevEx) 在许多软件组织中越来越受到关注。技术领导者凭直觉地接受，良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改善 DevEx 的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。

若昂·瓦拉霍, 安东尼奥·特里戈, 米格尔·阿尔梅达 - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极端低代码技术进行的实验室实验结果，以研究生产力差异，从而为该主题提供新的见解。低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。

伊瓦尔·雅各布森, 阿利斯泰尔·科伯恩 - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来服务于商业和社会，但它也很健忘。在快速前进的过程中，它容易受到时尚的影响，并且可能会忘记或忽略一些已证明可以解决其面临的一些永恒问题的解决方案。用例于 1986 年首次引入，并在后来普及，就是这些已被证明的解决方案之一。