閒聊 - 作廢的 Code 你會刪掉還是做成註解牆？順聊程式設計爭議心法

上個月保哥有篇 FB 貼文，聊到當系統規格修改，原本辛苦多時寫成的大段程式碼瞬間報廢，大家會一口氣刪掉眼不見為淨，確保程式碼清爽？還是先註解起來，當客戶改變心意把規格加回去能快速還原？

把不用的程式碼註解起來這事兒我以前常幹，但出發點不太一樣，主要不是預防客戶把規格改回來。舊功能復辟這種事不是沒發生過，但次數屈指可數，且若時間相隔較久，相關邏輯及資料多半已有落差，真能回收使用的案例更少。把大片廢棄程式註解起來築成註解牆，更大的用意是方便日後鑑古知今，了解程式規格演進的完整歷程。

在版控軟體還不成熟、版控不是開發者必備技能的年代，古代開發者要做版控多半是靠檔案系統。改版前複製成新資料夾再改、舊檔另存 .bak/.v1.bak/.v2.bak、或是把舊版 ZIP 存查... 大家各出奇招，在沒有 Git 這等神器可用的年代，不管你用什麼方法，需要回溯程式碼時，能翻出完整歷史軌跡就行。

【版控小科普】Git 是 Linus 看不慣 BitKeeper 免費版對開發者處處設限，一氣之下決定自己為 Linux Kernel 寫的版控工具，後來由腦粉濱野純接手維護，逐漸成為簡潔高效的成熟分散式版控工具。Git 1.0 發佈於 2005 年，但早期只用於 Linux 核心開發，隨著 Github 於 2008 成立後才迅速推廣普及。依據 2025 統計，Git 市佔已高達 93.9%，海放第二名 SVN (5.18%)、第四名 Mercurial (1.13%)。咦？怎沒有第三名？第三名是瀟灑不羈派，不用版控軟體(4.31%)。
(註：若你對 Git 的起源有興趣，這篇貼文值得一讀)

圖表來源

熟悉 Git 的人應該已很習慣用 git log 即時取得檔案完整修改歷程，何年何月何日被誰改過，鐵證如山。而 git blame 更是能讓你瞬間抓出某行程式碼是何時被哪個混蛋改壞的(啊... 原來是我自己)。早年沒這等神器可用，追溯修改記錄是件勞神費工的苦差事。若舊版被另存檔案，要翻出新舊版對照比較，往往還需動用 Beyond Compare 之類的比對軟體協助。相較之下，若修改時只是把舊版程式碼註解起來留在原檔案，未來要追查修改歷程時只需上下捲動，便能了解規格演進的來龍去脈，~~緬懷過往一場場可歌可泣的戰役，~~評估新規格時如同學長學姐在旁為你講古，更能掌握情境脈絡。(我知道，有人會主張這是系統文件該做的事，但要求程序員選擇看程式碼或看文件？寫註解或寫文件？二者成功機率有別，前者多數凡夫可及，後者屬聖人的行徑。不是每個人都有幸身處精銳部隊，把門檻降到結訓新兵也能上手，更利推廣)

在欠缺 Git 等方便版控軟體的年代，把整段不用的程式碼加上取消或作廢事由再註解起來，固然會犧牲程式碼的簡短性，減損資訊傳達效率(久久才會派上用場的文字佔用大量版面)，踩到某些人的底線(不少人對廢 Code 近乎零容忍)。但這類習慣常源自某個先人全數陣亡、文件不全的系統的某段難以理解的程式(心想當時寫程式的人應該是加班加到瘋了才會寫出這種鬼東西)，最後由前後方註解掉的大段程式碼跟規格異動註記找到線索拼出來龍去脈，理解程式為什麼是這副德行(並在心中說出「學長，您辛苦了」)；又或者某次，歷經兩個月五次修改，客戶說出傳說中的經典台詞「嗯，怎麼改都怪，我們還是用一開始的版本好了」(補聲幹)。遇上一次，遇上兩次，「報廢程式碼註解起來別刪掉可積陰德」的種子便悄悄在心中萌芽，之後便在系統各地長出一道道註解牆... 甚至還代代相傳。

以上是走過備份檔版控時代老人對註解牆形式原因的理解，部分情境或許是 Git 時代才上車的新同學較難想像的。

基於背景及經歷不同，你心中天經地義行之有年的習慣，在另一個群族眼中可能是愚不可及的蠢做法。所以，對於沒有絕對對錯的程式設計爭議(像是 { 該不該另起新行、行末要不要加分號、用 Tab 還是空白)，每次拋出來總能讓大家吵成一團。寫程式寫了 40 年，我現在都用另一個角度看待這類問題 - 槓探討這類問題的境界有三層：

• 知其然 - 我覺得應該 OOO
• 知其所以然 - 之所以該 OOO，是因為 OOO 有以下優點
• 知其所以不然 - 能理解或推敲出某些人之所以不 OOO 的理由

(猴子說，沒問題交給我：之所以該 OOO，是因為白痴才不用 OOO；至於那些人之所以不用 OOO，因為他們是白痴。)

這些年我特別喜歡挑戰第三層，每當發現有人與我習慣不同，或是看到極度荒謬不合理的設計，我的第一反應不是冷嘲熱諷，而是試著融入相關情境時空，想辦法為當事人找個「當時做出這個決策是合理的」的說法，最理想的標準是「如果是我，我可能也會這麼做」(不過也不乏有些得加上「當時頭被門夾到」「忽然想報復社會，讓後人一袋米扛幾樓」之類的附加條件才能做出解釋)。我發現這麼做有很多好處：

• 思索過程像看偵探小說或玩密室逃脫，過程饒富趣味且充滿成就感
• 有時解釋難度逼近「為什麼井被吹到牆外」，過程燒腦，有助活化腦細胞，預防老年痴呆
• 逼自己幫對方找合理解釋需積極蒐集反面論點的資訊，助於消除盲點，補足對該議題的知識完整度
• 經常換位思考，無形中會提高對不認同事物的包容度、消彌暴戾之氣，減少跟人吵架的衝動與機率
• 別人忙著對摃拼輸贏，我趁機思考長知識，偷偷提升競爭力 (謎：一把年紀還要這麼卷就對了？)

扯遠了，回到註解牆上。

我覺得把不要的程式碼註解掉而不是刪掉是有好處的，一來方便日後快速參照、二則萬一規格改回來有機會重啟使用，缺點當然看 Code 改 Code 時，螢幕滿是無用文字有損效率，有時還會在全文搜尋時出來攪局，但享受好處就得付出代價。然後這個議題在我學會 Git，開發人生從此變彩色後改變了，既然 Git 能快速追溯每一行程式的修改歷程，我們就沒理由把不要的程式碼完整留在程式裡佔空間。但我習慣在刪除後的遺址留下一行註解，解釋移除理由：

// 2025-06-21 經與 X 單位討論，因送件流程調整，決議移除 Y 功能

只有一行註解，佔用空間有限，但能有效提醒閱讀到該處的人，這裡曾經存在過一段程式，因為什麼理由移除，有助於還原歷史、拼湊故事脈絡，原地保留的記錄最有機會幫助到需要舊程式而追到該處的人，順手留個線索，其功德直逼扶老太太過街。

常需要參考當時的程式碼，找到該行註解來源 Commit 便有完整答案，既然舊程式碼唾手可得，自然可以大大方方刪除。

評估下來，這套做法的小小缺點是得熟悉 Git，但這年頭，不懂 Git 是開發者的缺點，不算做法的錯，所以就當沒缺點吧! 哈~