译重构：这个类太庞大了

Posted 2021-02-28 钱行慕

来自于一个真实（有缺陷）的代码环境的重构的示例。

在这篇文章中我将浏览一些列来自于真实代码环境的重构示例。我并不打算演示一下完美的情形，但它确实代表了一些事实。

问题大纲

       故事开始于一件无聊的家务事。我之前写了某种个人账户软件 - Reconciliate。它在命令行中运行并执行如下动作：

• 加载一些我个人的以逗号分隔数据：
  • 我的最近的银行以及信用卡事务的记录
  • 我计划中的月度以及年度事务（基于一个中央电子表格的数据）。
  • 任何未经协调的先前记录的数据。
• 加载第三方以逗号隔开的数据（这些数据来自于银行以及信用卡公司）。
• 协调第三方数据以及我的个人数据。
• 将所有的东西都写回中央电子表格。

       我需要修正一些bug并添加一些新的特性。但我通常的工作流程是把我的最小的孩子送上床睡觉之后，晚上很晚的时候才会到达笔记本跟前，此时在我睡眠之前只有很少的时间了，而且通常距离我上一次看这个代码已经过去好几个礼拜了。在这种情形下我们很容易像这样来考虑事情（这是很可怕的）：“好吧我知道这个代码很混乱，但是我现在没有时间来考虑并立即修复它。”

      很明显这并不理想。

      特别是其中有一个类 - ReconciliationIntro - 每次当我看到它的时候都会头疼不已。它是臃肿的，卷曲的，并且不可能“fit in my head”。这也产生了一个令人讨厌的反馈循环：因为这个代码是如此的难以证明，重构会花费比我所拥有的更多的时间和精力，所以我将会忍受它更久的时间。即使其意味着我不能对其做任何更改，因为它将花费我太多的时间来理解代码的当前状态以及决定更改将在代码的什么地方进行。

     举个例子，我想要添加处理另一张信用卡的能力。在许多的地方我都使用了polymorphism 和 the strategy pattern 来保持封装整齐的各个信用卡的唯一的行为。但是 ReconciliationIntro 类是一个地方，在那里由于缺乏对代码的设计以及清晰的上下文分离，如果我添加另一张信用卡，我会使得一个已经臃肿的类变得更糟糕。它对于四种数据类型包含了四个重复的代码路径（Bank In, Bank Out, Credit Card 1 and Credit Card 2），并且如果我现在添加了Credit 3，我最终会遵循同样的反模式。