如何处理设计变更?

在这方面,数据库设计不同于应用程序设计。

通常,客户机重新思考会完全改变应用程序,但在企业的基本底层数据模型中几乎没有改变(如果有的话)。原因是客户倾向于从业务流程的角度思考,而不是从基础数据的角度思考。业务处理和数据处理紧密耦合。数据存储的耦合度较低。

在经典的数据库设计时代,设计师学会了如何利用这个模式,将他们的数据库设计分为(至少)两层:逻辑设计和物理设计。业务流程的变更需要完全重写应用程序,以及对数据库物理设计进行重大修改,但很少(如果有的话)需要对逻辑设计进行更改。

如果您的数据库设计没有将这样的层分离出来,那么很难判断哪些层会受到影响,哪些层不会受到影响。请从表和列开始。问问你自己,是否有任何更改需要从它所在的表中删除任何列,或者需要发明新的列。如果答案是否定的,你就走运了。接下来,查看数据库上放置的约束(比如主键、外键、唯一键和非空键)。这些限制可能会因客户的更改而收紧或放松。如果没有,你就走运了。如果您没有在数据库中声明任何约束,并选择在应用程序代码中执行所有完整性保护,那么您可能就走运了。

在更改表上的索引以及应用程序处理数据的方式方面,您仍然有相当多的工作要做。但你挽救了对旧系统的部分投资。

应用程序本身比数据库更容易受到进程中客户端更改的影响。如果您的数据库设计完全由应用程序设计驱动,那么您可能会走运。

假设您已经有了单元测试,这只是重构。

如果没有单元测试,那么

1. 为您可能保留的部分编写单元测试。

2. 为要更改的部分编写单元测试。

3. 运行测试。“保持”应该通过。“改变”应该失败。

4. 开始重构,直到测试通过。

这在软件中并不是什么新鲜事,人们已经做了这件事并为此写了很多文章。

尝试阅读

• Working Effectively with Legacy Code
• Refactoring Databases: Evolutionary Database Design

这里解释的技术对于支持任何类型的长期运行的IT项目都是无价的。

如果这是一个巨大的变化,最好是重新开始。我已经完成了一些经历了巨大变化的项目。

重新开始给你一个机会,利用自上一个项目以来的经验,并提供一个更有效的产品。

我建议你不要把旧的网站重新开发成新的网站,你可能会花更多的时间在修改东西上,而不是你刚重写的时候。

祝你好运!

你将如何重新设计,使你保持自信,你正在改变的东西不会打破其他东西?简而言之,您将如何有效地处理急剧的应用程序设计变更(包括数据库和代码)?

测试、代码复杂性/覆盖度量和持续集成系统。尽早并且经常地运行它们,这样您就知道哪些部分是最危险的,以及从哪里开始写作。

当你必须做出潜在的有问题的改变时,这些将成为你的安全网。如果有什么东西坏了,你的CI系统会告诉你,在你意识到有问题之前,你不会花几个星期的时间在某个兔子洞里。

有时候你第二次做的更好,所以试着保持积极。另外,这次你将有更多的领域知识。