过程或步骤来重构C++遗留应用程序中的神类？

Question

此应用程序的编写没有任何设计原则（SOLID）的知识由以前的开发人员。该应用程序最关键的问题是，它有上帝的类，有很多很多的switch语句。这种不明智的结构使得难以维护应用程序。当然，根本没有单元测试。

首先在switch语句中，我发现在应用程序中有两个主要的潜在类。所以我会尝试首先构造这两个类，并将相应的代码移动到上帝类的类中。这是一个正确的方式吗？什么是一个很好的过程来解决这个问题？

BYW，我有这本书“有效地工作与遗产代码”。所以你可以建议本书的哪一部分我也要阅读:-)

Answer 1

开关是一个明显的重构目标。但也可能有其他人。你让我们继续下去。

我经常花大量的时间来处理代码，重写代码以便我可以改变注释/取消注释几行所使用的类型。

对于enum上的swich，定义一个包含一个成员的结构是非常有用的：枚举值，并隐式转换为枚举值。使用typedefs或宏，你可以确保你的新类型被传递，而不是枚举。如果有不良副作用，恢复，修复实施，并尝试使用你的新类型。

接下来，将开关代码移动到新类型的成员函数中，一次一个开关。

如果在这个过程中需要单元测试取决于你。

Answer 2

什么是一个很好的过程来解决这个问题？

“不修复它，如果它没有损坏”。

好的过程是让问题独立，直到您必须处理它或除非您被命令重构代码。这听起来不像你的情况是这样。

这种推理背后的理由非常简单：突然出现的完美主义（“让我们变得更好，更干净，更光滑”）可能会让您在未来6个月的生活中付出代价，无任何奖励（满意度不值得，因为这样的事情很快就不会令人满意了）。在这个过程中，你会引入多个新bug，并且可能至少破坏整个系统一次，所以会有一段时间你有大的代码库不起作用。整件事会增加工作量，并可能给你带来严重的压力，从而导致健康问题。除非你被赋予了重构代码的任务，并且保证了可观的回报，否则不要强调要“为了更好的”而改进代码库 - 这种想法可能会导致适得其反。

把整个事情放在允许快速分支/合并（git）的版本控制之下。因为你没有提到版本控制，所以按照墨菲定律，我不得不假设你没有使用它。

专注于需要解决的即时错误。在与您一起工作的领域中，改进代码以使其符合您最喜欢的风格，但保持最小化，并且不要触及与即时问题无关的任何事情。如果你有这种感觉，当你有空闲时间很多时，开始在必要的地方实施测试（与流行的观点相反，单元测试不是银色的子弹）。一旦你有一些方法来测试该应用程序仍然有效，创建单独的开发分支，并开始修改代码非常缓慢，只有当你有时间。尽可能避免将更改合并回主分支（包含未修改的旧版代码），直到您确定所有内容均正常工作。

请记住，您的目标不是完善的代码。 您的目标是使用最少量的资源（时间/精力）为当前问题提供快速高效的解决方案，同时获得工作的最大回报。根据我的经验，偏离这个原则是非常不健康的。

维持和改善现有的旧的代码基本上大致相当于重建3英尺高卡房的底层。即这是具有挑战性的，乏味的，冒险的，但并不能提供必要的情感满意度。所以除非有某种重要的奖励，否则尽可能避免这样做是有道理的。代码不会腐烂，所以如果现有的工作正常，没有理由修改它，只是因为你不喜欢当前源代码的外观。

但是，阅读代码并尝试理解以前作者的想法并更好地理解程序结构将是一个好主意。这从长远来看可能会得到回报。