c++ - 在 C++ 遗留应用程序中重构上帝类的过程或步骤？

Question

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

首先在 switch 语句上，我发现有两个主要的潜在类因应用程序而异。所以我会尝试先构建这两个类，然后将相应的代码移动到神类中的类中。这是正确的方法吗？什么是解决这个问题的好方法？

BYW，我有一本书“有效地使用遗留代码”。所以你可以建议我也必须阅读这本书的哪一部分:-)

Answer 1

What is a good process to attack this issue?

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

好的过程是先不管问题，直到您必须处理它，或者除非您被命令重构代码。在您的场景中听起来不像是这种情况。

这种推理背后的基本原理非常简单:突然出现的完美主义(“让我们让它变得更好、更干净、更 Shiny ”)可能会让你在接下来的 6 个月里付出代价，而没有任何返回(满足感不会不算数，因为像这样的事情很快就不再令人满意了)。在此过程中，您将引入多个新错误，并且可能至少破坏整个系统一次，因此有时您的大型代码库无法正常工作。整个事情会增加工作量，并可能给您带来严重压力，从而导致不良健康问题。除非你被赋予重构代码的任务并且保证获得可观的返回，否则抑制“为了更大的利益”改进代码库的冲动 - 以这种方式思考可能会适得其反。

将整个事情置于允许快速分支/合并 (git) 的版本控制之下。因为您没有提到版本控制，那么根据墨菲定律，我将不得不假设您没有使用它。

专注于您必须立即修复的错误。在您使用的区域中，改进代码以使其适合您喜欢的风格，但要尽量减少更改，并且不要触及与当前问题无关的任何内容。当你有很多空闲时间时，如果你愿意，开始在必要的地方实现测试(与普遍的看法相反，单元测试不是 Elixir )。一旦你有办法测试该应用程序是否仍然有效，创建单独的开发分支，并开始非常缓慢地修改代码，并且只有在你有时间的时候才这样做。尽可能避免将更改合并回 master 分支(包含未修改的遗留代码)- 直到您确定一切正常。

请记住，您的目标不是编写完美的代码。您的目标是使用最少的资源(时间/精力)为当前问题提供快速有效的解决方案，同时获得最大的工作返回。以我的经验，背离这个原则是极其不健康的。

维护和改进现有的旧代码库大致相当于重建3英尺高的纸牌屋的底层。 IE。它具有挑战性、乏味、冒险，但不能提供必要水平的情感满足。因此，除非有某种巨大的返回，否则尽可能避免这样做是有道理的。代码不会腐烂，所以如果现有的可以正常工作，就没有理由仅仅因为您不喜欢当前源代码的外观而修改它。

但是，阅读代码并尝试理解以前作者的思想并更好地理解程序结构是个好主意。从长远来看，这可能会有所返回。