Language agnostic 重用现有功能

向现有系统添加新功能时，如果您遇到一个几乎满足您需要的现有功能，最佳做法是：

• 复制现有函数并在新副本上进行更改（知道复制代码会让您的开发伙伴们大哭）

-或-

• 编辑现有功能以处理现有案例和您的新案例，这样可能会在系统的现有部分引入新的bug（这会让QA团队大哭）
  • 如果您编辑现有函数，在创建新的独立函数（基于副本）之前，您在何处画线…函数的10%，函数的50%

---

您应该始终努力避免代码重复。因此，我建议您尝试编写一个新函数，修改现有函数的返回值，以实现新功能

我确实意识到，在某些情况下，这样做可能是不可能的。在这种情况下，你绝对应该考虑改写现有函数而不改变它的接口。在将修改后的函数添加到项目代码之前，可以通过对修改后的函数运行单元测试来防止引入新的bug

---

如果你只需要一部分现有函数，考虑从现有的函数中提取一个新函数，并在现有的和新的函数中使用这个新的“帮助器”函数。再次通过单元测试确认所有功能都按预期工作。

您不能总是这样做，但这里的一个解决方案是将现有功能拆分为其他小部分，允许您使用所需的部分，而无需编辑所有代码，并使编辑小部分代码更容易

---

也就是说，如果您认为可以在不注意的情况下将新的bug引入系统的现有部分，您可能应该考虑使用单元测试。

我倾向于遵循的经验法则是，如果我可以通过向现有函数添加额外参数（或新的有效值）来覆盖新的行为，在现有的情况下，虽然代码或多或少“明显相同”，但更改函数并没有太大危险

例如，旧代码：

def utf8len(s):
    return len(s.encode('utf8')) # or maybe something more memory-efficient

新用例-我正在以使用null对象模式的样式编写一些代码，因此我希望

utf8len（None）

返回

None

，而不是抛出异常。我可以定义一个新函数

utf8len\u nullobjectpattern

，但这会很快变得很烦人，所以：

def utf8len(s):
    if s != None:
        return len(s.encode('utf8')) # old code path is untouched
    else:
        return None # new code path introduced

然后，即使

utf8len

的单元测试不完整，我敢打赌除了

None

之外，我没有改变任何输入的行为。我还需要检查是否没有人依靠

utf8len

为

None

输入抛出异常，这是一个（1）文档和/或测试质量的问题；（2）人们是否真正关注定义的接口，或者仅仅使用源代码。如果是后者，我需要查看呼叫站点，但是如果事情做得很好，我几乎不会

旧的允许输入是否仍然被视为“显然相同”，这并不是修改代码的百分比的问题，而是如何修改的问题。我特意选择了一个简单的例子，因为整个旧函数体仍然明显地存在于新函数中，但我认为当你看到它时，你就会知道。另一个例子是使用只提供旧的固定值的默认参数来配置固定值（可能通过传递值或用于获取值的依赖项）。旧的固定对象的每个实例都被（调用）新参数替换，因此在diff上很容易看到更改的含义。您至少有（或编写）一些测试，以确保您没有通过一些愚蠢的输入错误破坏旧的输入，因此即使您对测试覆盖率没有完全信心，您也可以继续进行

---

当然，您需要全面的测试，但您不一定拥有它。这里还有两个相互竞争的维护要求：1-不要复制代码，因为如果代码中有bug，或者将来可能需要更改的行为，那么您就是在复制bug/当前行为。2-开放/封闭原则，这有点令人费解，但基本上说，“写一些有用的东西，然后不要碰它”。1说你应该重构，在这两个相似的操作之间共享代码，2说不，你已经发布了旧的一个，或者它对这个新东西有用，或者它不可用，如果它不可用，那就别管它。

如果函数足够复杂，只可能修改10%的函数，理想的情况是你的测试足够好，你可以自信地修改现有的函数而不破坏它。因此，这里甚至有一个问题要问，这一事实预先假定测试还不够好，我认为答案将取决于它有多糟糕，从“我们有测试，我们只是没有时间做我们想做的一切”到“令人震惊”。