扔掉软件永远不会好吗？
Joel得出结论，公司永远不应该抛弃软件。
我努力成为一个优秀的小程序员并遵循这个规则。我参加了一个由一个人经营的五年历史的项目。它充满了反模式，通常设计不佳。大多数问题都来自使用内联动态 SQL 的数据层。
我可以重新收集需求并使用 OO、设计模式和现代 .NET 技术构建这个应用程序。易于管理和团队合作。
在小型应用程序中，遇到诸如此类的问题，我们应该听从 Joel 的建议吗？
这个问题可能会因为主观而被抛出，但我发现这对我作为程序员的工作至关重要。
乔尔的意思是，如果你把所有东西都扔掉，从头开始，你就是在扔掉多年的工作，却无法保证重写会比你已经拥有的要好得多。
与其专注于重写，不如考虑一次重构一个应用程序的实用性。代替内联 SQL，也许考虑创建一个新的数据层，也许基于“更好”的方法，例如 LINQ。然后，您可以一次迁移到新的第一层功能。通过这种方式，您将朝着更好的代码库的目标前进，而不必放弃多年以前的工作。
我的建议是这样的。如果它有效，请不要乱用它，直到您的应用程序中的下一个重要版本。然后在你认为必要的时候重构。我们在公司面临同样的事情，我们通常按照我描述的方式处理问题。
不丢弃旧代码、坏代码或不再相关的代码，IMO 是荒谬的。除非代码具有根本无法轻易复制的关键部分。
大多数问题都来自使用内联动态 SQL 的数据层。
只要 UI 和数据之间存在一些区别，这不一定是问题。不要对内联 SQL 产生偏见——只要它是参数化的，它就是一种完全可行的方法。
重新提出问题；我会质疑废弃它的技术原因是什么。如果你能以实际价值（最好是 $£€¥）证明它的合理性，那就太好了。但不要仅仅因为你不喜欢它的外观而这样做。我之前已经废弃了代码，但是尝试以无回归的方式进行操作可能会很曲折。
至于用户；如果做得对，他们并不真的需要知道有变化，但即使你想改变 UI - 大多数人都非常灵活并且乐于适应新的 UI。
我不会把所有东西都扔掉并从头开始，我会在进行时对其进行重构，进行单元测试支持的小改动。从头开始重写它的成本很少值得。
我将制作强制性插件以查看Michael Feathers 的有效使用遗留代码。他为渐进式重构提出了强有力的理由，重点是让遗留代码得到测试。这本书有点过时了，但是你的代码也是如此。我发现它非常有帮助，因为它帮助我做出了概念上的转变，改变了我处理所谓的“棕地”项目的方式。如果开发商被要求改造房屋，他很少会建议推平结构并从头开始；该项目将过于昂贵，并且该结构不再可用的时间太长。
我认为像您描述的软件并没有严格地丢弃，但可能必须重构得面目全非，可能是在首先编写一堆测试以确保在此过程中没有任何中断之后。
那个时候，是扔还是不扔？我会说是的，尽管最终的 EXE 名称和可见操作可能是相同的。简而言之，我认为这可能更多的是语义问题，以及面对现实世界的限制时的实用主义问题，而不是实际的最佳实践。
这正是您想要保留旧版本的情况；）
除非您复制具有旧系统确切错误的新系统，否则用户会要求恢复旧应用程序......许多用户会将一些错误视为一项功能（例如“快速关闭选项”或您遇到的任何怪癖）
当客户对产品“满意”时，通常很难为完全重写提供商业理由。我的建议是在开发新功能时进行重构，以慢慢迁移到所需的架构。这通常说起来容易做起来难，但是对于您描述的项目来说很有意义。