接近重构

Question

我有一个以数据为中心的应用程序,用Python/PyQt编写.我打算做一些重构来真正将UI与核心分开,主要是因为还没有任何真正的测试,而且显然必须改变.

已经存在一些分离,我认为我已经以正确的方式做了很多事情,但它远非完美.两个例子,告诉你什么样的事情困扰着我:

当用户右键单击数据对象的表示时,弹出的上下文菜单由数据对象创建,尽管此数据对象(实质上是数据库行的ORM表示)应该与UI无关.
当某些内容被写入数据库但写入失败时(例如,因为数据库记录被其他用户锁定),会向用户呈现经典的"重试/中止"消息框.此对话框由数据提供程序*创建,但提供程序显然不应具有任何UI功能.显然,提供者可以提出异常或以其他方式指示失败,并且UI可以捕获并相应地采取行动.

_{*这是我用于对象的词,它基本上代表数据库表并在其数据对象和数据库引擎之间进行调解; 我不确定这是否通常被称为"提供者"}

我没有测试经验,所以我不容易"感觉"可测性问题等,但在我开始之前,必须进行一些重组.

没有复杂的业务逻辑(它主要只是CRU D,是的,即使没有D),这将比重写更重组,所以我并不真正关心引入这个问题中讨论的回归错误.

我的计划是开始重构这个想法,因为UI部分很容易被删除,例如,由Web前端或基于文本的界面而不是Qt界面替换.另一方面,Qt本身仍将被核心使用,因为信号/插槽机制在很多地方使用,例如数据对象发出changed信号来指示,你知道什么.

所以,我的问题:这是一种提高可测试性和可维护性的可行方法吗？还有其他任何评论,特别是考虑到Python吗？

Answer 1

如果你还没有这样做,请阅读Michael Feathers的"有效使用遗留代码" - 它正是处理这种情况,并提供了丰富的技术来处理它.

他提出的一个关键点是在重构之前尝试进行一些测试.由于它不适合单元测试,因此尝试进行一些端到端测试.我相信Qt有自己的用于驱动GUI的测试框架,因此添加针对已知数据库操作GUI的测试并验证结果.在清理代码时,您可以使用单元测试替换或扩充端到端测试.

Answer 2

我之前曾对大型遗留代码进行过重构，旨在实现 UI/后端分离。这既有趣又有益。

/称赞 ;）

无论人们如何称呼它，或者它是 MVC 的一部分，拥有一个非常清晰的API 层都是非常宝贵的。如果可能的话，您可以通过调度程序路由所有 UI 请求，这将使您能够更好地控制 UI <-> 逻辑通信，例如。实现缓存、身份验证等

可视化：

[QT Frontend]
[CLIs]             <=======> [Dispatcher] <=> [API] <==> [Core/Model]
[SOAP/XMPRPC/Json]
[API Test Suite]

这边走

添加测试套件来测试您的 API 会更容易。
它还使得添加更多 UI 变得更统一、更容易。
API 文档：如果您想通过某些 RPC 接口记录和公开 API，则生成 API 文档会更容易。如果有人不同意 API 文档的重要性，可以随时查看 Twitter API，它是成功的。
您可以快速将 API 层导入到 python shell 中并使用它

API 设计可以在开始为 API 层编码之前进行。根据应用程序，您可能需要使用 zinterfaces 等软件包的帮助。这是我在编写非常小的应用程序时所采取的通用方法，并且它对我来说从未失败过。

看看

这种方法的一个明显优势是，在拥有 API 层和新的 UI 后，您现在可以返回到遗留代码并以较小的步骤修复/重构它。

其他建议是准备好您的测试套件。请参阅 interstar 的建议，在棕地应用程序中实施单元测试的首要任务是什么？。