是有代码重复并且非常简单/可读更好，还是没有重复（使用泛型）但要复杂得多？

Question

一般来说，我经常遇到这种情况。我的一些同事更喜欢非常简单、易于阅读的类，即使这意味着存在一些代码重复，而我会尽我所能避免代码重复，即使这意味着使架构变得更加复杂。最佳实践是什么？我只用 Java 工作。

Answer 1

虽然这两个目标都很好，但我认为可读性绝对是拥有可维护代码库的首要要求。我总是更喜欢简单、可读和可维护，而不是完全消除代码重复。

Answer 2

我总是喜欢没有重复代码的解决方案。即使更复杂的架构一开始更难理解，但维护的好处远远超过了学习曲线。

Answer 3

最佳实践：如果代码很短，请将其复制两次，但切勿重复。

因此，如果您在 3 个不同的位置复制/粘贴了非常相似的代码片段，请考虑重构。

请记住，重构并不自动意味着使代码变得更加复杂。请考虑以下事项：

class IntStack
{
    public int value;
    public IntStack next;
}

class StringStack
{
    public String value;
    public StringStack next;
}

class PersonStack
{
    public Person value;
    pubilc PersonStack Next;
}

每次您需要一个新数据类型的堆栈时，您都需要编写一个新类。复制代码工作正常，但假设您想添加一个新方法，也许是一个返回新堆栈的“Push”方法？好吧，现在你不得不将它添加到无数不同的地方。或者您可以使用通用对象堆栈，但这样您就会失去类型安全性。泛型将简化架构：

class Stack<T>
{
    public T value;
    public Stack<T> next;
}

酷！

好吧，这个例子怎么样：

class Logger
{
    int logtype;
    public Logger(int logtype) { ... }

    public void Log(string text)
    {
        if (logtype == FILE) { ... }
        elseif (logtype == DATABASE) { ... }
        elseif (logtype == CONSOLE) { ... }
    }

    public void Clear()
    {
        if (logtype == FILE) { ... }
        elseif (logtype == DATABASE) { ... }
        elseif (logtype == CONSOLE) { ... }
    }

    public void Truncate(int messagesToTruncate)
    {
        if (logtype == FILE) { ... }
        elseif (logtype == DATABASE) { ... }
        elseif (logtype == CONSOLE) { ... }
    }
}

好吧，所以每次添加一个方法时，你都必须检查你正在使用哪种类型的记录器。痛苦，并且容易出现错误。通常，您会分解出一个接口（可能使用 Log、Clear 和 Truncate 方法），然后创建三个类（FileLogger、DatabaseLogger、ConsoleLogger）。

更多类=更多架构。从长远来看，这是更容易还是更难维护？对于这个例子，我想说代码现在更容易维护，但是 YMMV。

Answer 4

避免代码重复的主要原因是可维护性。如果一段代码出现在多个位置，那么当需要更新时，您必须记住每个地方都进行更改。忘记更改一个实例可能会导致大问题，您可能不会立即注意到。

Answer 5

在某些极端情况下，您可以通过复杂的元编程（对于 Java 来说不是太大问题）或过度使用反射来防止代码重复，在这少数情况下，我倾向于允许重复。这是很少见的。只要代码仍然可以被熟练的开发人员（而不是您）理解，我就会消除重复。

我遇到过这样的情况：一个团队包括一两个熟练的开发人员和一群新手，新手试图阻止使用他们一眼看不懂的编码方法。必须抵制这种行为。

Answer 6

我不明白“泛型”与你的问题有什么关系。使用单独的类来表示 CollectionOfFoo 和 CollectionOfBar 是微不足道的，显然是错误的，因此这不是您所要求的。

你可能必须为每个观点提供一个例子，但你仍然可能会因为主观而被关闭。

Answer 7

避免代码重复总是一件好事。您需要警惕的一件事是过早泛化。

当您获得几段看起来相似的代码时，无需急于介入。在开发出一个好的模型之前，可以先坐下来。

即使举几个你需要概括的例子也可以，特别是当事情稍微复杂和/或开放式的时候。当你有 3-5 个以上的例子而不是一两个例子时，就更容易概括。

Answer 8

这是一个判断。大多数程序员重复代码太多，我认为这导致了热情的开发人员的态度，即消除重复绝对是一件好事，但事实并非如此。让代码易于阅读应该是首要任务，消除重复代码通常对可读性来说是件好事，但并非总是如此。

另外，我不会使用具有商业价值的代码来使用不熟悉的语言功能来学习它们。为此目的创建单独的学习项目。您不想最终在下班时间被叫去工作来修复由于过于喜欢泛型或任何其他功能而导致的错误。

Answer 9

不可以。这两种情况都是不可接受的。使用泛型编写它，但只需达到所需的复杂程度即可。

不要重复代码；你必须双重修复错误、双重添加增强、双重编写注释、双重编写测试。只要您在该代码库上工作，您创建的每一行代码都是一个小小的负担；尽量减少你的负担。

Answer 10

取决于多种因素：

• 有多少代码被重复？如果相同的五行出现两次，只要有合理的理由，这并不是什么问题。避免过度构建代码，从长远来看，它实际上可能会降低可维护性，因为下一个处理代码的人可能不会欣赏架构中的所有微妙之处，并将其严重变形。
• 相同代码有多少份？ 2 还不错，但 10（十进制）就不太好了。
• 为什么代码是重复的？我遇到过许多“重复”，一旦构建了所有需求，结果证明根本不是重复，只是有些相似。

所以我的答案也许是……

Answer 11

在给出答案之前，我想看一些示例代码，以了解问题的真正含义。

在等待的过程中，我相信，如果您的代码是按照最理智的 OO 原则构建的（例如每个类只做一件事并且只做一件事），就不应该有任何代码重复。当然有可能对抽象等感到疯狂，这最终会创建大量无用的类，但我认为这不是这里的问题。

Answer 12

泛型难以阅读的主要原因是没有经验的程序员不熟悉它。这意味着在选择命名和文档时必须非常小心，以便清晰可见。

此类核心类的命名非常重要。设计师可能希望在选择名称之前与同行进行彻底的讨论。

Answer 13

很好的问题；一般答案可能不适合您的情况。有很多因素决定您的选择

1. 当前的代码质量
2. 您的产品/项目阶段，早期/成长/成熟
3. 开发人员的经验和技能
4. 您的项目/产品上市时间

这些是决定您选择的一些关键因素。根据我的经验，我意识到重复的业务逻辑（中间层）代码不是一个好的做法，但表示层可以有重复的代码。

当我写这篇文章时，我记得文章“缓慢增长等于死亡”。编写高质量和非重复的代码可能需要时间，但这不应该成为您业务的瓶颈。

Answer 14

通常，重复代码的唯一原因是克服语言的弱模板/宏/泛型系统或进行优化，其中存在处理不同类型的不同低级函数名称。

在 C++ 中，您注意到您不使用它，模板系统允许零开销类型和函数生成，并且专门化可用于“自定义”生成的代码某些类型参数。 Java 没有这样的东西，消除了 C++ 中可用的通用和特定选择避免。

在 Common Lisp 中，可以使用宏和编译器宏来生成类似于 C++ 模板的代码，其中可以针对特定类型自定义基本情况，从而产生不同的代码扩展。

在 Java 中，我唯一反对泛型代码的情况是使用数字类型的内部循环。在这些情况下，为泛型代码中的数字类型支付装箱和拆箱成本是不可接受的，除非您的探查器可以让您相信编译器或 HotSpot 足够聪明，可以放弃装箱。

至于可读性，那么，让你的代码成为你的同事必须面对的模型和挑战。为那些阅读困难的人提供教育。鼓励他们检查是否存在缺陷。如果他们找到任何版本，您就可以展示只需修复唯一版本的好处。

Answer 15

将其与关系数据库中的规范化进行比较 - 您可能想要一个地方存放某种函数或数据生活，地方不多。它在可维护性和推理代码的能力方面有很大的不同。