如何重构WinForms应用程序？

Question

我打算在不久的将来修正WinForms应用程序（.NET 2.0）。通过源代码查看，我发现大量代码文件（超过2000行），其中大部分都是生成大量代码隐藏的对话框。

有没有给我分享的提示？任何战争故事或bug修复或重构WinForms应用程序的最佳做法？

Answer 1

• 首先尝试了解代码及其背后的逻辑。
• 一旦你了解一些代码的尝试为业务对象
• 使用某种层方法在新的设计模型需要的类（3层是经典）：界面层，业务层，数据访问层（或其他服务层）。
• 大量的耐心和文件的一切！

我觉得这是基本的东西。很多人在这里必须有很多建议。祝你好运！

Answer 2

我会先写一些单元测试。如果代码相当密集，您将需要这些来保持您的理智。

他们会给你一些信心在你的重构中相当积极。

Answer 3

夫妇的从顶头部的东西：

• 把所有生成的代码的局部类或区域（我使用区域）
• 移离操作的所有代码到一个单独的区域或类作为功能
• 写单元测试针对每个功能
• 这点之后执行共同重构模式，结合相同/类似的功能为一个函数
• 确保不同的按钮不使用不同的功能来做同样的事情（特别是在VB.NET中，这是很常见的设计，所以你可以在你的应用程序中发现）
• 在可能的情况下正确使用sender对象，而不是硬编码控制事件处理程序中的控件名称
• 如果看到任何此代码可以转换为一个很好的类，请执行此操作。摆脱WinForms中的所有非GUI代码。有时需要对原始类进行重构，以便使用GUI进行工作，编写单元测试并重构它们。 （一般即使没有单元测试你应该罚款）

Answer 4

短的版本：

购买迈克尔羽毛的书，有效地与遗留代码一起工作。

较长的版本：

维护时（改变）这样的应用程序是这样做不打破东西的最大挑战。这意味着您需要了解应用程序的行为，最简单的方法就是获取应用程序的测试。正如你所指出的，起初这可能令人望而生畏，但这并非不可能。它需要纪律和耐心。

您不必从单元测试开始。让一个自动化框架（如NUnitForms或White）首先将应用程序作为黑盒子来驱动通常会更容易。围绕你需要改变的地区建立一套测试，给你足够的信心去改变它，而不会破坏某些东西。然后进入并开始重构单元可测试性。

如果它就像我的工作申请任何东西，它主要包括：

• 删除未使用的代码（这是一个分心）。
• 删除公共静态方法调用并用接口替换它们（依赖注入是一种关键技术）。
• 将重复的代码提取到类中。
• 隐藏文件处理，网络IO，和用户界面代码背后的适配器（可以是非常薄的包装首先，就足以让你可以在测试时用存根替换它们）。
• 寻找机会将行为提取到小类中。

有时，重写代码段而不是重构它们会更容易，但是需要通过测试或通过引用规范（如果存在）来理解行为。

除了任何实际的建议，如果你是一个团队的一部分工作，请确保你是一起工作。它将使工作变得更轻松，更愉快，并确保你今天做出的改变不会由明白你工作的人明天撤销。

我可以整天写这个话题，但Feathers先生的话更好，我很饿。祝你好运！