[[382468]]

寫代碼的時候，反復修改是常見的事，修改之后忘記以前是什么樣子好像也很常見。

如何才能夠回溯那些被自己覆蓋掉的代碼片段？美國田納西大學的助理教授 Austin Z. Henley 介紹了自己開發的工具 Yestercode，它能讓回溯代碼就像播放視頻拉進度條一樣簡單。

這個工具在程序員們聚集的社區 HackerNews 上引發了人們的討論。

一項研究發現，Java 開發者在寫代碼的時候平均每 6 分鐘回溯一次，這意味著他們經常會需要使用 undo 按鈕或 Ctrl+z 讓代碼恢復到之前的狀態。這些撤銷動作顯然并不是預先可知的，而且隨后肯定會接著覆蓋重寫。

事實上，在另一項研究中，有開發者在 5 分鐘內進行了 40 次 undo/redo 操作。當被問及為什么要這樣做的時候，程序員的回答通常是：他們在試圖回想起被修改部分代碼的某個中間狀態。那么問題來了，為什么想看到之前寫過的代碼就這么難？

Undo 到盡頭

對于代碼工作來說，撤銷和重寫按鈕總是很有意義的設計。但這里會存在一些問題：（1）如果回溯之前的狀態，進行了新的更改，之前的狀態就會丟失。（2）人們無法看到改前改后狀態的直接對比。（3）沒有提示符直觀指示你在撤銷 / 重寫歷史的具體位置。（4）有些代碼編輯器使用全局 undo 堆棧，有些代碼編輯器為每個打開的文檔使用撤消堆棧，這可能會干擾你執行操作順序的思維方式。（5）代碼編輯器中還有很多動作是不會被加入 undo 堆棧中的（比如修改 debugger 選項），這在調試 bug 的時候會讓人頭疼。（6）一次回撤一小步，不知何時才能到盡頭。

這個吐槽的列表還能繼續列下去。

使用版本控制

有人說：「為什么很多程序員都習慣使用 undo/redo？版本控制可以解決所有問題。」

但實際情況是版本控制并不會奏效。當開發人員對代碼進行更改時，他們可能會對代碼進行很多改動并陷入困境，然后過了一會才能意識到想要的是某種中間版本。這就迫使開發人員在他們得到做出決定所需信息之前，保存一個中間版本。除非每隔幾分鐘將代碼放到 git 庫，無論其是否有效，因此版本控制在此并不會有所幫助。

開發人員通常對找到所需信息過于自信，而且他們大大低估了找到這些信息所需的工作量。

復制文件

開發人員在更改過程中，要么復制代碼文件，給相關代碼截圖。他們可能會有這樣的想法：「我要把代碼弄亂了，在弄亂之前，我要用 Ctrl-A 和 Ctrl-V 將它復制到一個新的標簽頁中，然后把該窗口放在編輯器旁邊，用作參考。」甚至有從業 20 年的開發者也是這樣做的。

回到最初的問題：為什么想回頭看 5 分鐘前的代碼就這么難？為什么代碼編輯器不能更好地執行這種行為？

使用 Yestercode 來挽救

Austin Henley 表示他早在 2015 年就開始草擬了一些設計方案，旨在為開發人員提供所需的信息，且所需的工作量較少。在他的設計中，開發人員可以一同查看代碼的新版本和原版本，同時自動記錄重要更改。由于 Henley 可以訪問 LabVIEW 編輯器的源代碼，因此他為 LabVIEW 的實驗版創建了一個帶有已啟用功能的分支。

盡管 LabVIEW 是一種可視化的拖放（drag-and-drop）語言，但這種設計思想也適用于傳統編輯器。然后 Henley 將其演示給了數十位開發人員、經理和其他 LabVIEW 用戶，以獲取反饋并進行迭代。

之后，Austin Henley 開發了一個名叫 Yestercode 的工具。它可以讓你在時間軸上瀏覽代碼歷史紀錄就像看 YouTube 視頻一樣。進行回溯編輯時，它可以匯總新的修改，并在時間軸上為這個版本建立分支。在這以后，你可以使用時間軸轉到先前的版本，并與當前版本的代碼并排查看。以前的版本是只讀的，但仍允許人們從中復制粘貼。最后，這個工具還顯示注釋，以便于人們知曉在更高版本上（比如 diff）進行過哪些更改。

幾年前，Henley 花費了一些時間把 Yestercode 做成了 Atom 插件，事實證明它對其他種類的代碼也很有用。

這還沒有完，Henley 希望能讓這樣的比較工具接手所有的文字版本，包括 word 文檔、電子表格和 PDF，新的工具目前也已有了原形。

這樣真的可以行得通嗎？等到它正式上線之后，我們就可以評判一下了。