您所處的情況並非是唯一的，並且並非不合理。在基於生產的軟件開發中，這實際上是相當標準的。需要注意以下幾點：

1. 技術債務是無法衡量的。您無法檢查功能並“量化”有多少技術債務，或有多少錢不能幫助您。您可以嘗試，但最終數字沒有意義，甚至無濟於事。就像您無法查看一個函數並告訴它“有多少個bug”（這是我最近被問到的一個字面上的問題）一樣。企業優先考慮“功能勝過修復”的原因是，客戶告訴他們“如果添加某某某物，我們將開始使用您而不是其他人”。技術債務無濟於事，因此您需要找到一種出售它的方法。
2. 企業靠收入經營。在IT /軟件開發人員中，我們經常會誤解或忘記了這一點，但企業需要賺錢才能生存。這意味著，它必須找到一種削減成本或提高利潤的方法。大型重構（您將停止使用新功能的重構）不會這樣做。您需要做的就是證明您可以重構並節省或增加利潤。
3. 無論如何，重構（因此，消除債務）是常規過程的一部分。一項功能，無論如何，您都應該始終重構並減少那裡的技術債務，不是事後的想法。問題在於，沒有人在第一次構建它時就做過這樣的事情，所以您可能就是所謂的“在堅硬的岩石之間” –結果，您認為唯一的選擇是進行大型重構，但這不是唯一。每當您觸摸某個功能時，都應該進行一些重構。這只是開發過程的一部分。
ol>

---

那麼，您能做什麼？

我將根據我的經驗為您提供建議，這使我能夠說服一家金融服務公司在整個第三季度（七月，八月，九月）為我提供重構我們的Web應用程序的機會。我們正在處理具有20年曆史的應用程序，該應用程序具有大量的代碼（最新的行數估計在200+百萬之間）。我說服他們給我三個月的時間（讓其他團隊做他們的事，給我三個月的時間）來重建必要的東西。這並不容易，您也不會，但是它教會了我一些寶貴的經驗。

首先，如另一個答案所提到的ROI分析。提出通過估算專用重構期來估算和證明我們可能會遇到的優勢的方法。它們不必一定很大，如果您可以證明1小時的開發時間可以在每次加載時節省9分鐘的時間，那麼這是一個不錯的開始，特別是如果它是高流量的功能/模塊/等等。 （即，使用已經重構的功能作為概念驗證。）

第二，重新編寫您的請求，以便指出業務優勢。

strong>我不想這麼說，但是，如果您不打算在一家“新興”公司中工作，那麼您的老闆將不在乎您的感受。你的老闆會在乎如何從中賺錢。了解（可能來自銷售，客戶服務等）什麼加載時間困擾著客戶，並描述我們如何解決該問題以提高客戶滿意度。 （不知道您的軟件有多專業，但是我構建的某些軟件是特定於我們行業的，因此“口碑”是巨大的。因此，如果您可以使客戶更好地喜歡它，也許他們會告訴您他們的朋友。）

第三，不要“抱怨”當前的現狀。不要“抱怨”，不要“生氣”，說實話。如果您不理emotion地與他們交談，並且以積極的態度陳述事實，您的經理很有可能會接受。不是“這段代碼是廢話”，而是“在這裡我們可以獲得一些戰術優勢。”不要談論某某某人如何編寫錯誤的代碼。不要談論某某事物與某某事物有何相對。談談優勢。保持積極的對話。 （我知道那是多麼艱難，但是“咬你的舌頭”通常是一件好事。）

第四，與開發人員討論節省的時間，以及如何節省時間應用於其他項目/問題。您的待辦事項是什麼樣的？它在不斷增長嗎？您是否正在將事情推遲越來越多的時間？談一談這將如何（並將影響）。如果企業從新功能中獲得價值，請談談這將如何使您有時間更快地創建新功能。談論這將如何加快開發人員的速度。

第五，這聽起來像是我在“混蛋”，但不要談論“如何使開發人員的生活更輕鬆” 。” ^{1 sup>我討厭成為壞消息的承擔者，但您的經理並不經常關心開發人員的感受。在大多數組織中，我們都是“生產”角色，也就是說，我們嚴格按照賺錢的方式做事，類似於物流公司的倉庫工人。除非如前所述，除非您在一家完全不同的公司工作，否則管理層不會經常為“開發人員幸福”投入過多的精力。完全放棄該想法，然後談論從您的想法中獲得收益的業務和原因。}

最後，要了解的是，如果這是一個舊的應用程序，並且重塑已經在進行中，最好的選擇可能就是“吸納”並希望情況會變得更好。如果他們已經在開發新版本，則您的團隊不會獲得所需的資源或時間。他們將您的團隊視為“分類”團隊。您的存在是為了確保當前的那一台保持足夠長的時間來建造新的一台。是的，很爛，但這是事情的運作方式。我去過許多分流團隊，其中大多數人的幸福感很低，周轉率很高，但這就是生活。業務無關緊要，因為您的工作是使當前的公司盡可能便宜地運行。可悲的是，高周轉率幾乎是有利的，因為這意味著薪水要低得多。 p>

^{1 sup>：世界上某些地區目前處於“開發人員短缺”時期，這意味著他們沒有足夠的備用開發人員來填補當前的角色，更不用說新的角色了。在某些情況下，公司會認真對待開發人員的滿意度。那不是我的經驗，我是根據 my 經驗寫這個答案的。因此，在本主題的這一部分，您的里程可能會有所不同（有時會很大）。}

當然，有優點和缺點。

您將其視為技術債務，因為其中包含大量代碼和大量數據。

在硬幣的另一面，看起來系統目前的工作方式似乎並不一定有任何問題。

正如已經指出的那樣，實施一個程序來重構代碼本身就是在分析，重構方面增加技術負擔。 ，重新測試和重新部署已經運行的系統。返工的系統越大，業務所面臨的風險就越大。

折衷方案是在相當狹窄的範圍內僅重構那些正在積極工作的部件-因此分析和測試受到限制

否則，您將把人們投入很多年的努力中，而企業實際上並沒有從中受益。

我知道這是' t您所要的答案，但它是現實的，並且（我認為）具有經濟意義。

現在，似乎有些工作流正在對客戶需求做出反應在性能方面。您還沒有遇到過相同類型的請求，因此，您真正要做的就是等待，使分配的工作任務盡可能高效。

您可以運行自己的請求自己進行分析並提出需要改進的地方，但這只能由經理根據企業對整個系統的優先級來批准。

簡短的回答：您做不到。

簡短的回答：管理層對業務價值感興趣，您不能出售技術債務。但是，當您導致每個模塊單獨出售時，您可以通過測試自動化或模塊化來降低質量檢查成本。只需說他們的語言即可！

請注意：經理是一個專業的專家。對您來說，是15年的一堆垃圾，他將其作為行業標準質量交付的15年記錄。當經理說諸如“相信我們需要為績效而努力”這樣含糊其詞時，它只是為了讓您感到滿意和服從而獲得的學士學位；當經理需要完成某項工作時，這是到期日和負責交付的人員。您說，您的團隊是“最好的”，這意味著對團隊工作流程的任何更改都符合公司的利益，並且會大力反對，因為這會影響經理的薪水，您不僅會被視為公司的敵人，而且會被視為膽敢的個人敵人後果。

值得注意的是，如果您在修復錯誤和添加新功能時做一些小事情或進行重構，則管理層對此並不感興趣。他們對KPI感興趣，他們每季度或每年在演示中展示一次。

因此，如果您想通過改善代碼庫來簡化開發人員的生活，只需在不通知管理人員的情況下秘密進行。

一種解決方案是，技術債務單也應顯示在儀表板上。另一個解決方案是績效應該作為衡量所有團隊的最高標準。

我同意重構的用途有限，如果沒有單元測試，重構可能會非常危險。添加單元測試可能更容易銷售，因為這可以提高每個人的可靠性。

但是總的來說，如果這是您經理的態度，那麼更改將非常緩慢，並且過程可能會令人沮喪。也許更換團隊會做得好嗎？

我可以從這方面的經驗中發言。

幾年前，我是著名大型機產品（Comparex）的首席程序員。基本程序中的代碼是亂七八糟的意大利麵條，修改它的任何嘗試都會破壞其他三件事。

發布週期大約一年。大量積壓的請求更改，但每年只有少數完成。因此，我瀏覽了整個程序並將其轉換為結構化格式。

這是一項艱鉅的工作。實際上，我必須開發工具來分析代碼並幫助記錄哪個例程調用了哪個例程。最終，我消除了除3個非結構化分支之外的所有分支。

現在，當我完成此工作時，大部分開發週期都已消失。因此，我隨後在請求隊列中實施了一些更改，儘管它們花了很多時間來重組程序，但它們進展得如此之快，以至於當年我就能進行“正常”的升級。

明年，我仍然能夠快速實施更改，並且完全消除了積壓的請求。

您需要編寫業務案例並顯示投資回報率（ROI）；大多數業務決策都歸結為金錢。您需要證明，通過重構，它將在未來永遠永久地加快XX％的開發速度，或者消除了對額外開發人員或兩者的需求，但是它將在XX個月內將生產率降低XX％。如果您可以這樣做，他們可能會參與重構。但是，

1. 沒有單元測試，就很難不破壞現有功能。
2. 通過提高生產率/質量來更好地重構產品
ol>

我們在某種程度上都在那條船上。抱怨不太會有幫助-您只會被歸類為不了解快速完成工作的需要的人，而您的建議將被忽略。

問題是，大多數程序員不會如果這不是解決問題的最直接方法（例如，構建用於檢查數據庫一致性或編輯系統數據的工具），則認為他們具有“權限”可以正確進行修復。自動化-您是一名程序員，對嗎？

您不僅有權做正確的事情，而且必須這樣做，這是您工作的本質，您的經理可能無法理解這些因素，但是如果您花時間去做的話是的，不要抱怨他們可能不會打擾您。如果經理或頑固的程序員不了解這種方法並積極與您抗爭，請開始尋找其他工作。

您還可以幫助您的隊友了解他們可以正確地實施更改。

當涉及到較大的修補程序（如5分鐘的啟動時間）時，請將其提交為bug，然後在處理該bug時將代碼重構為

隨著時間的流逝，您應該成為提供解決方案最快的團隊（否則，您將無法進行正確的重構，因為您說一個星期的工作應該花幾個時間幾小時就可以清理完），那麼您將擁有更多的迴旋餘地，並且可以進行更廣泛的更改。

我建議不要說我們必須重新編寫所有內容。像這樣的大型項目幾乎總是比預計的和/或失敗的時間長得多，並且這樣做可能會花費很多工作或整個公司。

簡單的答案，您不能從頭開始放棄並重寫這麼大的代碼庫；

但是，您所能做的是想出一個計劃，以編寫出更好的代碼以繼續前進。

您和其他開發人員需要想出辦法你們所有人都將遵守的編碼結構計劃。

您需要構想這種獨角獸-烏托邦式的環境，並努力以每一種可能的方式來發展它。

p>

是的，它將需要與當前的“憎惡”共存，但是當您獲得任務和工單時，它們便會繼續工作到烏托邦。

一旦驗證了新代碼並努力規範，然後您就可以刪除過時的代碼。

以這種方式思考；當客戶聘請畫家為門粉刷時，客戶並不關心畫家使用的是2英寸畫筆，3英寸畫筆還是小滾筒和畫筆組合。如果油漆進入了門，那就成功了。

再添加一個參數來準備您的音調。

在這個堆棧上有一個問題如何吸引人們從事非常古老和過時的技術工作？最近問。我建議也許不是現在，但在不更改流程的情況下，公司可能會在5年內找到自己的位置，他們將不得不向理解其代碼並願意看它的人們支付高額薪水。

如果新開發人員需要一年的時間來熟悉代碼庫，則意味著如果10％的員工辭職，公司將需要幾個月的時間來尋找替代產品，而一年的時間才能使替代產品變得高效作為失去的員工。甚至可能一年半損失10％的生產力。如果公司規模不大，並且目前有40名開發人員在編寫代碼，那麼10％的人只有4個人。

我認為這可能是一個緩慢的過程。詢問 new 項目是否可以通過單元測試和現代化來編寫，並解釋說它將確保功能。最終，管理層將發現這樣做是有益的，因為可以輕鬆更改代碼，並可能建議將應用程序的其他部分“更新”。

現在，您正在與自滿進行鬥爭。 軟件可以正常工作，開發需要花費週的時間，但已完成。任何人都可以爭辯說軟件不會永遠持續下去，因此，無法正常工作的64位可以很容易地被丟棄並“在進行中”。如果您可以證明可以在 days 天內完成而不是 weeks ，或者可以輕鬆移植64位代碼，那麼它會有所幫助。

1. 構建“業務案例”-證明減少技術債務將為您的組織帶來價值。使用明確的數據點來證明您的情況。
2. 傳達提案。簡短點說，經理們沒有時間閱讀“ TL; DR”文本。如果您可以在5秒鐘內提出您的想法，並且說得通並且符合組織目標-經理將要求您提供詳細信息。
ol>

我希望這會有所幫助。

我的建議：每當您需要修復錯誤或添加功能，並且在代碼的某些區域中工作時，都使該區域處於比現在更好的狀態。如果由於代碼質量差而花了更多的時間進行更改，那麼這樣做不會為工作增加明顯的時間，對下次在該領域有所幫助。

我會給您的老闆一些建議：如果您的代碼未在64位系統上運行，那麼您很快就會感到痛苦。這是我所在的地區發生的事情：在過去的兩年中，您無法發布不支持64位的iOS應用。如果您的用戶使用iOS 11（當前版本為幾個月），則32位應用程序將無法運行。 MacOS稍稍落後，但是用戶現在會收到警告（這將使您獲得很多昂貴的支持電話），並且在下一個MacOS版本中，將不再提供32位支持。

Windows的運行速度稍慢一些，但是出於完全合理的技術原因，不允許使用32位應用程序。而且，當這種情況發生並且您沒有可用的應用程序時，您的老闆就會遇到麻煩（您沒有，因為他們會需要您）。嘗試告訴您的客戶他們無法升級到Windows12。更糟糕的是，當Windows 12附帶新計算機時，他們無法更換損壞的計算機。