重写或不重写
所以我需要维护这个旧的遗留项目，其中的一部分是令人惊叹地写与Wordpess，许多糟糕的自定义插件，许多鸭子录音的脚本，解决了一个或其他的问题，数据库被设计得非常非常纯粹，也有其他用Zend编写的部分，这与可湿性粉剂的部分，也有这个其他的“杰作”项目连接到第一个项目的数据。主表包含大约150万条记录，也需要进行规范化。现在这个大钉子球“工作”了，而且它也有很多LOC，这是由于糟糕的基础造成的，所以维护它是一个巨大的痛苦。问题是，在我看来，如果不重写，从长远来看，我们正在失去灵活性，因为从技术和业务角度来看，我们都失去了灵活性，而且它开始不能扩展，但重写是一种风险，再加上我们需要将旧数据转换为新的数据结构。黑客的一部分，我想打破这一点，承担风险，并把它做好，但同时我有一种感觉，我的不成熟试图一口太大的一口。你怎么看？
回答 3
Stack Overflow用户
发布于 2012-02-10 05:50:44
在你这种情况下，10次中有9次，我建议重写。理性地说，情况a)不会变好，b)肯定会变得更糟。你应该咬紧牙关，以免为时已晚。
我说的太晚了，我的意思是有些东西完全崩溃了，你不仅必须重写整个东西，而且你的服务也将离线(因此，你可能还会失去用户/客户)。
Stack Overflow用户
发布于 2012-02-10 05:57:40
在像你这样的情况下，10次中有9次人们建议重写，但他们错了。
除非你对系统正在做什么有很好的应用程序级别的知识，否则你将不能成功、快速地重写它。
如果系统现在还在工作，但在很多方面都很糟糕，而且你有管理层的买断(他们拥有软件)来“修复东西”，那么我建议增量方法通常比全面重写要好。
我怀疑数据库给你带来了最多的麻烦，所以这可能是最好的开始。从理解它目前正在解决的问题开始，并将其写下来。如果在软件和数据库(除了jdbc等)之间没有层，则添加一层。一旦存在将db与应用程序分开的层，则将更容易改变db (和层)，同时最小化对应用程序的影响。
在某种程度上，你会对你改变的第一件事感到高兴。在这一点上，修复一些其他部分。重复以上步骤，直到系统变得“更好”。
关于风险:承担风险不是坏事，但粗心大意是可怕的。了解风险并计划缓解风险。
Stack Overflow用户
发布于 2013-09-04 02:03:29
在这种情况下，一个好的策略是像Martin Fowler所描述的那样“扼杀”你的应用程序：
http://martinfowler.com/bliki/StranglerApplication.html
其策略是围绕旧系统的边缘逐渐创建一个新系统，让它在几年内缓慢增长，直到旧系统被扼杀。
我已经使用这种方法扼杀了一个遗留应用程序，取得了很好的效果，而且几乎没有离线时间。
https://stackoverflow.com/questions/9219278
复制相似问题
腾讯云开发者
