提交问题

Kode Vicious - @kode_vicious

2010年2月10日
第8卷，第2期

什么时候是提交更改的正确时机？

尊敬的 KV，

我的项目中的另一个人坚持以大批量提交不相关的更改。当我说 不相关 时，我的意思是，他会修复几个不相关的错误，然后对整个源代码树中的间距和缩进进行一些细微的更改。然后，他会一次性提交所有这些更改，通常只用一条简短的提交消息列出他声称已修复的错误。我是否太挑剔了，以至于希望每次提交只解决一个问题或错误？

欲盖弥彰

尊敬的欲盖弥彰，

在我撰写这些文章的这么多年里，我不认为我曾说过任何人太挑剔——考虑到我经常抱怨和指出别人的缺点，这有点令人惊讶。

当然，如果我处在你的位置，我不会只是抱怨；我会撤销那个人的提交，并让他分小块提交工作。幸运的是，现代源代码控制系统是双向的：它们使分组提交变得容易，也使撤销提交变得容易。

我不仅希望提交只包含相关的更改，而且我还认为提交有不同的类型，程序员应该确保他们的提交不是“泄漏”的。“泄漏”的提交通常是由于“再多做一件事情”综合症引起的。你开始修复一个错误，但随后发现该错误是由不仅结构不良而且格式也很差的代码造成的。一旦错误被修复，你自然会想清理你在修复过程中发现的其他垃圾，例如糟糕的缩进、空格使用不当、缺少注释等等。整理一段代码是值得称赞的事情，但在修复错误的同时彻底清理整个文件则不是。和往常一样，这是一个平衡问题。

处理你在处理其他事情时发现的位腐烂或丑陋代码的正确方法是停下来，提交修复，然后再去彻底清理文件！确保在修复错误后尽快进行清理，因为我们都知道，一旦你点击回车键提交了你的小错误修复，很可能会出现更紧急的事情。突然，你的老板会发来一封电子邮件，要求你修复另一个错误，然后你就没有时间清理你之前发现的垃圾，这将导致在其中发现更多错误，以及更大的内部压力来真正“把它做好，该死的！” 最终你会开始用头撞击办公室的窗户并大喊大叫。好吧，也许你不会，但当我知道必须清理但没有时间清理的文件列表变得太长时，这就是我发生的事情。

避免在彻底清理文件时被打断的一种方法是分组提交，这正是你应该教你的同事做的事情。修复一些错误、清理一些文件、在此处添加注释、删除彼处的无关空格并做好所有这些工作是可以的。关键是确保每个更改都可以独立提交。实现这一点的最佳方法是在你自己的分支中工作，在这个分支中，你可以提交而无需其他人立即看到你的工作。将每个更改独立提交到你自己的分支中——首先是错误修复，然后是广泛的彻底清理，最后是空格和注释清理——然后将所有更改合并到实际工作树中。

这种方法并非没有风险——特别是，你会被困在合并地狱中（参见尽早合并，经常合并，KV，2009 年 10 月）一段时间——但如果你正在进行错误修复和空格更改，你应该至少每周能够合并你的工作，这应该会减少你必须进行的合并量。如果可以，每天合并更改，这将有助于控制你必须进行的合并量。

关于空格和格式更改。尽管确保项目中的所有代码都格式良好并符合编码标准是值得称赞的，但仅仅为了重新格式化代码而重新格式化代码是一种非常、非常反社会的行为。你更改的每一行都会显示在版本之间的差异中，并且尝试比较跨大量空格差异的文件的两个版本是非常令人恼火的。有时你只需要忍受文件中的间距或格式，以便保留必要的历史记录——以及每个人的理智。可惜，这是另一个需要平衡的建议。我无法告诉你多少空格更改才算太多，但我可以告诉你，如果你更改了文件的格式并且它更改了每一行，你最好愿意为自己辩护，以对抗一群愤怒的同事，他们可能会认为你的更改具有太大的破坏性，但几乎没有实际的好处。

尊敬的 KV，

你是否曾经将测试嵌入到你的代码中，而不是编写独立的测试代码，作为测试基本功能的一种简单方法？这是我在学校学习测试代码的方式，但我很少在实践中看到它这样做。

随波逐流

尊敬的随波逐流，

添加内部测试不是我在学校学到的东西，而是我在实践中看到并偶尔使用的东西。我最喜欢的这类测试的两个例子是计算器代码和 vi 编辑器。

很久以前，包括 KV 在内的许多人都使用功能强大的计算器，你可以对其进行编程。这些程序以纸质形式分发，通常在杂志上，并且必须直接在计算器上键入。这是一个容易出错的过程。如果你非常幸运或富有，你或许可以使用条形码阅读器从页面上读取程序。键入程序很费力，但修复程序——通过一次编辑程序一行——则更不好玩。通常，每个子程序都有一个注释，例如“将这些参数输入计算器并执行此子程序；如果答案不是 X，那么你做错了什么；回去修复代码。” 这样，当你在键入代码时，你可以逐步检查你键入的内容是否正确，从而提高整个程序的成功率，并且可能还有助于降低你的血压并过上更长寿更幸福的生活。

关于古代历史就说这么多；让我们向前迈进一点。你们中的许多人使用 vi 编辑器，或者更可能是它的较新表亲 nvi 和 vim。我希望你从未读过代码的内部结构，因为它非常可怕。许多年前，Keith Bostic 将 vi 编辑器改造成 nvi，并在使一个非常令人困惑的程序变得不那么令人困惑和更易于维护方面做得非常出色。我做了一点扩展编辑器的工作，并开始遇到这样的代码片段

代码中散布着许多这些嵌入式测试，旨在帮助任何阅读代码的人相对快速地知道，当他们进行更改时是否犯了错误。

当很容易看到输出变化时，这些类型的测试效果相对较好。例如，它们在网络堆栈中效果不佳，因为你可能需要查看数据包的内容。在处理代码编辑器时，你可以将测试嵌入到源代码中，因为你很可能正在使用同一个编辑器来处理代码，并且可以尝试建议的测试并立即获得答案。

一种适合此类嵌入式测试的代码类型是解释型语言的代码。一些程序编辑器有一种执行正在编辑的代码区域的方法，作为测试该子程序的一种方式。 Lisp 编程语言的编辑器长期以来都具有此功能，并且在 Emacs 编辑器中已将其扩展到涵盖其他脚本语言（如 Python 和 Perl）。如果你正在使用允许原位执行代码的编辑器处理解释型代码，那么你绝对应该将这些类型的测试添加到你的代码中。

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

最初发表于 Queue vol. 8, no. 2—
在数字图书馆中评论本文

更多相关文章

Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
尽管加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。出于各种安全要求，存在许多针对加密哈希的标准，但在非加密方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对现实世界数据集的均匀分布很有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。

Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。直观地看，技术领导者普遍认为，良好的开发者体验可以实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改进 DevEx 的拟议举措和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。

João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果，以研究生产力差异，从而提供关于该主题的新见解。低代码技术已清晰地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了有力的论据。本文报告了程序和协议、结果、局限性以及未来研究的机会。

Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中新的工具、技术和技巧不断被开发出来以服务于商业和社会，但它也很健忘。在其快速前进的过程中，它容易受到时尚潮流的影响，并且可能会忘记或忽略针对其面临的一些永恒问题的成熟解决方案。用例于 1986 年首次引入，后来普及，是这些成熟的解决方案之一。