在c++遗留应用程序中重构god类的过程或步骤？

Question

此应用程序是由以前的开发人员在没有任何设计原则(SOLID)知识的情况下编写的。这个应用程序最关键的问题是它有一个包含大量switch语句的god类。这种不明智的结构使得维护应用程序变得很困难。当然，根本就没有单元测试。

首先，关于switch语句，我发现有两个主要的潜在类，它们随应用程序的不同而不同。因此，我将首先尝试构造这两个类，并将相应的代码从god类移动到这些类。这条路对吗？解决这个问题的好方法是什么？

顺便说一下，我有一本名为“有效使用遗留代码”的书。所以你可以建议我读这本书的哪一部分:-)

Answer 1

开关是一个显而易见的重构目标。但也可能会有其他人。你给了我们很少的进展。

我经常花大量的时间修改代码，重写代码，这样我就可以通过注释/取消注释几行代码来更改所使用的类型。

对于枚举上的swich，定义一个包含一个成员的结构可能很有用:枚举值，并具有到枚举值的隐式转换。使用typedefs或宏，您可以确保传递新类型而不是枚举。如果这有不希望的副作用，恢复，修复实现，并尝试使用您的新类型。

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

在此过程中是否需要进行单元测试取决于您。

Answer 2

解决此问题的好方法是什么？

“如果它没有坏，就不要修理它”。

一个好的过程是把这个问题放在一边，直到你不得不处理它，或者除非你被命令重构代码。在您的场景中，听起来不是这样的。

这种推理背后的理由很简单:突然爆发的完美主义(“让我们让它变得更好，更干净，更闪亮”)可能会让你在接下来的6个月里没有任何奖励(满足感不算数，因为这样的事情很快就不够令人满意了)。在这个过程中，您将引入多个新的bug，并且可能至少使整个系统崩溃一次，因此在一段时间内，您会有大量的代码库无法工作。整件事都会增加工作量，可能会给你带来很大的压力，这可能会导致糟糕的健康问题。除非你被赋予了重构代码的任务，并且得到了不错的回报，否则抑制住“为了更大的利益”改进代码库的冲动-这种想法可能会产生严重的适得其反的效果。

把整个东西放在允许快速分支/合并(git)的版本控制之下。因为你没有提到版本控制，所以根据墨菲定律，我不得不假设你没有使用它。

专注于你必须修复的即时bug。在你工作的地方，改进代码，使它适合你最喜欢的风格，但保持最小的变化，不要接触任何与直接问题无关的东西。当你有很多空闲时间时，如果你喜欢，就开始在必要的地方实现测试(与流行的想法相反，不是银弹)。一旦您有了一些方法来测试该应用程序仍然可以工作，就创建单独的开发分支，并开始非常缓慢地修改代码，而且只有在您有时间的时候才开始修改。尽可能长时间地避免将更改合并回主分支(包含未修改的遗留代码)-直到您确定一切都正常工作为止。

请记住，您的目标不是创建完美的代码。你的目标是用最少的资源(时间/精力)为当前的问题提供快速有效的解决方案，同时获得工作的最大回报。根据我的经验，背离这一原则是非常不健康的。

维护和改进现有的旧代码库大致相当于重建3英尺高的卡片屋的底层。也就是说，它是具有挑战性的，乏味的，有风险的，但不能提供必要的情感满足。因此，除非有某种形式的大笔奖励，否则尽可能长时间避免这样做是有意义的。代码不会腐烂，所以如果现有的代码工作正常，就没有理由仅仅因为您不喜欢当前源代码的外观而修改它。

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