我刚刚完成了过去几个月的项目工作。它在线并准备好了。客户现在回来了或多或少完全重写了应用程序的大多数部分。已经起草了一份新合同，并为所涉及的额外工作付款。
我想知道开始改造整个事情的最佳方法是什么。你会做的第一件事是什么？你会如何改变设计，以确保你所改变的东西不会破坏其他东西？
简而言之，您如何有效地解决激烈的应用程序设计变更（数据库和代码）？
答案 0 :(得分：4)
假设您已经进行了单元测试，这只是重构。
如果您没有进行单元测试，那么
为您可能保留的部分编写单元测试。
为您要更改的部分编写单元测试。
运行测试。 “保持”应该通过。 “改变”应该失败。
开始重构，直到测试通过。
答案 1 :(得分：3)
这在软件中并不是新事物，人们已经这样做并写了很多关于此的内容。
尝试阅读
这里解释的技术对于维持任何类型的长期IT项目非常宝贵。
答案 2 :(得分：1)
如果变化剧烈，那么最好重新开始。我参与了一些经历了一些重大变化的项目。
重新开始让您有机会使用自上次项目以来学到的经验，并提供更高效的产品。
我建议不要尝试将旧网站重新加入新网站，你可能会花更多的时间来改变一些事情，而不是重新编写它。
祝你好运！
答案 3 :(得分：1)
数据库设计在这方面与应用程序设计不同。
通常，客户端重新思考会完全改变应用程序，但在企业的基础底层数据模型中几乎没有变化。这样做的原因是客户倾向于考虑业务流程，而不是基础数据。业务处理和数据处理紧密结合。数据存储的耦合程度较低。
在经典数据库设计时代，设计人员通过将数据库设计划分为（至少）两层来学习如何利用这种模式：逻辑设计和物理设计。业务流程的变更需要完全重写应用程序，以及对数据库物理设计进行重大修改，但需要对逻辑设计进行少量修改（如果有的话）。
如果您的数据库设计没有将这样的图层分开，则很难说出受影响的内容和不受影响的内容。从表和列开始。问问自己是否有任何更改需要从其所在的表中删除任何列，或者需要发明新列。如果答案是否定的，那么你很幸运。接下来，查看数据库上的约束（例如PRIMARY KEY，FOREIGN KEY，UNIQUE和NOT NULL）。客户的变化可能会收紧或放松这些限制。如果没有，你很幸运。如果您没有在数据库中声明任何约束，并选择在应用程序代码中执行所有完整性保护，那么您可能会运气不好。
在更改表上的索引以及应用程序处理数据的方式方面，您仍有大量工作要做。但是你已经挽回了旧系统的部分投资。
应用程序本身比数据库更容易受到客户端更改的影响。如果您的数据库设计完全由您的应用程序设计驱动，那么您可能会失败。
答案 4 :(得分：0)
您如何以一种让您对自己正在改变的东西不会破坏其他东西的信心保持自信的方式重新设计？简而言之，您将如何有效地解决激烈的应用程序设计更改（包括数据库和代码）？
测试，代码复杂性/覆盖率指标和持续集成系统。经常运行它们，这样你就知道哪些部分最危险，哪些部分开始写作。
当您必须进行可能存在问题的更改时，这些将成为您的安全网。如果有什么东西坏了，你的CI系统就会告诉你，在你意识到问题出现之前，你不会花几个星期的时间来挖洞。
答案 5 :(得分：0)
有时候你第二次做得更好，所以试着保持积极态度。此外，这次您将获得更多领域知识。