coding

coding

寫程式碼從來不是瓶頸：LLM時代的軟體開發挑戰

多年來，我始終認為在軟體工程中，撰寫程式碼的行數從來都不是真正的瓶頸所在。 真正的瓶頸過去是，現在依然是程式碼審查、透過指導和配對進行的知識傳遞、測試、偵錯，以及協調與溝通的人為成本。所有這些都被包裹在工作票、規劃會議和敏捷儀式的迷宮中。 這些原本旨在提升品質的流程，往往比撰寫程式碼本身更能拖慢我們的速度，因為它們需要思考、共享理解和健全的判斷力。 如今，隨著大型語言模型（LLMs）使生成可運行程式碼變得比以往更快，一種新的說法出現了：撰寫程式碼曾經是瓶頸，而我們終於突破了它。 但這種說法並不完全正確。 新增軟體的邊際成本正趨近於零，尤其是有了LLMs的幫助。但理解、測試和信任該程式碼的代價是什麼？比以往更高。 LLMs轉移了工作負載——而非消除它 像Claude這樣的工具可以加快初始實現速度。但結果往往是更多的程式碼流入系統，以及對負責審查、整合和維護它的人員施加更大壓力。 這在以下情況尤為明顯： * 不清楚作者是否完全理解他們提交的內容。 * 生成的程式碼引入了不熟悉的模式或違反了既定慣例。 * 邊緣案例和非預期的副作用並不明顯。 我們最終陷入這樣一種情

coding

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

在軟體開發的世界裡，有一個現象一直存在卻鮮少被深入討論：開發者將大部分時間花在「理解系統」上。這個現象值得我們深入探討，因為它直接影響著開發效率和成本。 軟體開發的時間分配：40年來的驚人不變 早在1979年，Zelkowitz、Shaw和Gannon在《軟體工程與設計原則》一書中就指出，開發者67%的時間都花在了維護上。這已經暗示了理解現有代碼是開發工作的主要部分。 快轉到2018年，Xia、Bao等人在《測量程式理解：與專業人員進行的大規模現場研究》中透過詳細的數據分析發現，程式理解佔據了開發者約58%的時間。更值得注意的是，「導航」（在代碼間跳轉查找信息）單獨就佔了24%的時間，這部分甚至不包括在「理解」的範疇內！ 這意味著，經過40多年的技術進步，開發者仍然將大部分時間花在理解系統上。唯一的變化可能只是我們更精確地測量了這些「理解時間」。 為何這個問題如此重要？ 如果理解系統是軟體開發中最大的時間消耗，那麼它理應成為我們首要優化的目標。然而，我們的討論往往集中在如何編寫代碼，如何構建系統，卻很少談論如何高效地「理解系統」。未被討論的問題就不會被明確定義，未被明確