本文最初發表在 Understand Legacy Code，經原作者 Nicolas Carlo 授權，InfoQ 中文站翻譯並分享。
管理層是不會讓我對遺留代碼進行重構的！
你認識到自己現在的處境了嗎？那是多麼令人沮喪的事啊！
作爲一名開放人員，經常會遇到這樣的情況：管理者似乎對修復已經存在的問題不感興趣。
新功能！緊急發佈！錯誤修復！推遲重構那個混亂的代碼庫總有這樣的或那樣的藉口。😭
就算你解釋了乾淨代碼的優點和好處，管理者們似乎仍然不理解，也不關心。他們關注的重點總是成本和時間，而不是質量。而現在，面對不斷積累的技術債務，就算你想去解決，也會感到有心無力。
IT 部門深陷在爲不耐煩的客戶提供生產支持的困境。
客戶不會爲重構買單。
感覺就像是失敗的事業！
這樣的形勢已經逼得許多優秀的開發人員捲鋪蓋走人了。現在的情況啊，真是鐵打的公司，流水的開發者。
管理者不是工程師
你需要幫助管理層瞭解糟糕的代碼質量對商業有什麼樣的影響。
歸根結底，對公司來說，最重要的是創收、盈利能力。爲了降低成本、增加收入，管理層需要作出最好的決策。
因此，如果你想爲重構說出理由，就應該學會商業語言。
作爲一名前顧問和技術主管，這些都是我曾經做過的事情，所以，就讓我來幫你一把。
可用於管理層的五個論點
1. “重構將減少功能邊際成本的波動性。”
這句話是出自 J. B. Rainsberger 的名言：“軟件設計經濟學”（The Economics of Software Design）。
別逃避！這只不過是一種聽起來似乎很明智的方式，把自己已經知道的事情說出來就好。
讓我們來分解一下：
-
到目前爲止，“重構將減少”這說得還不錯。
-
“波動性”就是“不確定性”的另一種說法。
-
“邊際成本”是指多生產一個單位的成本。
-
“功能”就是商業價值！是啊，我們都對商業價值感興趣。
它的要點就是這五個論點的核心。當我們與非技術人員交談時，我們卻忽略了這一點：
用他們的語言來說。
不要用極客們慣用的話語。要談經濟、談商業。這就是我的祕訣！
與你的管理者聯繫去吧。
所以，來試試這樣跟他們談論這個論點吧。畢竟，你知道這個論點到底是什麼意思。
2. “在過去三個月裏，我們用了 63% 的開發預算來解決質量問題。”
我會讓你根據實際情況對這個數字予以調整。😉
此處的重點，就是要用數據來說話。這個技術宅肯定會影響到你的日常工作。你能證明這一點嗎？
你當然可以！
下面是一些例子，你可以參考：
- 隨着時間的推移，你的速度會怎麼變化？你每次衝刺能拿到多少分？它會下降嗎？
- 每週報告 Bug 的數量。每週修復的 Bug 數量。Bug 是否在積累？花在 Bug 修復上的時間是不是越來越多？
- 跟蹤每週發生的緊急事件的數量。是否在持續？這個數量會不會上升？
給管理層看看劣質產品的成本。
額外建議：將這些數字與實際金額掛鉤。💰
有一天，我參加了一個 Bug 的事後調查分析。這個 Bug 本可以通過靜態類型檢查來避免。代碼是用 JavaScript 編寫的。當時公司里正在進行一場遲日曠久的辯論：到底要不要採用 TypeScript。
進行事後調查分析的開發人員做了一些挖掘工作，並能計算出那個 Bug 對業務的影響。
就在這個 Bug 存在的那幾個月裏，已經讓我們損失了 100 萬加幣。100 萬加幣啊！
僅憑這一點，TypeScript 就值得投資！
因此，公司決定，新的服務將用 TypeScript 實現，而關鍵服務將通過類型檢查重新審查。
3. “我們拿了技術貸款，爲了更快地交付，我們需要償還一些債務，以保持降低上市時間。”
我再說一遍，用他們的語言來說。
使用比喻可以非常有效地傳達信息。它通過與他們所熟知的東西聯繫起來，可以幫助別人理解他們不熟悉的概念。
“貸款”是管理者們都會熟悉的一個概念。“技術債務”也是一個著名的比喻。
你還可以將公司想象成一個餐廳，把代碼庫想象成這個餐廳的廚房。當你任由盤子堆積如山時，外面等待的客人越來越多，問題會變得非常棘手，在這種情況下，你的員工需要開始洗碗刷盤。
4. “我們可以通過將 10% 的時間投入到代碼質量上來減少員工離職帶來的影響。”
我們已經討論了劣質產品的直接成本。
但有一個惡性的因素可能會被忽視：員工離職。
如今，企業要想留住開發人員已經很難了。尤其是優秀的開發人員。當員工士氣低落時，他們就很容易會跳槽。一些能讓他們擺脫困境的東西。
嘿！也許你已經在那裏了，夢想着有一片更綠的青草！
現在，請提出一個問題：
爲了更換一個已離職的開發人員，我們需要花多少錢？
要吸引新的人才，聘用他們並讓他們入職。而這既要花錢，又要花時間，還會拖累團隊的效率。
你的管理者肯定不願意每年都更換開發人員。減少員工離職率是一個令人信服的理由。並且，如果能有個解決技術債務的計劃，就已經對團隊士氣起到了提振作用。
5. “將預算的 20% 用於重構，可以減少一半的首次迴應時間，並對開發人員的工作效率帶來正投資回報率。”
首次迴應時間（First Response Time，FRT），是客戶支持的關鍵指標。
讓客戶滿意，對企業來說很重要。
重點是：
- 獲取對客戶支持部門重要的指標。
- 確定一些反覆出現或需要開發人員解決的問題。
- 提出一項計劃，通過解決問題的根源，來減少支持問題的數量。
通過解決這些問題，開發人員在協助客戶支持方面將花更少的時間。這將彌補所投入的時間：正投資回報率。
額外建議
但最終他們還是做出了決定
對嗎？
好了，我剛纔給你了五個論點，這些論點可以幫你向管理者們論證解決技術債務的重要性。
但是，我覺得在你去找管理者談談之前，我還應該給你最後一個額外的建議。
需要重構時就動手吧。
重構不應該是實現功能之外的獨立步驟。事實上，你無法預知下一個功能是什麼。因此，你必須對代碼進行重構，使其適應新的現實。
這是你工作的一部分。
作爲一名專業開發人員，你知道怎樣才能不斷帶來商業價值。
這是行之有效的做法，即使是在遺留代碼庫上也是如此。但也就這樣了，不會再好到哪裏去了。而且，你也不可能做到隨時進行大規模的重構。但至少，情況不會變得更糟糕。
使用遺留代碼並不是一件什麼好事，而是爲了更好。
每修復一個 Bug，就要多花一個小時編寫一個自動化測試。對於每個功能，都要多花一天的時間來清理代碼。讓改變變得更容易。每天都要如此。這樣，幾個月後，這個習慣將會對你的工作效率產生巨大的影響。
你知道爲什麼嗎？
因爲這些利益複合，降低了功能邊際成本的波動性！
作者介紹：
Nicolas Carlo，在加拿大蒙特利爾生活和工作。他創建了軟件工匠蒙特利爾社區（Software Crafters Montreal community），該社區關注構建可維護的軟件。
原文鏈接：
https://understandlegacycode.com/blog/5-arguments-to-make-managers-care-about-technical-debt/