開發者時間大解密：為何大部分工作都在「理解系統」上？

在軟體開發的世界裡，有一個現象一直存在卻鮮少被深入討論：開發者將大部分時間花在「理解系統」上。這個現象值得我們深入探討，因為它直接影響著開發效率和成本。

軟體開發的時間分配：40年來的驚人不變

早在1979年，Zelkowitz、Shaw和Gannon在《軟體工程與設計原則》一書中就指出，開發者67%的時間都花在了維護上。這已經暗示了理解現有代碼是開發工作的主要部分。

快轉到2018年，Xia、Bao等人在《測量程式理解：與專業人員進行的大規模現場研究》中透過詳細的數據分析發現，程式理解佔據了開發者約58%的時間。更值得注意的是，「導航」（在代碼間跳轉查找信息）單獨就佔了24%的時間，這部分甚至不包括在「理解」的範疇內！

這意味著，經過40多年的技術進步，開發者仍然將大部分時間花在理解系統上。唯一的變化可能只是我們更精確地測量了這些「理解時間」。

為何這個問題如此重要？

如果理解系統是軟體開發中最大的時間消耗，那麼它理應成為我們首要優化的目標。然而，我們的討論往往集中在如何編寫代碼，如何構建系統，卻很少談論如何高效地「理解系統」。未被討論的問題就不會被明確定義，未被明確定義的問題也就無法被有效優化。

目前，「理解系統」主要通過閱讀代碼實現。事實上，前面提到的研究也將理解與閱讀視為基本同義詞。這引發了一個重要問題：閱讀真的是理解系統的最佳方式嗎？

重新定義問題：從閱讀到決策

為什麼開發者要閱讀代碼？根本目的是為了收集足夠的信息，以便知道下一步該做什麼。從這個角度看，閱讀代碼本質上是一種決策前的信息收集過程。

閱讀恰恰是從數據中收集信息的最手動、最低效的方式。這為我們提供了一個巨大的優化空間。

在我多年前創立的人性化評估理念中，我將「理解系統以知道下一步該做什麼」的過程稱為「評估」(assessment)。我認為，我們應該圍繞這一過程優化開發工作流。

從閱讀到工具化：可塑性開發的誕生

經過十年的探索，我和同事們發展出了「可塑性開發」(moldable development)的概念。這一理念認識到：閱讀是從數據中提取信息的最手動方式，它不僅無法擴展，還會導致信息不完整和不確定性。

軟體開發已經足夠困難，不了解當前系統的狀態不應該成為方程式中的一個變量。一個手繪的關於當前系統的圖只是一種信念，而工程決策絕不應該基於信念。

一旦我們接受系統本質上是數據的觀點，就應該像處理數據那樣處理它。數據科學告訴我們，應該先從問題出發，然後通過與上下文匹配的工具進行推理。

可塑性工具：適應上下文的解決方案

由於軟體高度依賴上下文，我們無法預測具體問題，只能預測問題類型。為了應對這一挑戰，可塑性開發的核心理念是：工具應該在了解問題後可以被塑造，以便處理上下文中重要的事情，並代替開發者完成枯燥的閱讀工作。當然，為了使這一方法實用，創建自定義工具的成本必須很低。

我認為，在開發過程中為每一個具體問題構建自定義工具將是軟體開發的下一個重大飛躍。

十年後，我們不應該再以閱讀來衡量「理解系統」的時間。我們應該將精力集中在解決實際問題上。要實現這一目標，我們應該從討論如何「不閱讀代碼」開始。我們負擔不起不這樣做的代價。

Glamorous Toolkit：可塑性開發的具體實踐

為了啟動「如何不閱讀代碼」的對話，我們創建了Glamorous Toolkit。這是一個可塑性開發環境，它使得以低成本創建關於軟體系統的自定義工具成為可能。

例如，假設你需要理解一個複雜的數據處理管道。傳統方法需要你閱讀數百行代碼並在腦中構建流程模型。而使用Glamorous Toolkit，你可以快速創建一個視覺化工具，直接展示數據如何在管道中流動，哪些轉換發生在哪裡，以及可能的瓶頸在哪裡。這不僅節省了理解時間，還提供了更準確的系統視圖。

為普通人解釋：為什麼這很重要？

即使你不是軟體開發者，這個話題也與你息息相關。想像一下，如果建築師花67%的時間試圖理解已有的建築結構，而不是設計新建築；或者醫生花58%的診斷時間查閱過去的病歷，而不是與患者互動和制定治療方案。這聽起來效率極低，對吧？

這正是軟體行業面臨的現實。結果是什麼？軟體開發成本高昂，交付緩慢，質量不穩定。作為軟體的使用者，你可能經歷過緩慢的更新、持續存在的錯誤或過高的軟體價格。這些問題很大程度上源於開發者在理解系統上花費過多時間。

可塑性開發提供了一種新思路：不是更快地閱讀代碼，而是通過創建針對特定問題的工具來避免大量閱讀。這就像從用放大鏡手動檢查地圖，進化到使用GPS導航系統。結果將是更快、更便宜、更可靠的軟體開發。