您是否應該重寫C#中的Legacy程式碼？深入探討Derek Comartin的觀點

"Never Rewrite Code" 原則

Derek以一項在軟體開發中經常給出的長期建議開場：永遠不要從頭重寫程式碼。這種觀點來自於Joel Spolsky著名的部落格文章"Things You Should Never Do"，該文章強烈警告不要重寫舊系統。

在0:32時，Derek指出了Spolsky文章中最關鍵的想法：

"他們犯了任何軟體公司可能犯的最嚴重的戰略錯誤：他們決定從頭重寫程式碼。"

Derek 解釋說，這裡的主要啟示是：從頭開始時，沒有理由相信您一定會比第一次做得更好。尤其在大型複雜系統中，容易低估當前實現中隱藏的價值。

簡單的錯覺

在1:07時，Derek回顧了他作為初級開發者的早期日子。 像許多其他人一樣，他經常想重寫系統的大部分，僅僅因為他認為程式碼差勁。 但他後來意識到，這種信念常常來自於不理解程式碼，而不是因為程式碼本身固有的劣質。

他分享了一個大家都能理解的真相：

"從頭開始新項目比真正深入研究、進入程式碼庫、理解所有的複雜性和邊緣情況要容易得多——這真的很困難。"

實質上，看起來像是"火災現場"的東西可能只是誤解的邏輯，隱藏在多年來的演變和補丁中。 開發者經常將不熟悉錯誤地看作是設計不良。

重寫可能有正當理由的時候

不過，Derek並不認為重寫總是錯的。 大約在1:44，他開始引入細微差別。 對於已經在同一程式碼庫中沉浸多年、了解所有領域的複雜性和系統限制的團隊來說——重寫可能是一個有效的選擇。

"如果你在一個系統中呆了很長時間... 這就是細微差別的來源。 您可以說，是的，這個東西是一場火災，並讓我們無法前進。 也許重寫是恰當的。"

"更差就是更好" 和 80/20 法則

在2:01時，Derek介紹了"更差就是更好"這個概念，並將其與帕累托原則（80/20法則）聯繫起來。 他認為，通常系統80%的價值來自僅僅20%的程式碼庫。 所以，當重寫時，目標不應該是全部重現，而是專注於真正提供價值的核心。

"有一點是功能較少——更差——是更可取的選擇。"

他解釋說，簡單性和實用性通常超越完整性。 限製而可用和容易維護的系統可能比廣大但難以維護的舊平台更好。

評估成本與效益

在2:47時，Derek建議最終決定往往歸結為成本效益分析。 為重寫而重寫是沒有道理的。 但如果維護舊程式碼或受限於舊技術的成本超過了重建，那麼方程可能會傾向於重寫。

他提到，在一些情況下，因為您被困在過時的平台或工具上而削減了競爭優勢。 在這些情況中，技術差距本身就成為重建的合理原因。

從Greg Young的教訓

Derek在3:12提到了一篇由Greg Young發表的精彩文章，其中一個意外進入生產環境的原型被重寫。 重寫花了9個月。 結果如何？

"在我們九個月的美麗架構和程式碼工作之後，我們每月大約多賺取10,000美元。"

Greg總結說，與其在重建那個項目上投入大量資金，不如構建30個新原型來測試新策略更好。 Derek喜愛這個結論，因為它挑戰了技術完美總是目標的假設。

有時，"足夠好"的軟體勝出——特別是當它已經在提供業務價值時。

"舊與新"的偏見

在4:20，Derek談到常見的思維方式，即舊不如新。 他給了一個個人例子：他整合了兩個第三方服務，這兩個服務提供相同的功能。 一個使用現代JSON，可能是用Python建的。 另一個讓人驚訝的是，返回XML，可能是1990年代用ColdFusion建的。

"它們都是等效的。 它們很穩定。 它們為我和我的客戶提供相同的價值。"

這強調了新不一定好。 穩定性、可靠性和實用性通常比技術框架更重要。

Derek的個人重寫經歷

最終在5:31處，Derek分享了他自己的故事。在在原系統的領域中工作了六年多後，他參與了一個大規模重寫。 重寫大約花了14個月，主要是由於技術差距，限制造成系統無法與現代電子商務工具和線上服務整合。

"我們真的需要為這個目的重建一些新東西。"

這不僅僅是"壞程式碼"的問題——系統根本無法演變，所以重建是唯一可行的道路。

最後的想法

影片結尾在6:11左右，Derek強調答案不僅僅是"是"或"否"。

"我不認為答案是簡單的否定。我認為您在做出這個決定時應該謹慎，因為上下文很重要，這裡面有很多細微的不同。"

用C#重寫舊程式碼可能是必要的——但只有在當上下文、領域知識、價值傳遞和技術限制都支持這個決定時。

結論

Derek Comartin的影片是對於軟體開發中最有爭議話題之一的平衡、基於經驗的探討：您應該重寫舊程式碼嗎？ 他的建議不教條——而是考慮周到、基於事實，並富含個人見解。

藉由反思歷史教訓、現實世界故事以及"新就是好"的陷阱，Derek幫助觀眾發展出成熟的框架，以做出軟體架構中最具結果性的決定之一。

如果您在自己的C#專案中面臨類似選擇，請重新觀看Derek的影片並仔細權衡您的上下文。 有時，舊程式碼並非敵人——它只是被誤解了。

在Derek的YouTube頻道上觀看更多有見地的影片。 前往 CodeOpinion.com 查看Derek更多的內容。