IRONSOFTWAREHOME

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

Never rewrite code?

Derek Comartin

7m 01s

重寫舊有程式碼是許多開發者面臨的兩難困境,特別是在一些長期存在的專案中,那些專案可能顯得笨拙、過時,或者無法擴展。 從零開始建構一個現代且容易維護的系統是令人嚮往的。 但這是正確的選擇嗎?

在本文中,我們將探討用C#重寫舊系統的複雜性,這是在Derek Comartin的影片"Never Rewrite Code?"中詳細解釋的,您可以在他CodeOpinion.com的YouTube頻道上觀看該影片。 Derek將個人經驗和社群智慧帶入這個話題,提供了一種紮實的觀點,許多開發者和技術決策者會欣賞。

"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更多的內容。

Earn More by Sharing What You Love

Do you create content for developers working with .NET, C#, Java, Python, or Node.js? Turn your expertise into extra income!

Let's Stay in Touch!

Join our newsletter, you’ll get exclusive access on article updates. We value your privacy

Key in blue circle

立即免費取得 30 天試用金鑰

Your trial license will be sent to your email address

無任何限制。100% 解鎖。無需信用卡。

OR
bullet_checked無需信用卡或建立帳號無任何限制。100% 解鎖。無需信用卡。
  • Logo Aetna
  • Logo NASA
  • Logo GE
  • Logo Porsche
  • Logo USDA
  • Logo Qatar
Join Millions of Engineers who’ve tried Iron Suite
獲取您的無義務諮詢
填寫以下表格或發送電子郵件至sales@ironsoftware.com
您的詳細資訊將始終保密。
被全球數百萬工程師信任
Iron Software的客戶標誌
立即獲取您的30天試用金鑰
無需信用卡或帳戶建立