永远不要扔掉软件?

乔尔得到的结果是,如果你把所有的东西都扔掉,从头开始,你就扔掉了多年的工作,没有任何保证重写会比你已经拥有的要好得多。

与其专注于重写,不如考虑一次重构一个应用程序的实用性。与其使用内联SQL,不如考虑创建一个新的数据层,也许是基于“更好”的方法,比如LINQ。然后你可以一次一个功能迁移到新的层。以这种方式,您将朝着更好的代码基础的目标前进,而不必放弃多年来的工作。

我的建议是这样的。如果可以,在应用程序的下一个重要版本发布之前,不要弄乱它。然后根据需要进行重构。我们在公司也面临同样的问题,我们通常都是按照我描述的方式来处理问题。

不扔掉旧代码,或坏代码,或不再相关的代码,在我看来,是荒谬的。除非代码中的关键部分不容易复制。

大多数问题都是来自具有内联动态SQL的数据层。

只要UI和数据之间有一些区别,这就不一定是个问题。不要影响内联SQL—只要它是参数化的,它就是一种完全可行的方法。

再问一个问题;我会问 技术原因 因为它报废了。如果你能证明 实际条件 (理想情况下是美元),那就太好了。但不要因为你不喜欢它的样子就这么做。我以前已经废弃了代码,但是尝试以一种无回归的方式来实现它可能会很麻烦。

至于用户,做得对,他们并不需要知道有改变,但即使你想改变UI——大多数人都很灵活,乐于适应新的UI。

与其把所有的东西都扔掉,从头开始,我宁愿一边重构它,一边进行单元测试支持的小修改。从头开始重写的成本很少值得。

我会做必要的插头检查 Working Effectively with Legacy Code 迈克尔·费瑟。他提出了增量重构的有力理由,重点是让遗留代码接受测试。这本书有点过时了,但是,再说一遍,你的代码也是。我发现它非常有帮助,因为它帮助我做出了一个概念上的转变,改变了我处理所谓“布朗菲尔德”项目的方式。如果要求开发商对房屋进行改造,他很少会建议推平结构,从头开始;项目成本太高,而且结构不再使用的时间太长。

我认为像你所描述的软件并没有被严格地抛弃,但可能必须被重构到所有人都无法识别的程度,可能是在第一次编写一系列测试以确保在这个过程中没有任何中断之后。

在那一点上,是不是扔掉了?我会说是的,尽管最终的EXE名称和可见操作可能是相同的。简言之,我认为这可能更多的是语义问题,以及面对现实世界约束时的实用主义,而不是实际的最佳实践。

这正是您希望保留旧版本的情况;)

在你用旧系统的错误复制新系统之前,用户会要求旧应用程序返回。。。许多用户会将一些bug视为一个特性(比如“快速关闭选项”或您遇到的任何怪癖)

当客户对一个产品“满意”时,通常很难为完全重写做一个商业理由。我的建议是在开发新特性时进行重构,以缓慢地移动到所需的体系结构。这通常说起来容易做起来难,但是,对于您描述的项目来说是有意义的。