重用，重寫或重構？

Question

在工作中，我繼承了一個基於PHP的Web站點的開發工作，在最初生成它的顧問之後，他保留下來並沒有留下痕跡。從字面上看，有一半的代碼是從在線教程中剝離出來的，而且有成千上萬的代碼不完整，只有少量的代碼。幾乎沒有任何實際工作。我一直在試圖提取可用的組件，比如佈局（巧妙地與代碼混合），會話管理（用非轉義的，未經驗證的SQL查詢精心調配過的）以及其他一些東西，但是很難全部強制這個垃圾到位。此外，我不會說慣用的PHP，更多的是Perl用戶，我應該在這個項目上主要是爲了維護，所以重寫所有東西似乎只要將現有的怪物摔回原位就好了。

順便說一句，我從來沒有見過像這樣寫得很糟糕的東西。歡迎光臨我與其他人的代碼工作的世界，我想，但我希望這不是這個共同在現實世界中有這樣的寶石，因爲這些：

• // WHY IS THIS NOT WORKING
• // I know this is bad but were going for working stuff right now...
• // This is a PHP code outputing Javascript code outputting HTML...do not go further
• // Not userful

我在尋找我可以在這裏得到最好的建議。如果你在我的職位上，你會怎麼做？

編輯：謝謝大家，爲您的快速和有益的建議！

Answer 1

向您的經理解釋問題，指出除非您刪除代碼中的技術債務，否則支持成本將繼續增加。建議他儘快進行重寫，使用現有系統作爲特徵的模板，即1-1替換爲目標。由於開發時間的很大一部分是要弄清楚你需要做什麼，所以這不應該和原來的一樣長。擁有一個合格的開發人員可能意味着它只需要很短的時間。

讓您的經理完成他的工作 - 計算替代項目的投資回報率 - 並做出決定。

Answer 2

真的這取決於你在看什麼的大小和範圍。

因爲它特別涉及到你的場景，如果工作很簡單，但代碼被破壞，你可能會省下很多時間重寫它。你不會繼承任何傳統的粗俗或糟糕的設計選擇。關於網站，有大量的框架和/或開源解決方案，您可以在不花費大量精力的情況下映射現有網站。

看看上面的代碼示例，看起來它可能也值得將代碼段提交給dailywtf.com。 ;）

Answer 3

維護代碼。這很糟糕，但是你在這個行業中的時間越長（並且被維護的時間越長），越是認識到寶石並不是你所見過的最糟糕的東西......

只要學會與你擁有的東西一起工作，並儘可能提供更多的好處。當然，如果您真的對代碼進行了深入評估，並且仍然得出結論，您可以從頭開始編寫代碼而不是修復代碼，那麼請提供（計劃出的）時間表給您的老闆，看看它的發展方向。

Answer 4

我想大家都知道這裏沒有簡單的答案，處理遺留代碼是我們行業中最令人沮喪的事情之一，但我們大多數人都必須經常處理。在進一步研究之前，我會建議您確保您瞭解項目的確切範圍，將其分解爲必須擁有和設想的項目。然後，您可以首先更密切地關注最重要的領域。就重用/重構/重寫等方面的選擇而言，這將取決於代碼的糟糕程度以及代碼的未來需求。

Answer 5

向您的客戶解釋，以前的顧問可能已經過頭了。代碼不可管理，需要重寫。如果你想解開這個混亂的問題，那麼解釋一下，成本將不止是從頭開始重寫。我不得不這樣做。大部分時間重寫都比較容易。

Answer 6

因爲我在一個成熟的傳統環境中工作，所以我不喜歡重構/重構的重構。看到源代碼歷史中的「變化」比查看漂亮的代碼更重要。我們的大部分更改都與bug報告或批准的「更改請求」綁定在一起，形式要求也是如此。但是我在這裏談論的是基本上可以工作的代碼，而不是你自己的代碼。因此，在你的情況下，當處理目前不符合要求的代碼（任何需求，過去或現在）時，我會說繼續並重寫。

Answer 7

每個人都會隨時繼承不良的代碼。

你在這裏得到的是我過去見過的一個相當經典的例子（我實際上看到的更糟糕）。雖然我可以理解重寫的願望（事實上，如果所有的代碼都不好，你應該認真考慮這個選項） - 你的經理可能不會那麼做，或者至少不會立即。

無論採用哪種方式，您都需要處理一段時間。我會盡可能清理，或者 - 如果這是面向客戶的 - 推動安全問題。如果代碼和我發佈的代碼一樣糟糕，那麼它可能會散佈諸如SQL注入，以及少量的CSRF和XSS。因此，如果您將其用於需要安全的任何事情，那麼您可以爲「改進」提供一個好的案例。