此应用程序是在以前的开发人员不知道设计原则（SOLID）的情况下编写的。该应用程序最关键的问题是它有神级，有很多很多的switch语句。这种不明智的结构使得维护应用程序变得困难。当然，根本没有单元测试。
首先在switch语句中，我发现有两个主要的潜在类在应用程序中有所不同。所以我将尝试首先构造这两个类，并将相应的代码移到神类的类中。这是正确的方法吗？攻击这个问题的好方法是什么？
BYW，我有一本书“有效地使用遗留代码”。所以你可以建议我也要读这本书的哪一部分： - ）
答案 0 :(得分：3)
攻击此问题的好方法是什么？
“如果没有破坏，请不要修理”。
好的过程是让问题单独处理，直到你必须处理它或除非你被命令重构代码。听起来情况并非像您的情景中那样。
这种推理背后的理由非常简单：突然完美主义（“让它变得更好，更清洁，更有光泽”）可能会让你在接下来的6个月中付出代价而没有任何奖励（满意度不高）算一算，因为这样的事情很快就会让人满意。在这个过程中，你将引入多个新的bug，并且可能至少打破整个系统一次，因此有一段时间你有大量的代码库不起作用。整个过程会增加工作量，并可能会给您带来严重压力，从而导致健康问题。除非你被赋予了重构代码的任务并且保证了合理的奖励，否则就会产生“为更大的利益”改进代码库的冲动 - 以这种方式思考会严重适得其反。
将整个内容置于允许快速分支/合并（git）的版本控制之下。因为你没有提到版本控制，那么根据墨菲定律，我将不得不假设你没有使用它。
专注于你必须修复的即时错误。在您使用的区域中，改进代码以使其适合您喜欢的样式，但保持最小化，并且不要触及与即时问题无关的任何内容。如果您有足够的很多的空闲时间，那么在必要时开始实施测试（与普遍看法相反，单元测试不是银弹）。一旦你有一些方法来测试该应用程序仍然有效，创建单独的开发分支，并开始非常缓慢地修改代码，只有当你有时间。尽可能避免将更改合并回主分支（包含未修改的遗留代码） - 直到您确定一切正常。
请记住，您的目标不是制作完美的代码。 您的目标是使用最少的资源（时间/精力）为当前问题提供快速有效的解决方案，同时为您的工作获得最大的回报。根据我的经验，偏离这一原则是非常不健康的。
维护和改进现有的旧代码库大致相当于重建3英尺高的卡房底层。即它具有挑战性，乏味，风险，但没有提供必要的情感满足感。因此，除非有某种重大奖励，否则尽可能避免这样做是有道理的。代码不会腐烂，所以如果现有的工作正常，没有理由仅仅因为你不喜欢当前源代码的外观来修改它。
然而，阅读代码并尝试理解前一作者的思想并更好地理解程序结构将是一个好主意。从长远来看，这可能会有所回报。
答案 1 :(得分：2)
交换机是一个明显的重构目标。但也可能有其他人。你让我们继续下去。
我经常花费大量时间来按摩代码，重写它以便我可以通过注释/取消注释几行来改变使用的类型。
对于枚举上的swich，定义包含一个成员的结构可能很有用：枚举值，并且隐式转换为枚举值。使用typedef或宏，您可以确保传递新类型而不是枚举。如果这有不受欢迎的副作用，请恢复，修复实现，并尝试使用您的新类型。
接下来，将开关代码移动到新类型的成员函数，一次一个开关。
如果在此过程中需要进行单元测试取决于您。