我继承了一个在架构上是灾难的ASP.NET应用程序，但是它可以正常使用并且可以在生产中使用。为了在将来增强应用程序，我需要完全重新构建它，但我需要保留现有的前端功能 - 我所要求的更改比前端功能或用户交互更多的后端集成
基本问题是 - 大部分业务逻辑都在存储过程中（其余部分在UI代码隐藏文件中） - 没有业务领域模型可以说。我需要将逻辑从数据库（以及从UI向下）重构为代码，但应用程序的行为基本上与这些存储过程有关。所以问题是这个 - 你如何进行这种完整的重新架构？
我理解小步骤的重构，我读过fowler等等。我真的在寻找那些经历过类似过程的人的实用建议。
谢谢！
修改 我应该说，理想情况下，我想在多个发布周期中迭代地重新设计。
答案 0 :(得分：3)
恕我直言，最重要的事情是开发大量优秀测试，涵盖您想要保留的全部功能。
我知道在混乱的代码库中编写测试非常困难，但仍然可以通过一些依赖性破坏技术。我建议"Working effectively with legacy code"，因为它完全是关于重构的实际方面。
答案 1 :(得分：2)
这很痛苦，但第一个大问题是：你真的需要做这个重新架构吗？如果数据库设计或多或少都可以，那么您可以构建新的东西并留下旧的东西吗？每一个反射都渴望整理混乱，但从业务用户的角度来看，需要什么样的投资水平以及投资回报是什么？
您已经将迭代更改确定为一种方法。为了实现这一点，它意味着系统中存在一定程度的粒度，允许您在不影响其他部分的情况下更改某些部分。您的想法可能是提供一些新的业务价值并同时清理部分应用程序 - 有效地分摊许多有价值的可交付成果的变更成本，以及交付新东西时的“垃圾收集税”。那“税”可以接受吗？
所以我认为粒度假设是你需要检查的。识别一小块。尝试重构。你觉得它是否像你希望的那样孤立变化？成本是否符合预期？而且重要的是......那里有什么不好的东西？您的代码可能比现有存储过程执行得不好。发展“税”是一回事，运行时表现“税”是一个完全不同的东西。
答案 2 :(得分：1)
分别处理存储过程和UI的业务逻辑。并首先采取SP。一次一个：
同样接近UI。在任何一种情况下，它都不像听起来那么简单 - SP和“常规”代码之间的映射最多也是不完美的 - 但我不知道更好的方法。
我主张不编写一系列单元测试，然后重构;相反，测试覆盖今天要重构的代码。一些单元测试，一点点重构;泡沫，冲洗，重复。你可以随时打断并拥有比你开始时更好的系统;在进行变更和看到结果之间没有很大的延迟。
答案 3 :(得分：0)
我非常同意piotsrz's answer - 一套好的，全面的单元测试正是您在重构时帮助保持行为所需要的。将这些测试添加到持续集成系统中，以便您获得每个开发人员的每次提交的快速反馈。
关于这个主题的另一本好书是Refactoring to Patterns，它描述了几种保留行为的架构转换的迭代技术。