为什么我们很难看到代码 5 分钟前的样子？

作者 | Austin Z. Henley

译者 | 弯月

出品 | CSDN（ID：CSDNnews）

一项研究发现，Java 开发人员每 6 分钟就会重复一次撤销/重做，也就是说他们会将代码还原到以前的状态（例如单击撤消或按 Ctrl-Z）。他们会突然间狂按撤销，紧接着再狂按重做。事实上，另一项研究的一名参与者在 5 分钟内使用了 40 次撤消/重做！当被问到为什么要这么做时，他们表示他们希望在修改过程中看一看代码的某个中间状态。为什么在修改的过程中很难看到代码 5 分钟前的状态？

01

撤销有次数限制

 撤消和重做只能重复处理一小段代码。即便如此，这中间仍然有一些问题：

1. 如果进入之前的某个状态，然后进行修改，则无法再点击重做，而且之前的更改将全部丢失；
2. 你无法并排比较前一个版本与最新版本；
3. 没有任何视觉指示告诉你，你在撤消/重做历史记录中的哪个位置；
4. 有些代码编辑器使用全局撤消堆栈，而有些则会为每个打开的文档建立一个撤消堆栈，这可能会干扰你在脑海中想象的动作顺序；
5. 我发现代码编辑器中有很多动作不会添加到撤消堆栈中（例如，更改调试选项），这会在调试 bug 的时候带来不少问题；
6. 一次只能后退一小步，非常麻烦。

以及其他问题等等。

02

为什么不使用版本控制

有人可能会问，为什么要依赖撤销/重做呢？版本控制可以很好地解决这些问题！下面，我来解释一下为什么版本控制解决不了这些问题的一些原因。当开发人员修改代码时，他们可能并不会意识到他们需要几分钟前的某个中间版本，直到他们做了大量修改并卡壳。我们的研究中反复出现了这种情况。这就引出了一个问题：不成熟的提交，这会迫使开发人员在没有做决定所需的所有信息之前决定是否要保存一个中间版本，不管这个决定是否有必要。除非每隔几分钟就向 git 提交一次代码，而且可以不管这些代码是否可以正常运行，否则版本控制都没有太大帮助。开发人员对于寻找所需的信息，往往会过于自信，并且还会大大低估获取这些信息所需的工作量。

03

复制文件

我们看到有些开发人员想到了其他方法：在修改代码的过程中，他们会复制代码文件，或者截屏相关的代码。我本人以前也干过类似的事情，当我担心会弄乱代码时，我会按下 Ctrl-A 和 Ctrl-V，将所有代码复制到一个新标签中，然后将这个窗口放在编辑器旁边，作为参考。我甚至见过拥有 20 年经验的专业开发人员也会这么做！回到我们的问题，为什么在修改代码的过程中，看看 5 分钟前的代码如此困难？为什么代码编辑器不能更好地支持这种行为？

04

救星来了！

早在 2015 年，我就开始构思解决方案，我的设计可以为开发人员提供所需的信息，同时又无需大费周折。你不仅可以并排比较多个版本，而且还会自动记录“重要的”更改。由于我可以访问 LabVIEW 代码编辑器的源代码，因此我建立了一个 LabVIEW 的分支，并在实验版本中加入了这个功能。虽然 LabVIEW 是一种可视化的拖放语言，但基本思路也同样适用于传统的代码编辑器。后来，我向十几位开发人员、经理和其他 LabVIEW 用户做了演示，获取了反馈，并进行了迭代。下面，我来介绍一下这款工具：Yestercode。你可以利用时间轴浏览代码历史记录，就像 YouTube 视频一样。在你编辑代码的时候，它会汇总所有的代码，并在该版本的时间轴上显示一个点。接下来，你可以利用时间轴查看之前的版本，而且还可以并排比较当前版本。之前的版本是只读的，但允许你从中复制代码。它还会显示注释，以方便你了解之后的版本中进行了哪些修改（类似于 diff）。几年前，我又构建了一个 Atom 插件，并针对传统的文本代码实现了相同的功能。最后，我希望通过一个工具来比较所有类型的文件，甚至是 Word 文档，电子表格和 PDF 等。我做了一些原型：希望有一天 Yestercode 能成为正式的产品！原文链接：http://web.eecs.utk.edu/~azh/blog/yestercode.html

识别关注我们

了解更多精彩内容

点分享

点点赞

点在看