軟體業最荒謬的管理方式，就是用「程式碼行數（Lines of Code, LOC）」或是「Commit 數量」來評斷一個工程師的產值。寫程式不是在菜市場秤斤論兩賣豬肉好嗎？一個真正資深的工程師，花三天時間把一千行的義大利麵邏輯，重構縮減成一百行的乾淨架構，結果在這種智障 KPI 制度下，他的產值竟然是負的？

阿姨年輕的時候待過一間系統廠，某天來了一個傳產思維的空降主管。他看不懂架構，只會看報表，為了展現他「精實管理」的績效，竟然在部門大會上宣布：每人每週必須產出至少 500 行 Code，並且要在 GitLab 上有至少 5 個 Commit，否則分紅 0 。

這項政策一頒布，整個技術團隊直接進入「惡意合規（Malicious Compliance）」模式。

原本可以用一個迴圈寫完的邏輯，菜鳥硬生生把它展開成十幾行；原本應該寫在迴圈裡的變數宣告，全部拆到最外面。最扯的是，有人為了達標，把自動產生的 package-lock.json 跟一大包肥到不行的靜態字典檔（Dictionary）直接 Commit 進去，一天的程式碼產出量高達三萬行，主管看了還在月會上大力表揚他。

結果不到半年，我們的 Codebase 肥大到連編譯都要花上十分鐘，滿地都是高度重複的 Copy-Paste 垃圾。這就是用程式碼行數當 KPI 的下場。

面對這種只看數字不看品質的外行主管，你跟他談 Clean Code 或是 Refactoring 是沒有用的。你必須用系統機制來「反向制約」他的管理報表。

1. 在 CI/CD 導入「圈複雜度」與「重複率」掃描
   主管愛看報表？那我們就給他看更致命的報表。在 SonarQube 裡設定嚴格的 Duplication Rate（重複程式碼比例）與 Cyclomatic Complexity（圈複雜度）。當那些灌水的垃圾 Code 把重複率刷破 20%，讓整個專案的 Quality Gate 亮起大紅燈、無法部署上線時，直接把鍋甩回去：「報告主管，為了達到您的行數 KPI，系統複雜度已超過安全閥值被迫停工。」

2. 區分 Generated Code 與 Source Code
   如果真的被逼著交行數，請善用 .gitattributes，把那些自動生成的檔案（如 JSON、Lock 檔、編譯檔）標記為 linguist-generated=true。讓那些想靠假檔案刷 KPI 的薪水小偷原形畢露。