比方說，我有一個較老的系統/框架，顯示它的年齡有點，但很快就會被用來做超過它最初的意圖。這是一個網絡應用程序，它沒有太多的常見代碼隱藏，所以我建議從長遠來看，使用更具前瞻性的代碼來重建它的工作量會更少，並且着眼於減少維護工作（我已經擁有了一段時間的遺留系統，並相信這是真實的）。請記住，遺留系統的體系結構最終需要大量的故障排除和TLC：如果它工作，我不在乎它「不美觀」或書寫「正確」，但它不會「正常工作」它現在是。在成功使用類似的系統之前，我已經完成了重寫，如果我正確地提出它，它看起來像是我開放的權力。從零開始重寫系統：你在提案中包含了什麼？
所以，現在是由我來出售這個想法。我提到的以前的系統，我成功地重寫過，沒有什麼正式的，有點像我的業餘時間，但是如果我在重寫中花費一些預先準備時間，這會對項目時間表產生直接影響。這意味着我更瞭解我的東西。由於之前沒有正式的完全重寫，我想要關於如何推介它的想法。
立即我需要重新確定重寫的範圍，但是之後它很模糊。在重寫之後，有數字可以證明維護成本和節省量，但這很難估計。還要別的嗎？
我已經多次成功地投入了這個球場，這是我的總體戰略。這是基於我們的企業文化，在技術使用方面比我們業務領域的其他企業更爲先進，但我相信這些戰略幾乎可以在任何地方運作。
首先，您需要讓他們瞭解公司的需求和經濟效益。如果沒有，請不要打擾。如果你能拿出具體的數字，就這樣做。如果沒有，請給出您的最佳估計，並告訴他們這是一個估計。如果這個數字是一個完全未知的數字，試着從可能知道的人那裏找出數字是什麼。那麼這就是我使用的一般音調格式。
首先，我介紹一下程序的功能以及它對我們公司的好處。指出它如何節省資金，或給你一個競爭優勢。讓他們看到這個系統對我們的成功至關重要。
二，經歷問題。描述這些問題如何影響業務，而不是如何影響你作爲維護程序員。
一定要包括任何最終用戶的痛苦。 （例如，他們需要等待系統修復並且他們的生產率下降，否則我們可能會錯過機會，或者他們需要手動計算數字，這需要時間並且浪費勞動力。）
如果你可以誠實地說，重寫需要多長時間才能完成，你需要證明你每月/每週/每期/每次花費x小時，這需要花這麼多時間來重新編寫，寫。
如果重新編寫所花費的時間比您在故障排除上花費的時間要長，請確保包含發生問題時浪費的時間。
基本上，你需要考慮底線。底線不僅僅是金錢。這也是爲了提供比競爭對手更好的機會（這就是爲什麼公司首先花在IT上的原因 - 保持或比其他公司更好。）
編輯
而且也，不僞造，以包括可以通過升級來做出的改進，以及如何給公司的優勢，以及。
誰在使用網絡應用？獲得他們對重寫的支持，或者當某些事情沒有完全解決時你可能會遇到麻煩（「你爲什麼改變它？現在比以前更糟糕了！」）一個好辦法是問問他們想要什麼等待修復。確保他們爲新系統的痛苦得到一些東西。
估計需要多長時間才能修復當前系統中的錯誤，並將其置於您的估計數量旁邊以重寫它。說實話。
檢查您過去花了多少小時來解決問題。清楚說明你會把這個數字下來。
請確保您必須從頭開始重寫所有內容。通常，通過重構和大量單元測試來逐步遷移現有代碼會更安全，更簡單。
如果您想避免在遇到任何問題時獨處，請讓公司的重要人員支持這個。尋找一位決策者，一個更高層的人，一個聲音有點重量的人。
許多公司寧願繼續修補的東西是工作，即使維護成本高，比一個危險的改寫前進。特別是如果該功能對業務至關重要。
雖然您有機會添加主要功能，並且可以將其作爲不改變爲重寫的風險。
但是，在展示您的產品之前，您可能只需要進入「工作原型」實現。提供遷移計劃和兼容性測試計劃。
如果在下一年重寫總共需要6個月，那麼請確保節省的成本大於保留現有系統的成本。許多人不會在意節省是否僅在三年或更長時間內實現。
我們改寫了系統，但是它們是系統，每年的許可成本都是業務的核心。六個月的重寫和兩天/每月的維護是一件容易的事情，不用介意其他的好處，比如大幅提高系統的準確性（導致需要指導老系統的人員的冗餘）。總而言之，節省的資金幫助公司在最近的低迷時期更加活躍，並將爲我們帶來前所未有的競爭優勢。