什麼是現代化程式設計？

【導讀】：現代化程式設計應該是：不強制用相同的 IDE，統一的程式碼風格，方便的依賴管理，持續整合，版本控制等。

---

在我的青少年時期，我涉獵了程式設計基礎和一些彙編。當我學習了 Turbo Pascal 之後這事更進了一步，它提供了一種最早期的整合開發環境（IDE）。我覺得這下合我心意了。實際上，IDE 是一種讓你在一個友好的環境內，方便地編寫、編譯、除錯和執行程式碼的程式。Turbo Pascal 沒有太多的圖形介面（它基於文字），但它有選單和視窗。你可以進入除錯模式，跟蹤變數的值等等。

然後我轉到了 Delphi （一種圖形化的 Turbo Pascal），它擁有到今天看來仍然不錯的出色 IDE。我用  Visual Basic 設計了一個“會報時的鐘”，當時發表在 Bulletin Board Systems（使用 Windows 3.1 的一個系統）。那之後我發現了 Visual Studio。有好幾年我的 C++ 程式設計都是借用的 Visual Studio。以上就是我一直使用的所有 IDE。

早在八十年代初，Smalltalk 就有了著名的強大圖形化 IDE（Youtube 視訊）。

我認為，使用 IDE 並不代表著“現代化”。現在的 IDE 和過去的 IDE 非常相像。雖然我們程式設計的內容改變了，但在很多情況下，我們如何程式設計卻沒有改變。在我的 Dell 膝上型電腦裡裝著最新版 Visual Studio。換做 20 年前的我，也能完美地輕鬆上手它。除錯、程式碼補全、遠端程式碼執行，它和以前很像。事實上，Visual Studio 從未與 Turbo Pascal 相差很大過。而我發現這非常令人沮喪。我以為我們應該取得比這更快的進步。

我提出了現代化程式設計在桌面外觀上難有作為的觀點。圖形化使用者介面（GUI）只是表層。現代化程式設計技術都是關於流程和實際工具的，而不是它們之上的表層。我不在乎你是否使用 Eclipse 或 Emacs，這和你如何現代化毫不相關。

那麼，什麼是“現代化”？

編碼是社會化的

在 20 年前，要求你公司裡的每個人都使用相同的 IDE，並且要唯一依賴於這種 IDE 來構建、測試和部署程式碼，這是很明智的。但在你公司外有很多聰明的人，他們往往不使用你這種 IDE。如今，你可以觸及他們了。這意味著對於所採用的工具和流程你必須明智。

如果你嘲弄使用 Atom 文字編輯器、Visual Studio 或者 Emacs 程式設計的人，那你就不是社會化的。你需要儘可能的包容，否則就會付出代價。

Go 語言有自己的格式化工具

我不在乎在你儲存的時候，是不是自動重新格式化程式碼，或者有沒有點選重新格式化按鈕，或者是不是輸入 go fmt，這些都一樣。但它無疑是一個卓越的現代化的想法。這就是進步。所有的程式語言都應該為使用者強加一個唯一的程式碼格式。別再 bikeshedding（過於關心旁枝末節，而忽視主要問題）。

我們很清楚 Java 擁有規範，但規範是不夠的。我們需要一個工具，能把程式碼作為輸入，並生成一個唯一定義了的輸出，它能處理從行長度到空格的所有問題。

這個工具的目標是對於應該如何格式化程式碼，不再有任何可能有的爭議，而且產生正確的格式不費吹灰之力。我簡直無法告訴你這是多麼的重要。

像 Rust、Go、Swift 這樣的程式語言有自己的程式包管理系統

因此，例如在 Swift 中，我可以建立一個名為 Package.swift 的小文字檔案，並把它放入我專案的根檔案，在那裡宣告我的依賴。

（原始碼例項）

然後我可以輸入 swift build，軟體會自動抓取依賴程式碼，並構建我的程式。這在 Swift 執行的所有地方通用。你使用哪種文字編輯器和 IDE 都沒關係。

你不想使用文字編輯器，而更喜歡圖形介面？可以。都沒有區別。

為什麼那樣顯得現代化？因為自動地解決依賴關係而不費吹灰之力，對於 20 年前的我來說就像魔術。並且自動地、系統地解決依賴關係是極其重要的。我不想永遠都不得不手動安裝和部署一個依賴項。我希望其他人能夠在幾秒內把我的庫新增到他們專案中，而不是幾分鐘或是幾小時。

是的,你可以將它新增到現有的語言(如：Java 的 Maven 或是 IED)但需要有一個唯一的方法讓它起效。

像 Rust、Go、Swift 這樣的程式語言，在一開始就支援單元測試。

比如在 Go 裡，建立一個 filemyproject_test.go，然後新增 func TestMyStuff（t * testing.T）這樣的函式，然後輸入 go test 既可。

在 20 年前，幾乎沒有人測試他們的程式碼，而今天已經是一個必要要求，您和它需要以一種唯一的方式來做，這樣你就可以在專案之間移動，還總是知道如何測試了。

如果不能在你的程式碼中立刻認出健全的單元測試，我會設想你的程式碼嚴重損壞了。

持續整合

程式碼更改時，你想要一個遠端工具來獲取新程式碼，並測試它，以便可以提前停止迴歸。人們可以在你的程式碼上執行測試還不夠，他們還需要看到自動化測試的結果，自行檢查最終的故障。

持續整合是較大規模計劃的一部分：你必須在你程式設計的時候瘋狂地自動化程式。體力勞動應該最小化。有時候這意味著你真的應該只是點選一個按鈕，無論是通過一個圖形化使用者介面，還是命令視窗，但它不意味著需要反覆地遵循一系列複雜的命令。

版本控制

20 年前，你在桌面上編寫程式碼，並通過電子郵件傳送新程式碼（作為補丁）是講得通的。但這隻在緩慢的合作節奏中有意義。如今，這麼做是愚蠢的。任何差於 Git 的都是落後的。注意，如今甚至微軟構建 Windows 也使用 Git。

 

那麼，當你共事於從來沒有聽過現代程式設計的聰明學生會發生什麼呢？他們看一個類似 go get 的命令，只看得到表層（一個命令列）。他們認為這是落後的。漂亮的圖形在哪？

他們使用一個好看的 IDE 工作，像是 Visual Studio 或 Eclipse，並確信自己是現代化的，完全無視 IDE 可以追溯到幾十年前的事實。然後並沒有使用 IDE 的優勢，比如更好的功能可見性和更快的操作，而是在其他地方使用現代化程式設計技術。他們堅持守舊派程式設計：

• 沒有測試。至少，沒有自動化和系統化的測試。
• 在一個具體的設定上難以處理依賴關係。
• 沒有自動化。沒有持續整合，沒有自動化部署。

他們程式設計就像我幾十年前使用 Turbo Pascal 入門的時候。儘管 Turbo Pascal 有圖形化使用者介面（GUI），但它是非常古老的學校。