程式設計王道，唯“慢”不破

Jeffrey Ventrella 最近在一篇文章裡探討了這種程式設計速度的差異，他是絕對的龜速派代表，來看看他對程式設計速度的看法：

我爸常跟我說的一句話是，慢一點碼，才能快點把程式寫完。

我在舊金山很多家網際網路公司工作過，現在已經 52 歲了，對於程式猿這個職業來說，我的年齡算偏大的。我寫程式碼的速度近乎龜速，事實上，我更像是一個會寫程式碼的設計師。

以前有一次，我和一些比較年輕的程式猿一起工作，他們信奉的程式設計宗旨是“速度快、更迭少”。我們在同一個 codebase 裡合作，就像在共同煮一大鍋湯一樣。如果我們每個人都持續不間斷的貢獻程式碼的話，未來這個工程應該就會很美很壯觀的呈現出來。

但是並沒有。

問題在於，這些年輕的程式猿們在心裡其實有這麼一種思想，他們覺得：1、每個人都是可替代的；2、沒人應該對某一部分的具體程式碼負責；3、所有人應該都可以任意修改整個工程的程式碼。

他們覺得，現在已經有了 github 這種神器用來管理非同步時間內的程式碼貢獻，只要每個人都持之以恆的貢獻程式碼，工程和產品就會順理成章的出爐了。

事實不是這樣的。程式設計從來就不應該是拿工具來減少軟體開發的時間的。

程式設計應該是一項有節奏感有韻律的運動。我傾向於把工程依照不同的規模和時間度量分成不同的塗層，每一個塗層再從探索、實驗、error、臨時變數這些細小的東西開始做起。有點像建設腳手架的形式。每一個塗層最終完成的時候是一段可以部署和擴充套件的 implementation-ready 程式碼。這種開發過程有點像是從策略到設計方案最後到完成一棟真正的建築。

有時候當這棟建築完成之後，我還會推倒重來一遍，因為我覺得我有更好的建築方法。這種新的方法有時候是對的，有時候是錯的，事實上除非真正去再做一遍，不然你永遠無法知道究竟哪一種方法更好。

回到最初那鍋湯的問題：在軟體開發生態圈裡，關於對整個設計流程產生推動與支援的混合思考是很重要的，沒有這一部分的工作，再快的程式猿又能做出多好的設計？很多神經系統科學家相信神經元資訊的流動在大腦的傳導過程中會有一個短暫的堵塞和混響，這對思維和感知會有很重要的作用。程式設計的設計也應該是這樣，需要時間。

慢速程式設計運動

慢速程式設計運動在維基百科裡的解釋是這樣的：慢速程式設計運動是慢速運動的一部分，這是一種強調謹慎設計、高質量程式碼、軟體測試和思考的軟體開發哲學，反對混雜組裝、佈滿 bug 的程式碼，以及過於快速的釋出週期。

世界上的軟體開發團隊都在尋找更具預測性的工程專案，希望能促成更多的程式設計師擁有可持續性的職業生涯。他們提議了一些可以切身操作的實踐方法，比如結對程式設計、程式碼審查和程式碼重構，以開發更可靠更健壯的軟體應用。

在舊金山海灣地區，風險投資支援的軟體開發正呈現出一種高燒般的熱度。利益正驅動著軟體開發以一種完全不自然的不對拍的節奏感在運動，它打亂了設計進化（design evolution）原本應有的週期節律和生物鐘。關於這一點，Rushkoff 在 Present Shock 裡說得很明白了。

另一個問題在於，人們對科技越來越詭異的迷戀，以及開發人員對工具異常的狂熱。大家總在說，為什麼有的軟體和應用做得這麼爛？沒錯，確實很爛。爛的原因在於，太多一味求快的程式猿在忙著建設工具，然後用這個工具去支援和適配另一個他們建好的工具，然後再用這個工具去支援和適配另另一個他們建好的工具，然後再用這個工具幫他們寫出更快的程式碼。

這就是我為什麼覺得軟體開發需要更多的“人”，而不是“工具”的原因。並且，這些人不僅僅只是幫忙做做外面的 UI 藝術之類的而已，應該要有更多的人深入軟體開發的內部——確保軟體更多的與人文產生共鳴和迴響。

當我們談論程式設計時，我們在談論什麼？

程式設計不是打字。

所有的程式猿都明白這一點，但是大部分人都容易忘記這一點。

在電腦前噼裡啪啦、彈指揮間的感覺確實很爽，這種鍵盤上啪啪啪的快感卻很容易讓人忘記程式設計是一項腦力活動，而不是體力勞動。程式設計的真正的奧祕在於，把人類的思維、設計、語言、邏輯和精神創造以一種計算機可以識別和儲存的方式記錄下來。

我妻子有時會跑到院子裡問我，你在程式設計嗎？我說，對，我在程式設計。事實上我可能正拿著鉗子修剪花盆裡的花草，或者做做施化肥之類的事情。

植物、土壤、鉗子，這些都是程式設計的好工具，正如鍵盤、滑鼠和雙螢幕一樣。

目前，我們正在經歷一個經濟產業的轉型期，從新興到可持續發展之間的一次過渡。新的軟體產品和商業模式是需要發展，但為了網際網路行業發展的可持續性，這種速度應該降下來一些了。擼程式碼不僅僅只是在擼當下使用者的需求，擼的更是未來某個行業領域的架構基礎。程式碼應該在程式設計師的關愛下慢慢的、茁壯的成長。Like good wine。Like a baby。