我爲一個非常小的公司（約70人總共有10名實際程序員）工作，並且需要一些比較大的（C++中的1M LOC）應用程序，這需要一些嚴重的TLC。由於公司的規模，我們主要是通過我們可以向客戶出售的東西來驅動的，除了修復導致事情失敗的錯誤外，沒有時間維護代碼，而不是始終修復它們。顯然這是該公司過去10年來的工作方式！如何向管理層出售「良好的代碼」的好處？
我該如何說服管理層，他們所做的實際上是在花費他們的錢/時間/生產力？存在哪些主動維護策略？對於資源稀缺的小公司來說，哪些好？
「技術債務」（或「工程債務」）的概念對商人有意義。解釋一下，無論你什麼時候做一些快速而又骯髒的事情，你都會招致「債務」，因此你在以後每次做出改變時都要支付「利息」。這就是爲什麼，例如，在表單中添加一個小字段可能需要四周的時間來處理債務纏身的代碼庫。
然後解釋一下，您可以通過重構（或任何您想要用於清理的期限）來償還債務，然後持續的利息支出將會減少。
很明顯，像任何比喻或類比它可能會變得緊張，但通過使用商業/金融術語，它可能比programmerese更有效地搔動腦筋。
基本上：更好的代碼=更少的維護。少維護=開發人員有更多時間來開發新功能。新功能=更多收入。
另外：更好的代碼=新開發人員的學習曲線更低。
我發現只有三種方式出讓的維護管理：
簡而言之：管理會談中的功能，而不是代碼。
我的經驗是，銷售「清理代碼庫」項目總是會失敗。我建議採取以下方法之一：
1.開始分配時間進行小規模維護以及將來的所有工作。您可以使用這樣的論據，只要您將功能添加到現有模塊，您就可以在當時更熟悉的情況下對其進行改進。一定要表現出隨着時間的推移而改進的好處，並且它在更長時間內更便宜的「清潔代碼庫」項目。
2.開始分配時間進行小維護以及所有未來的工作，但不告訴任何人。如果有人着迷，只要告訴他們你需要重構相關模塊以完成你添加的功能。
在我所有這些年裏，每次我試圖告訴管理人員和團隊負責人我們正在使用的代碼很爛，我收到了很多反彈。 （我沒有使用這些工作。）不用說，你們的公司正在賺錢，而且在他們眼中，如果它沒有破產，就不要修理它。而且，你可能會讓事情變得更糟。
但是，我確實設法通過等待機會來重寫某些東西。需要添加一些新功能，並且代碼在幾年內被忽略，甚至幾乎沒有編譯。我把它賣給了我的團隊負責人和經理，因爲未來增加更多的東西將會是一個更好的投資回報。也就是說，我改寫這個東西的速度更快，並增加了他們的新功能，而不是找出那個老東西是如何工作並在那裏解決問題的。
「，甚至幾乎沒有編譯」 我不知道這是一個程度問題。 – PeterAllenWebb 2008-10-02 17:53:37
使用他們最喜歡的「範式」之一：大圖片
這是一個大多數人都理解的術語，因爲他們都將自己視爲「大圖片」類型的人。承認該做的事情錯誤的方式可以，在某些情況下，賺更多的錢在短期內點，但在長期（或「大圖」），它的成本維護，銷售和重新部署不好的代碼，這將是值得的空中工作時間正確的。
ie：「你需要看看'大圖片'，看到我們通過錯誤的方式來損失金錢：
你通常不能說服他們進行簡單的討論。該作品是「秀」他們寫乾淨有據可查的代碼（可能通過重構爲你修復bug小塊），並追蹤了多長時間開發商在「乾淨」與「亂」代碼來解決新的bug。
這就需要一個好的bug跟蹤系統，雖然包括工作時間等條目，你其實可以減少的圖表前，在「缺陷修復」的時間和或減少在「新的錯誤」清理代碼模塊。
鋤頭肯定是漫長的道路。 :-)
你能證明支持成本在上升嗎？無論是支持事件的數量，還是開發者花費在支持上的時間百分比。
嘗試確定可以改進事物的可管理重構，然後顯示如何避免最近的錯誤。
總有將是之間需要做，以保持新的銷售流向VS需要做長期提高軟件的「基礎設施」什麼什麼困難的張力。證明短期內從「基礎設施」工作獲得的回報是將其納入管理層的最簡單方式。
不知道更多關於公司的信息，我最好的猜測是沒有什麼可以做的。
你說的方式他們甚至不知道他們有問題，更不用說尋求解決問題。他們很可能會把你看作是在尋找一個他們認爲不存在的問題的人。
十年的「經驗」是一個很大的戰鬥。從他們的觀點來看，他們有一個產品，它的工作原理，肯定有麻煩，不斷維護和客戶問題，但沒有人可以與結果爭論？他們可以嗎？另外，每個人都有這些問題的權利？
也許你將有更多的運氣比我，但在不到他們正在尋找它，我不認爲你永遠不會讓他們看到它。
您可能希望考慮貴公司的優先級不利於產生恆星代碼。
如果不是的話，那麼提出具體建議，並銷售基於具體的設想好壞你的建議，因爲它們反映了組織的目標。
首先，我會建議看看你是否可以做到雙贏。由此，找出軟件不能滿足公司需求的差距（例如，它是否限制了業務種類，或員工是否有很多複式項目，或者管理層缺乏良好的報告） - 並且與它進行系統檢修。
成本覈算的錢在許多方面：可操作數據的
1）缺乏。如果報告緩慢（不再有效）或不準確或不存在，這是管理者最有意義的一個領域。 2）如果人工輸入或重複輸入正在發生並且可能被自動化，那麼確定有多少員工受其影響，他們多頻繁，並且對公司的成本感到擔憂。然後你可以得出損失爲總和（對於每個人）的時間損失*人的成本。
3）確定機會成本的區域 - 例如，工作人員或管理層是有限的。發現客戶不滿意並且由於系統缺乏靈活性而未能返回的情況。
按照它如何幫助實現業務目標銷售它。
不要說「如果我們這樣做，這意味着一旦我們發現一個錯誤，我們可以更快地管理它」 相反，把它放在一個角度來看，那些不真正關心技術方面的人會理解和理解。比如說「如果我們這樣做，我們就能夠增加整體收入並提供更好的產品」。
如果你能做到這一點，這意味着做出更大決定的人通常會更容易接受。
開發人員編寫代碼而不是管理員。我確信你的管理員從來沒有告訴開發人員去編寫垃圾代碼。我認爲您需要說服其他9位開發人員，所有編寫的新代碼都需要滿足更高質量的要求。
我懷疑你永遠不會拿經理人協議離開並重寫大塊代碼，因爲你認爲質量很糟糕，但是，你應該能夠削減你的同事開發人員，至少讓他們在正確的道路。
在其他開發人員的支持下，您可能會說服管理人員分配空閒時間進行清理。
我發現Technical Debt比喻非常有用，當試圖說非技術人士投入資金來支持代碼庫的改進。其基本思想是通過讓代碼質量受損而產生更多的功能就像獲得貸款以利用機會：你可以做到這一點，但是如果你永遠不會償還貸款，你將會被利益所掩蓋。同樣，如果您從不修復質量問題，那麼您的進度將越來越少，直到應用程序必須被丟棄的程度爲止
這取決於您的店鋪所在的商業模式。如果您正在製作下一個大型視頻遊戲，下一個大型IDE或某個公司的下一個大型CRM系統，可以通過不同的方式評估清理代碼庫的優點。
我只是做了業務的發展，所以我不能給任何其他的商業模式證明代碼清理說話，但在這裏是我的$ 0.02的服務發展：
如果你是做業務的發展對於一些外部公司，出售清理工作非常困難。 「你的意思是你爲我們寫了糟糕的代碼？現在你想要更多的錢來清理它？」這是一個沒有商店想要回答的問題。作爲開發人員，我們並不總是意識到我們的時間花費了多少時間，而且他們非常專注於將成本與直接商業價值掛鉤。
因此，我喜歡在這種情況下完成代碼清理的一種方式是將清理描述爲某些更改順序或功能請求的「先決條件修改」。這允許企業將清理成本與某些直接價值聯繫起來，這是變化或功能，並允許他們使用他們熟悉的常見成本效益分析。這會讓你花時間去做一些清理工作，但要注意範圍。當你有一週的時間清理時，打開蠕蟲的罐頭可能是有風險的事情。您的建議可能沒有說：「我們將重新編寫應用程序，然後實施您的功能。」與客戶做一些風險和期望管理，保持誠實和道德。
也許別人能回答這個在軟件開發的不同的商業模式......
機會是他們瞭解權衡和正在接受的風險。我認爲隨着你的進行重新考慮的建議可能是你唯一的希望。
如果他們是一個小公司，如你所建議的那樣，他們會比留下漂亮的代碼更有興趣留在商業中。另外60個沒有開發者可能有類似的抱怨（我希望資產負債表/現金流量報告/預算/營銷預算/銷售線索/停車場更好）。每個人都有能力決定真實的人的工作和生活（包括提問者）將最終在今天結束。當你是一個小企業時，這是正確的。
如果你真的很幸運，你會在董事會會議室找到一個有同情心的技術耳朵，所以至少你有一個懂得你的痛苦的人，並且可以讓你有足夠的空間將一些非常糟糕的代碼作爲一面項目或重大錯誤發佈期間。那個人可能不需要很多說服力。你可能想要做
另一個想法...
事情是保持細緻的bug統計資料，每個代碼組件組織。通過這種方式，您可以證明或反駁代碼庫中缺乏質量會導致交付產品中出現更多錯誤的情況。如果您發現特定組件每月報告的bug數量穩步增加，您可以將其放在一個圖表上，並讓它在未來繼續增長，向管理層證明最終您的團隊中有一半會忙於維護那一個組件。
如果您每週或每個月發出一個錯誤統計報告，這也將幫助您的團隊，因爲您將不得不分析導致錯誤更改的原因並採取相應措施。
有時使用比喻可以幫助非技術人員瞭解。
爲什麼代碼重構，維護等是重要的最好的比喻我發現這是一個。它是從一個post採取Slashdot：
每個人都拋出一個大的晚宴 ，然後離開了菜幾 天。或者更糟的是，曾經有一個室友 。原來這很糟糕，因爲 如果你只是想讓自己早餐一點兒 ，那麼就很難 做飯。你必須將平底鍋和 芯片從平板上取下才能開始。 而烹飪是兩倍的工作 因爲你必須轉移混亂 只是爲了得到櫃檯，然後 然後再次轉移到 爐竈。
然後，當你做，你肯定不 要正確地洗了;水槽的 已經充滿了菜餚。所以你 只是在 的頂部折騰你的菜，說你會在「稍後」 。當然，不斷增長的 丘的模糊菜是代碼 基地一半我見過的 真實世界的比喻。和巨大的 重寫這將不可避免地重蹈是 像推倒你的廚房和 建立一個新的，因爲這是擺脫困境的 最便宜的方式。
相反，好廚師工作乾淨。他們 乾淨，因爲他們去。總是。不是因爲 他們緊張的怪胎，而是因爲如果 他們不這樣做，亂減慢下來 ，使他們更模糊，最終導致 在一個巨大的clusterfuck，與 所有的同事，他們大喊大叫。
我懷疑你的老闆永遠不會明白如何幹淨的代碼將獲得你的公司更多的錢，除非你所在的公司中，高層管理人員積極參加了許多不同大小的軟件公司擔任程序員工作的真正性質。不要打擾他們給程序員的理由，公正就不會理解。相反，你必須給他們結果。
我的建議是要找到一個項目，就是小到不足以被遺留代碼完全負擔，並選擇您認爲方法將幫助清理您的系統，並就去做。跟蹤您的更改，記錄過程中的差異如何改善，然後在系統中傳輸結果時監控結果。最後，如果您實際上對代碼行做出了積極的貢獻，並且您的貢獻通常會在您的同事嘗試不通過的情況下順利通過測試，那麼人們會傾聽您的意見。
一旦他們看到解決方案的好處，他們會更加關注問題。
更好的代碼更容易維護，但更重要的是，它也更容易維護除原作者以外的其他人。
編碼標準使開發人員能夠更「互換」 - 這有利於開發商在產品上的英雄程序員很少被准予曾經去別的工作。
我去過那裏 - 你覺得真的需要和業務的重要一年左右的時間，但很快就開始疑惑，爲什麼你總是錯過了晉升，從不對有趣的新東西的工作。
作爲一家企業，您希望獲得靈活性和安全性 - 如果您的明星開發人員贏得彩票或者最終決定他在同一件事情上工作五年，他想繼續工作。如果有大的機會進入，您希望能夠快速擴展。
寫得很好，經過充分評論，符合標準且經過單元測試的代碼花費更多，但對業務價值更高。
任何企業的經理是否都希望在一個開發人員或小團隊中長期保持成功？如果是的話（他們是瘋了嗎？）然後爭辯說，開發每2 - 5年移動公司，他們的技能集100％可轉讓。
您的10年舊代碼庫可能需要幾個月的時間才能讓新開發者貢獻任何東西。每當你失去一個開發者時，你實際上已經失去了六個月的時間（更不用說招聘了）。如果你的團隊很孤立，你可能會失去更多的東西，因爲所有其他人都需要花費數週的時間來解決離職者代碼中的小問題，因爲他們不知道它是如何工作的。
對於如何構建沒有這些問題的新項目（我自己使用自定義的Agile變體），有許多研究涉及到變化中流。
TLC？可能是溫柔的愛與關懷;另見http://www.urbandictionary.com/define.php?term=tlc – 2008-10-02 18:09:37
這個問題是無題的，因爲它不在適合本網站的問題範圍內，如[我可以問什麼主題這裏？]（http://stackoverflow.com/help/on-topic）另請參閱：[我應該避免問什麼類型的問題？]（http://stackoverflow.com/help/dont-ask）能夠在[另一個Stack Exchange站點]（http://stackexchange.com/sites#name）上獲得幫助，例如[pm.se]或[softwareengineering.se]。 – Makyen 2017-08-18 23:24:26