程式碼視覺化的自動化之路

你知道，當你忙於一個複雜演算法時，不得不返工一百萬次，因為你沒有正確地掌握細節？或者在你讀某人的程式碼時，你不能確定它在做什麼？此時，我們希望擁有程式碼視覺化（code visualization）工具，因為這會讓程式設計生活如此簡化。

本文，我將討論一些現有的用於程式碼視覺化的工具及其缺點，然後儘量總結它們背後的想法。為了創造得體的程式碼視覺化工具、以及如何達到這個程度，接著我會分享必備條件，我將給出應該採取的最初幾步。

 工具

有很多不同的、顯示程式碼視覺化有用的情況。理解複雜的演算法、理解其他人的函式，或在一個總體的不同範圍下，理解一個新的程式碼庫、或類、或函式集合。對於某些情況，視覺化已經存在了。對於專案或程式碼級別的範圍，有UML，各種圖表。在演算法的範圍，有些網站企圖視覺化一部分最通用的演算法。這些工具是偉大的，但是它們有一個大問題，使用它們要花費很長時間。在嚴峻的時間下，我們只有兩週來開發下一個 Facebook，你沒有時間畫複雜的 UML圖。第二個問題，即使通用演算法可能有視覺化了，而自定義演算法可能從來不會有。

也有一些工具和程式語言採用了不同的方式，你程式設計一部分，很快就能看到互動、或至少你正在做的視覺化的結果。我在討論 dat.GUI，你知道的，你在很多 demo 裡看到過黑色和彩色控制皮膚嗎？你能夠看到我的優雅的文字生成器示例（不要在較慢的裝置上開啟）。另一個例子是 Gooey，把 Python 命令列程式自動生成 GUI，無需從技術上理解的、使用者友好性。我過去在討論的一種程式語言是 JavaScript，從 JavaScript 剛剛出現的時候，它就與一種名叫 HTML 的介面結合在一起了。

允許你視覺化程式碼（非自動地）的第一套工具，允許你把現有程式碼/配置轉化成介面（自動地）的第二套工具。問題在於，我們是否能夠自動產生介面，包括輸入和輸出。視覺化只是輸出。那麼，我們為什麼沒有儘量視覺化程式碼以使其易於理解的工具？聽說過一個物件圖表嗎？它們是視覺化了當前程式或程式子集的狀態的圖表。具有三種“水果”型別的物件的列表看起來是這樣的：

如果能夠使用這樣的視覺化來除錯，是不是很好呀？

我對介面的定義是，它有輸入、輸出或二者都有，幾乎任何東西都能用一到兩種方式定義為介面，石頭、鍵盤、樂器、人類……

實際上所有這些工具在做的，都是把一個想法、用程式碼或圖表表達的想法，轉化成一個或多個不同種類的介面。程式語言把想法（以文字形式）轉化成不同的介面，可以是 HMTL、可以是傳統的 GUI、命令列應用程式或 app。UML 把想法轉化成優雅的視覺化概括。dat.GUI 用 HTML把配置程式碼轉化成清晰的配置 GUI。Gooey 把命令列程式轉化成傳統的 GUI。

它們都使用一個介面，然後轉化成一個或多個不同的介面。我樂於給出更多的例子，只是本文篇幅會過長。如果你對有趣的介面轉化的更多例子感興趣，看看 Slava Akhmechet 關於 lisp 的文章，它討論了把任何程式語言轉化為另一種語言的通用介面。或者 Philip C Monk 的博文，他討論了樹、影象程式設計（他有 demo）等等。

想法

好吧，下一步，我們明白了程式碼視覺化的一些工具和方法。程式碼視覺化是把程式碼或其子集視覺化的過程。這可以在高等級（程式碼庫或專案），中等級（函式檔案、類、龐大的類）或低等級（函式級別，演算法）。每個等級需要不同的分析程式碼的方法和不同的細節等級。

在最低的等級，我們需要的是至少視覺化最基本的資料型別的方法，最常見的是布林值、字串、數字、list和物件（或字典、hashmap、任何你呼叫的東東）。還有，一種獲取視覺化所需資料的方法。但是如果我們這樣做了，我們仍然面臨現有工具同樣的問題。然而，通用演算法可能已經有視覺化了，自定義演算法可能從來不存在。資料型別同樣如此，而 list 的視覺化或許容易，當一個 list 包含數千個item，或你無法使用內建list，比如雙端佇列（棧），連結串列時，很快就變得複雜了。在有物件時，甚至更難，因為它們很快變得比程式的其它任何地方都要複雜。

然而不是不可能，弄清楚程式設計師在用哪種資料型別會是極端困難的（特別是沒有自定義型別的 JavaScript之類的語言）。這就是為什麼我們需要在兩個地方互動的工具。第一個是在程式執行（程式配置）之前，比如定義你在使用的資料型別，第二種就是在程式執行的時候，縮放、padding、隱藏列表 items 中的 10000 個等等。

限於篇幅，方便交流起見，我忽略了中等級和高等級的細節。

偏題

本文原本是關於程式碼視覺化的，現在變成了隨筆，是關於：每樣事物都是一些事物的介面、電子訊號是大腦和手之間的介面、鍵盤是手和電腦之間的介面、文字編輯器是鍵盤和程式語言之間的介面、程式語言是想法和其它更多想法之間的抽象介面！我喜愛探索介面的想法，更普遍地推廣，因此我們可以用不同的方式使用它們。

為什麼我認為它是有用的，因為它不僅僅是有用的思想，而是一種不同的方法，產生了不同的解決方案、思路等等，而且它可以被用在優化以及概念或現有想法的產生上。

我希望本文能有一點點意義，激發人們隨後用不同的方式思考這個世界，我也打算寫更多的關於介面、不同種類的介面、介面之間的互動方面的文章。

• 注1：雙端佇列（deque，全名 double-ended queue）是一種具有佇列和棧性質的資料結構。雙端佇列中的元素可以從兩端彈出，插入和刪除操作限定在佇列的兩邊進行。http://zh.wikipedia.org/wiki/%E5%8F%8C%E7%AB%AF%E9%98%9F%E5%88%97
  
• 英文原文：The road to automatic code visualization