屎山上的神廟與新猴子背鍋 揭開技術斷層與知識傳承危機，破解屎山背鍋

面對前人留下的「屎山」，新猴子如何突圍？

在 專案管理 中，新進人員常面臨在 屎山代碼 上建造新功能的挑戰。Project Banana Paradise AI 的案例顯示，當核心開發者轉型為管理層後，常因追求亮眼 KPI 而忽視 技術債，導致 知識傳承 出現 技術斷層。新猴子被賦予重責卻缺乏文件與支援，最終演變成 權責不符 的責備文化。打破僵局的關鍵在於建立透明評估機制，讓管理層意識到維護成本，而非單純轉嫁壓力。

屎山上的神廟：在不穩固的地基上強行套用新技術，只會讓系統的脆弱性加速爆發。

定義：什麼是「屎山代碼」與「技術斷層」？

「屎山代碼」是指經過長期無序開發、缺乏架構設計且邏輯極度耦合的舊系統；「技術斷層」則是系統核心開發者離開或晉升後，後繼者無法獲取足夠的背景資訊與設計邏輯，導致系統維護成本飆升的現象。

歡迎來到 Project Banana Paradise AI 的遺跡探險之旅！隨著系統越長越大，當初跟著評審猿的英雄程序猿因為戰功彪炳，如今已是高高在上的管理猿和戲精猿，並留下一座巨大的程式碼迷宮，卻忘了給地圖。

維護和擴建這座日益複雜的 AI 系統的重責大任，就落到了新招募的年輕程序猿身上。現在，新來的程序猿被迫在這座迷宮上，套用最新的智慧決策模型蓋一座全新的 AI 神廟。

寓言分析：英雄變主管，留下地圖卻忘了給指南針

一位新來的程序猿報到的第一天，就被指派了一個任務：為「智慧蕉倉」增加一個新的庫存預警模組。

他打開程式碼，瞬間傻眼。整個系統像一座巨大的、沒有標示的迷宮。無數的子系統和模組互相呼叫，命名混亂，而且沒有任何文件說明「當初為什麼要這樣設計」。程序猿想找人問，卻發現最資深的程序猿也只來了半年。

而那些真正知道答案的猴子，現在正坐在另一間會議室裡，討論著下一季的 KPI 該如何制定。曾經的英雄們變成了管理猿和戲精猿，留下了戰場的地圖，卻忘了給後人最重要的指南針。

角色透視：在「屎山」上蓋新神廟的壓力

更糟的是，評審猿最近迷上了最新的智慧決策模型，他下達了一道指令：立刻將現有的 AI 系統，替換成最新的智慧模組！這個指令，對新來的程序猿來說，無異於要求他在一座搖搖欲墜的屎山上，蓋一座富麗堂皇的新神廟。

地基是不穩的，架構是不明的，每一行他動到的程式碼，都像是踩在未知的地雷上。壓力之下，出錯成了必然。

很快，一次發布中程序猿的修改意外地影響到了另一個從未聽說過的子系統，導致香蕉派送流程大亂。災難發生後，程序猿被管理猿叫去痛罵了一頓，而這位管理猿，正是當年親手寫下那段混亂程式碼的英雄之一。

程序猿委屈地解釋：

「報告，我不知道這個模組跟派送系統有關聯，文件上沒有寫。」

管理猿不耐煩地打斷說：

「這種基礎的東西還要文件嗎？你自己的責任，要多想想！不要總給團隊添麻煩！」

那一刻，程序猿徹底心灰意冷。看著眼前這位曾經的技術大神，他感到一種巨大的陌生感。為什麼最懂這座迷宮的人，在晉升管理職後，反而成了最冷漠、最不願理解歷史問題的人？或許是因為承認系統的脆弱，就等於承認自己過去留下的爛攤子。將責任推給新人，遠比回頭清理自己的技術債要輕鬆得多。

行動指引：這鍋，到底該由誰來背？

這早已不是一隻猴子簡單的問題，而是一個典型的組織系統性問題：

• 知識斷層：核心知識掌握在少數管理者手中，且沒有被有效傳承。
• 權責不符：新人被賦予修改核心系統的「責任」，卻沒有得到足夠的權力與支持。
• 目標錯位：領導層只追求新功能，忽視了維護現有系統穩定性的隱形成本。

FAQ：接手遺留系統的生存策略

Q1：接手完全沒有文件的「屎山」代碼，第一步該做什麼？

A：進行「黑箱測試與日誌追蹤」。在不改動核心邏輯的前提下，透過輸入輸出觀察建立行為地圖。利用自動化工具生成呼叫圖 (Call Graph)，補齊最基礎的結構資訊。

Q2：如何說服「老猴子」主管給予時間清理技術債？

A：將技術風險轉化為「開發速度 (Velocity)」。展示：因為地基不穩，目前增加功能需多花 200% 的測試時間。強調「清理債務是為了下一季跑得更快」。

Q3：當發生故障且被指責「沒看文件」時，該如何應對？

A：保持事實導向溝通。回應：「我確實查閱了現有文檔，但此處耦合邏輯並未記錄。我已將此關聯補進文檔中，建議未來重大修改前能有更資深的同仁進行 Code Review。」

Q4：如何避免成為「背鍋猴」？

A：落實「影響評估 (Impact Analysis)」。在任何重大修改前，發出書面評估，列出不確定區域與潛在風險。當風險被明確標註，責任就不再僅由執行者承擔。

結論：別讓技術債成為新人的墳場

當一個團隊開始頻繁地責備新猴子犯錯時，真正該被檢討的，也許是那些掌握資訊卻選擇了遺忘的「老猴子」們？

• ← 上一篇
• 下一篇 →