我正在研究一个胖客户端遗留的C ++应用程序，它有许多业务逻辑与事物的表示方式混合在一起。我想清理一下并完全重构代码，因此有一个明确的问题分离。我正在研究MVC或其他一些合适的设计模式以实现这一目标。
我希望得到之前走过这条路的人的建议 -
我是否使用MVP或MVC（或其他模式）？
进行这样的事情的最佳做法是什么（即有用的步骤/检查）？
答案 0 :(得分：1)
最有用的步骤是创建非常强大且完整的回归测试集，无论您选择哪种模式。
要在MVP和MVC之间进行选择，请查看他们在此SO问题中的差异：
答案 1 :(得分：1)
如果MVP与MVC是您的主要问题，您可以自由选择。
影响该决定的因素有三个：您之前的经验，对框架/库的支持，以及更适合现有代码库的内容。
在我的epxerience中，这两种模式都适合C ++遗留应用程序，如婚礼蛋糕上的猫呕吐。您的主要挑战将是：
其余部分对于处理遗留应用程序非常通用，与您的问题的细节无关。我会留在这里，因为你也有一个通用的部分。
重写与重构您已经陈述了自己的决定，所以我只是提出了需要考虑的专业重写参数：如果您有明确的规范并了解当前用户如何使用此应用，则重写可能当30％或更多代码需要更改时，更快，更便宜。 （这并不意味着“重写所有内容”，这也可能意味着将应用程序削减为仅逻辑，然后在其上方植入新的表示层）
假设你去重构：
定义目标为什么需要重构应用程序？很好的理由可能是要实现许多新功能，需要更换表示层，或者要保持理智。从那里，决定需要改变什么，以及什么可以保持原样。
你已经选择了目标：MV *。我只是想让你从长远来看考虑客户和代码所有者的好处。
阅读代码。不，真的，花点时间习惯代码库。使用调试器逐步完成它。尝试了解所涉及的事情。记下你认为应该做的改进。
创建测试 - 主要是针对当前所需行为的回归测试。使用遗留代码库，它们通常不是手动的，因此创建一个白痴可以遵循的测试协议，并试图抓住一个可以不时运行这些测试的不那么白痴。尝试从现有用户那里获得一些用例。
坚持小的，可逆的变化如果重构步骤出错，它应该足够小，可以毫不犹豫地扔掉。有时，这并不容易，我典型的最坏情况步骤是：
- 决定要替换的功能。制定计划新代码的样子。
- 将现有代码移动到也适用于新代码的接口后面
- 测试
- 用新代码替换功能
- 测试
- 有时，界面是“最终的”，有些时候你可以删除/减少它
始终改进不接受功能挫折“以后可以修复”。
答案 2 :(得分：0)
您应该看看Michael Feathers的“有效使用遗留代码”。本书概述了如何将现有代码纳入测试工具，以及如何安全地破坏代码中的依赖关系。