我看到这个主题现在不止一次出现.我希望那些目前处于类似情况或过去的人可以提供一些有见地的建议.如果您也分享过去的经历可能会有用.
因此,这些相当大的Windows窗体应用程序已经开发了多年.虽然开发团队已经尝试将业务逻辑与UI分离,但它并没有完全发生,并且代码中有许多区域,其中业务逻辑硬连接到UI.实际上,在很多地方都可以看到以前尝试采用MVP架构的残余.还有单元测试,但代码覆盖率相对较低.然而,有一些热点 - 每个人都知道的领域变得越来越复杂,他们必然需要.
很多时候,只有当测试人员拿起他们的火炬灯并且真正开始寻找不幸的太晚,昂贵且有风险的错误时,才会发现可能早先发现的错误.工程师,测试人员和PM--都意识到需要做些什么.
什么是最实际的方法来解决这种情况,或改善这种情况？由于这将是一项长期任务,衡量目标进展的最佳方法是什么？如何以客观的术语来定义目标？
您需要重新构建业务层,然后将UI连接回此重新架构的层.
在完成此操作后,您将保留现有UI和硬连线业务逻辑,并一次将其切换为一个新表单.
这具有允许您在效果较小时添加所需的所有单元测试和自动测试工具的优点.您还可以确保您的组件正在执行他们正确执行的操作.
基本上,短期内投资回报率有限,但中长期(实际上只是长期)潜在的巨大收益.