2024/05/21：重新編輯全文，增加了一些新的觀點與例子。

相關文章：別依賴「試誤法」寫程式

我常常覺得，軟體工程師可能是最能體現「當你手裡只有鎚子，看什麼都會像釘子」的一群人😂

我們在工作中，有時會陷入一種被稱為「路徑依賴」的困境。

本文將探討「路徑依賴」在軟體工程師的工作與職涯發展中，所造成的各種影響，以及「受困者」會有的具體表現。

或許會讓你感到有點熟悉。

前言：何謂路徑依賴？

「路徑依賴」是個社會科學的概念，用來描述一種現象，即一旦人們在某一方面選擇了特定的路徑或方式，他們就可能變得過度依賴這條路徑，並且可能難以改變。

這種依賴性可能源於各種因素，包括習慣、成本、學習曲線等，並可能在多個層面上產生影響，包括個人的行為、團隊的運作，甚至是整個社會的結構和制度。

在這裡，我們將專注於討論「軟體工程師常見的路徑依賴」。

以下的內容主要是基於我個人在工作上的觀察，可能帶有一點偏見，所以閱讀時請保持批判性思考。

何謂軟體工程師的路徑依賴？

文章標題與開頭把「路徑依賴」稱為一種「困境」，這樣的說法可能有失公允。

事實上，在大部分情況下，遵循既定的路徑可以顯著提高效率、增加確定性，同時也是我們發展專業的基礎。

所以嚴格來說，本文要討論的，是軟體工程師在工作與職涯中，那些「造成不良影響」的路徑依賴。

這類依賴帶來了一系列問題，例如低效率產出、溝通不順暢，甚至限制了我們的視野。因此，對於軟體工程師來說，了解這些路徑依賴的存在，確實有其必要。

接下來，我將從我自己以及我曾接觸和共事過的軟體工程師身上，舉出四個常見的路徑依賴觀察實例。

而且它們會是「層層遞進」的關係，從底層的工作細節，到上層的個人職涯選擇，我們無不受到「軟體工程師」這個角色的影響（或說「限制」）。

不過礙於篇幅，我們這期只先講前兩個。

一、程式註解的路徑依賴

首先，讓我們以「程式註解」為例，看看軟體工程師在為程式碼寫註解時，如何表現出「不良的路徑依賴」。

所謂的「程式註解」，指的是在程式碼中以特定格式或符號添加的文字或說明，用於解釋程式碼的功能、邏輯或用途。

程式註解是為了提供給開發人員或其他讀者（通常是一起開發的工程師）更容易理解和閱讀本段程式碼的附加資訊。它們不會影響程式的執行，但對於增進開發上的溝通與協作效率，有著重要地位，尤其是程式中特別複雜的部分。

註解通常使用自然語言（例如英文、中文）撰寫，而且要力求好讀、好理解。

太多細節與「程式晶晶體」註解

2024/05/21：適度使用英文詞彙，通常是為了專業術語或標準化，這類用法有其必要性。所以以下說的是「過度使用」，尤其是涉及太多底層、實作細節，造成程式碼閱讀者的認知負擔。

晶晶體是一種流行於臺灣以中文為基底，夾雜英語不成句的單字或片語的表達方式。

某些人在撰寫註解時，容易過度依賴程式碼的「實作細節」表達，比如用 excutemany 大量插入資料至 User Table、以 bulk_create 批次建立 obj——簡單說就是「講太細了！」

很多時候，這些細節描述應該使用「高抽象層次」且簡潔清晰的自然語言來替代。比如將用戶資料存入資料庫、一次性建立大量用戶資料——這才是給人看的註解。

給人看的註解

在中文夾雜大量的程式碼片語，堪稱「程式晶晶體」，語意不清、主詞不明，常常讓人無法一望即知。

其實也有完全用自然語言書寫的註解，但你讀起來並不覺得那是「通順」的句子，比較像 10 歲小學生寫的作文。

為什麼會這樣？因為開發者普遍「比較擅長」寫程式，而非文字表達。

所以乾脆用寫程式的思路來寫註解——毫無疑問，這樣真的比較輕鬆。只是讀者可能會覺得「這註解是在說什麼？」

這種在思考與陳述上，嚴重依賴程式碼邏輯的敘事方式，常常導致註解難以理解、重複程式碼的內容（即冗餘的註解），甚至可能產生混淆。

為什麼作者都需要好編輯？

你可能會認為：「只要提醒對方注意一下，問題就解決了吧？自己的文字是否易懂，應該很容易看得出來吧！」可惜，事實往往不是如此。

對於開發程式的「當事人」而言，即使註解中夾雜了大量不必要的程式細節，自己也常常會深陷其中，難以察覺，甚至覺得看起來很合理！——這就是為什麼作者都需要好的編輯，因為自身的盲點是很難完全發現並避免的。

少部分工程師甚至會覺得「我的程式能跑且執行結果正確」就算稱職了。至於註解有沒有寫、寫得好不好，不能算是評價我工作品質的範圍與指標。

這想法不能說毫無道理，只不過，寫程式若只顧自己，終究難登大雅之堂。這些程式碼看起來就像是一個人的自言自語（只要自己有完成任務就好）——它並沒有在溝通。

註解只是冰山一角

本段以「程式註解」為例，試圖說明工程師在「撰寫易讀程式碼」常見的路徑依賴（可以說是一種協作上的「阻礙」）。

然而，這種「缺乏溝通意識（或說意願）」的開發心態所帶來的影響，不僅存在於註解中，也往往貫穿整個程式寫作過程。

它實際的影響，超越了程式碼的範疇。接下來，我們將繼續探討這種心態在「工作表達方式」上的依賴特徵。

二、工作溝通上的路徑依賴

看完第一個路徑依賴，我想你已經能猜到，這第二個會是什麼模樣了。

很多軟體 PM 在會議中常常會覺得，聽不太懂工程師在說些什麼。而我想說的是，你是對的！因為我也聽不懂。

既然寫註解、docstring 這種應該用「簡潔清晰的自然語言」表達的場合，我們都容易藉由程式邏輯與實作細節含混帶過。

那麼軟體工程師在會議中的表達，自然也會受到此「慣性」影響。

重解決方法，輕問題本質

以我個人的經驗，工程師在描述自己工作上的要解決的問題、解決方式、可能的方向、已完成的任務等等，非常容易陷入類似的路徑依賴。

其結果就跟前面提到的程式註解一樣，你不會覺得對方是在講「人話」，而像是一種對技術方案、程式邏輯的「輪廓描述」。

至於所要解決的問題、背後的痛點究竟是什麼？選擇的依據為何？常常會直接予以忽略——因為滿腦子都是技術思維。

導致重點還沒說清楚，相關細節卻講了一堆，本末倒置。

身為會議的聽眾，哪怕同是軟體工程師，我可能連「問題是什麼」都還不甚清楚，然後對方已經開始自顧自的說起解決方案。

通常我會適時打斷，補充說「等等！我們可能要先知道的是，為什麼……」、「這樣講別人可能不容易懂，可以先講○○○就好」，好讓對方重新調整闡述方向。

練習：以他人的角度思考

前面提到，不好的程式註解，就像一個人的自言自語。而這樣的表達方式，又何嘗不是如此？導致我們常常需要提醒對方「等等！……」

不過平心而論，良好的溝通、表達，對任何人都不容易，都需要一定的練習。

換句話說，要把一件事情講好，絕對需要先構思、自我反芻、察覺他人容易產生的疑問，並且以他人的角度去思考，才能真正做到「說人話」。

只不過軟體工程師基於職業上的特性，在感到表達困難的當下，容易反射性地躲回自己熟悉的技術與專業領域，以獲得一定的自適與安全感。

2024/05/21：我得強調一件事，要用簡單的自然語言，把複雜的開發邏輯講清楚、好討論，本來就很難！所以本文著眼的，是那份「願意好好表達」的意識，與背後的用心，而非「表達能力」。

這樣的路徑依賴，對於工程師的溝通能力和團隊協作，都會帶來一定的負面影響。

這無疑會讓沒有技術背景的人，感到困惑和隔閡。

結語：讀者意識的欠缺

講完前兩項，本篇要收尾了，我們作個小結。

前兩個路徑依賴凸顯的都是當事人對於「他人很可能會不理解」這個意識的強烈欠缺，以至於常常用一種旁人看來近乎「自言自語」的方式在表達自我。

如果是一個作者，那就是「讀者意識不足」——寫出來的文章只有自己看得懂。

所謂的「讀者意識」，指的是作者在寫作時預見到讀者的理解困難，並通過語言表達和組織結構來幫助讀者，使讀者更容易理解的能力。

「讀者意識的欠缺」在軟體工程師中確實是一個普遍存在的問題。

有時候，我們可能過於專注於自己的程式碼和技術細節，而忽略了將這些複雜的概念和思維以易於理解的方式傳達給他人。

我也不敢說自己已經完全擺脫了上述的困境，在「讓自己與自己的工作產出容易被他人理解」這個面向上，我們還可以不斷努力，一直努力。