通过“代码重复”来应对需求变化

消除“代码重复”是绝大部分程序员矢志不渝追寻的目标。而在本文中，我们通过引入“代码重复”来解决开发中常见的需求变化。

代码重复

美国知名的软件工程师Sandi Metz曾经说过一句很经典的话：

代码重复比错误的抽象伤害更小。（duplication is far cheaper than the wrong abstraction）

或者说：

宁可代码重复，也不要错误的抽象。（prefer duplication over the wrong abstraction）

代码重复比错误的抽象伤害更小

“错误的抽象”问题是非常普遍和棘手。我们经常在工作中发现下面的场景：

1. A程序员看见了代码重复。
2. A程序员提取了重复的代码并给它取了一个名字。
3. 这创建了一个新的抽象。它可以是一个新的方法，甚至可能是一个新的类。
4. A程序员将重复的代码用新的抽象代替了。
5. 哈哈，代码是如此的完美。A程序员开心的跑开了。
6. 时间流逝。
7. 对于目前如此完美的抽象，有一个新的需求出现。
8. B程序员被指派来完成这个需求。
9. B程序员觉得有必要保留现有的抽象，但由于并不是在每种情况下都是完全相同的，他修改代码以接受一个参数，然后添加逻辑，根据该参数的值按条件去做正确的事情。
10. 曾经是通用抽象，现在根据不同情况而有不同的行为表现。
11. 现在又一个新的需求来了。X程序员又添加了一个额外参数，又一个新的条件。就这样循环下去直到代码无法理解。
12. 然后你出现在这个场景里，你的生活也发生了戏剧性的转折。

现存的代码具有强大的影响力。它的存在本身就表明它是正确的和必要的。我们知道代码代表了所花费的工作，并且我们非常有动力去保存这项工作的价值。不幸且可悲的事实是：代码越复杂、越难以理。也就是说，在创建代码时投入越多，我们就越会有保留这些代码的压力(“沉没成本谬误”)。就好像我们的潜意识告诉我们:“天哪，这么如此让人迷惑，一定花了很长时间才弄好。这些代码必然非常非常重要。让所有的努力付诸东流将是一种罪过。”

沉没成本谬误：人们往往不愿意正视持续增加投资未必会带来更多回报的事实，而选择铤而走险地持续对过去投资失败的项目增资，以逃避过去投资失败带来的反悔心理。

沉没成本谬误

当你出现在上面的第8步时，这种压力也可能会迫使你继续前进，也就是说，通过更改现有代码来实现新的需求。然而我们面临的残酷的现实是：代码不再代表一个单一且通用的抽象，而是变成了一个包含条件的过程，其中交织着许多模糊关联的思想。它很难理解且很容易打破。

如果你发现自己在这种情形下，不要被沉没成本所驱使。在处理错误的抽象时，最快的前进方法是回退。做以下几点:

1. 通过将抽象代码放回每个调用者来重新引入重复代码。
2. 在每个调用者中，使用错误抽象中传递的参数，来确定此不同调用者所需要调用的代码部分。
3. 删除不同调用者不需要的代码部分。

通过这样做消除了抽象和条件，并将每个调用者减少到仅它需要的代码。 当你以这种方式回顾决策时，通常会发现虽然每个调用者表面上调用了一个共享抽象，但他们运行的代码却独一无二。 一旦你完全删除了旧的抽象，你就可以重新开始，重新隔离重复代码并重新提取抽象。

在工作中人们勇敢地尝试以错误的抽象方式前进，但收效甚微。 添加新功能变得非常困难，每次成功都会使代码更加复杂，这使得添加下一个功能更加困难。 当他们将观点从“我必须保留我们对这些代码的投入”转变为“这些代码对解决以前的问题是有阶段性意义的，但也许我们已经从中学到了我们所需要的一切”，接着根据当前需求重新思考它们的抽象，一切都变得更容易了。 一旦代码被放回调用者，前进的道路就变得显而易见，添加新功能变得更快、更容易。

故事中的场景的寓意是什么？ 不要被沉没成本谬误所困！ 如果你发现自己通过共享代码传递参数和添加条件路径，则标明抽象是错误的。 也许这个抽象一开始可能是对的，但那一天已经过去了。 一旦抽象被证明是错误的，最好的策略是重新引入代码重复，让它告诉你什么是正确的。 虽然偶尔积累一些条件语句以深入了解正在发生的事情是有意义的，但如果你早点放弃错误的抽象，你会遭受更少的痛苦。

当抽象错误时，最快的前进方式就是回退。 这不是退缩，而是朝着更好的方向前进。这样做， 你不仅将改善自己的工作，也会改善所有追随者的工作。

参考资料：

https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction