您应该用 C# 重写遗留代码吗？深入了解 Derek Comartin 的观点

重写遗留代码是许多开发人员面临的难题，尤其是在那些感觉笨拙、过时或无法扩展的长期项目中。 梦想着从头开始，一尘不染地构建一个现代化的、可维护的系统，这很有诱惑力。 但这样做对吗？

在本文中，我们将探索用 C# 重写传统系统的复杂性，这是 Derek Comartin 在他的视频中"Never Rewrite Code?"在他的CodeOpinion.com YouTube 频道上详尽解释的。 Derek 将个人经验和社区智慧融入到该主题中，为许多开发人员和技术决策者提供了接地气的观点。

"绝不重写代码 "原则

Derek 开宗明义地指出了软件开发中长期存在的常见建议：Never rewrite code from scratch. 这一观点源自 Joel Spolsky 的一篇著名博文《Things You Should Never Do》，其中强烈警告不要重写遗留系统。

在 0:32 分，Derek 指出了 Spolsky 文章中最关键的观点：

"他们犯了任何软件公司都可能犯的最严重的战略错误：他们决定从头开始重写代码。

Derek 解释说，主要的启示是：当从头开始时，没有理由相信你一定会比第一次做得更好。特别是在大型复杂系统中，很容易低估当前实施中蕴含的隐藏价值。

简单的错觉

在 1:07 处，Derek 回忆了他作为初级开发人员的早期经历。 像其他许多人一样，他经常想重写系统的大部分内容，原因仅仅是他认为代码不好。 但他后来意识到，这种想法往往源于对代码的不理解，而不是因为代码本身本身不好。

他分享了一个贴近生活的事实：

"从头开始做一件新鲜的事情比真正深入代码库、了解所有复杂性和边缘案例要容易得多--这真的很困难"。

从本质上讲，看起来像 "轮胎着火 "的东西可能只是多年演化和修补过程中被误解的逻辑。 开发人员经常会将不熟悉与糟糕的设计混为一谈。

什么情况下重写是合理的

尽管如此，Derek 并没有说重写总是不好的。 在 1:44 左右，他开始介绍细微差别。 对于在同一代码库中扎根多年、了解所有领域复杂性和系统限制的团队来说，重写可能是一个有效的选择。

"如果您在一个系统中工作了很长时间... 这就是细微之处。 你可以说，是的，这东西是个轮胎火，阻碍了我们的发展。 也许应该重写 "。

"差就是好 "和 80/20 规则

Derek 在 2:01 介绍了 "Worse Is Better "的概念，并将其与帕累托原则（80/20 规则）联系起来。 他认为，通常情况下，系统 80% 的价值仅来自于 20% 的代码库。 因此，在重写时，目标不应是复制所有内容，而应专注于真正有价值的核心内容。

"在某种程度上，功能越少越好。

他解释说，简洁性和实用性往往胜过完整性。 一个有限但可用、可维护的系统可能比一个庞大但难以维护的传统平台更好。

评估成本与收益

2:47 时，Derek 建议最终的决定往往取决于成本效益分析。 绝不能为了改写而改写。 但是，如果维护旧代码或受限于旧技术的成本高于重建成本，那么等式可能会转向重写。

他提到了由于使用过时的平台或工具而导致竞争优势受阻的情况。 在这种情况下，技术差距本身就成为重建的正当理由。

Greg Young 的一堂课

德里克提到了格雷格-扬在 3:12 发表的一篇精彩文章，他在文章中重写了一个意外进入生产阶段的原型。 重写工作耗时 9 个月。 结果如何？

"经过九个月漂亮的架构和代码工作，我们每月大约能多赚 1 万美元。

格雷格总结说，与其投入巨资重建那个原型，还不如建立 30 个新原型来测试新策略。 Derek 喜欢这个结论，因为它挑战了 "技术完美是我们的目标 "这一假设。

有时候，"足够好 "的软件才是赢家--尤其是当它已经带来商业价值的时候。

"新旧 "之争

在 4:20 分，Derek 谈到了 "旧的就是坏的，新的就是好的 "这一普遍心态。 他举了一个亲身经历的例子：他集成了两个具有相同用途的第三方服务。 其中一个工具使用现代 JSON，很可能是用 Python 构建的。 另一个令人惊讶的是，它返回的是 XML，可能是在 20 世纪 90 年代用 ColdFusion 制作的。

"它们都是等价的。 它们很稳定。 它们为我和我的客户提供了相同的价值 "。

这凸显了 "新 "并不总是 "好"。 稳定性、可靠性和实用性往往比技术堆栈重要得多。

Derek 的个人重写经历

最后，Derek 在 5:31 分享了他自己的故事。他在原系统领域工作了六年多，之后参与了大规模的重写工作。 重写工作耗时约 14 个月，主要原因是技术差距限制了系统与现代电子商务工具和在线服务集成的能力。

"我们确实必须为此重建一些新的东西。

这不仅仅是一个 "糟糕代码 "的案例--系统从根本上无法发展，因此重建是唯一可行的途径。

最后的想法

在视频的最后，大约 6:11 左右，Derek 强调答案不是简单的 "是 "或 "否"。

"我不认为明确的答案是否定的。我认为在做出这一决定时应该谨慎，因为上下文很重要，而且有很多细微差别。

重写传统的 C# 代码可能是必要的，但只有在上下文、领域知识、价值交付和技术限制都支持这一决定的情况下才有必要。

结论

Derek Comartin 的视频以平衡、经验为导向的方式探讨了软件开发中最受争议的话题之一：您是否应该重写遗留代码？ 他的建议不是教条式的，而是深思熟虑、脚踏实地，并蕴含着丰富的个人见解。

通过对历史教训、现实故事和 "新的就是好的 "陷阱的反思，Derek 帮助读者建立一个成熟的框架，以做出软件架构中最重要的决策之一。

如果您在自己的 C# 项目中面临类似的选择，请重温 Derek 的视频并仔细权衡上下文。 有时，遗留代码并不是敌人，它只是被误解了。

在 Derek 的YouTube 频道上观看更多有深度的视频。 请访问 CodeOpinion.com 了解 Derek 的更多内容。