这篇博客是为所有那些因为在代码库中造成的混乱而被当场抓获时开始在高级工程师面前掩面的开发人员的。它在生产环境中产生了很多错误，整个软件成为其他开发人员工作的噩梦。
为什么会造成混乱？……只有造成混乱的开发人员才能解释原因。也许有一天他/她心情不同，变得懒惰从文件中删除一段不必要的代码，也许是截止日期的压力，或者他只是另一个进入开发的男孩/女孩，无法应用最好的由于缺乏知识而导致的编码实践。
每当开发人员编写干净、结构良好、文档齐全、注释良好且经过简单规划的代码时，他们就会对其感到满意。对于他们刚刚在代码库中编写的最优雅的代码，您会发现他们脸上洋溢着笑容。
他们遵循一些设计模式并使用框架来加速开发过程，他们还遵循一些最佳编码实践，使他们的源代码灵活、可重用和可维护。但即使在完成所有这些事情之后，您仍会发现他们的软件中存在反模式，这些反模式是在一个月前编写的，或者由于截止日期压力而编写得太快。
如果您从事软件开发，那么您肯定会给出一些需要快速修复的错误。你尝试了一个基本的 hack（一个简单的解决方案），你实现了它，它起作用了，你在多个地方复制了这段代码来修复相同的错误。问题已解决，但您犯了一个错误，并在您的软件中创建了一个反模式。你能想象这个错误会造成另一个问题吗？或者它会在您的软件中产生另一个错误？
希望您可能已经明白了我们的观点，并且您可能已经理解了软件开发中反模式的含义。在这篇博客中，我们将详细讨论这个话题，我们将讨论软件开发中不同类型的反模式。让我们先从快速介绍开始……
什么是反模式？
您可能已经从我们所做的所有讨论中理解了反模式的含义。反模式是设计模式的另一面。你也可以称之为设计味道，这是由糟糕的软件设计引起的。它们通常是无效或模糊的修复。代码中存在反模式可能会产生很多错误，您可能需要稍后正确修复它。
反模式会严重影响您的软件，并且会增加“技术债务”——为您带来额外的工作（当然也很头疼）。让我们讨论六种最常见的反模式类型及其在软件开发中的解决方案。
1. 意大利面代码
这是您在软件开发中会发现的最常见的反模式类型之一。您编写了一些代码，实现了一些功能，它起作用了，然后您进一步在软件中实现了其他几个功能，但是您没有注意编码约定或使其更清晰。
现在只需观察代码的整个结构，观察软件的完整流程。长得怎么样？？是不是很乱？？文件和函数不是随便乱放的吗？
随着程序的增长，您最终会得到一堆随机放置在不同文件中的函数。没有什么是模块化的，你会发现自己一遍又一遍地复制和粘贴代码行。您对一个函数进行了更改，然后其他几个功能中断了。这称为意大利面条式代码。
整个应用程序变成了一个无法重构的大泥球，您可能不得不决定重写。你会看到一个没有编码注释的草率结构，到处都是静态变量/函数，多次重载方法，还有一千行没有编码约定的代码。
在一个没有组织功能、文件、图像和项目的其他几个部分的项目上工作真的很令人沮丧。完整的流程和结构变得混乱。当开发人员不太考虑维护软件的干净结构时，通常会发生这种情况。他们立即开始编写代码，而没有注意程序的流程。
对于其他开发人员来说，很难为其添加功能。整个程序对他们来说太可怕了，要处理它，他们需要首先组织代码中的所有内容。这可能会破坏软件中的一些东西，并且也变得难以理解更改的范围。
2. 金锤
软件开发是一个领域，如果解决方案或模式适用于单个问题，那么它也适用于其他问题并不重要。如果一个解决方案适合问题 A、问题 B 和问题 C，那么它就不一定适合问题 D。
想象一个场景，你正在做一个项目，你调整了一个新的解决方案，一个全新的架构，这个新架构解决了你过去的所有问题。现在你为另一组问题尝试了这个新架构……瞧，它也适用于这个问题。现在你变得自信，你开始尝试让它适合任何地方，但是……等等，你发现它对XYZ的问题不起作用。这就是金锤或银弹。
金锤可能会在您的代码中产生许多问题。所选的解决方案可能不是您问题的有效解决方案，您的代码也可能变成过于复杂的代码。
请记住，在软件开发中，每个设计模式、每个框架或语言都适用于特定类型的问题。你不能让它无处不在。如果一个问题 D 在你面前哭着说它不适合我，你为什么要把它放到你最喜欢的架构中？
如果您将正方形撞成圆形，您的软件性能将会下降。仅仅因为您对某种方法感到满意并且更容易，因此您不要尝试使用相同的方法或模式解决所有类型的问题。
为特定问题选择正确的工具、语言、框架、模式或架构。对于一个问题，总是有多个解决方案（至少两个）。观察每一种的优缺点，然后选择最好的一种。
3. 船锚
如果您从事软件开发，那么您肯定已经预测到将来要实现的东西。如果我以后需要实现 XYZ 功能怎么办？如果这种情况发生在我的代码中怎么办？
上面的假设问题迫使您在程序中添加一些现在不需要的额外代码行。这就是软件中的船锚反模式。当程序员在代码库中留下一段代码认为他们以后可能需要它时，这种反模式就存在于代码中。
您编写了一些当前需求中未提及的代码，但您确信下个月或两个月后可能会需要它。你不删除它。你认为你会立即让它发挥作用，无论将来何时你被要求实施它。
这只会在您的软件中创建另一个反模式。您的同事正在查看代码并试图了解这段特定代码在代码库中的作用。当然，阅读和调试那些不必要的代码行只是浪费时间。
简单地说，船，锚描述了一件事情——沉重的携带（过时的代码，没有用，没有用途，在代码中什么都不做，并增加了技术债务）。
4. 死代码
死代码类似于Boat Anchor。请记住，当您收到一个项目时，该项目的许多文件保存在不同的目录中。您打开一个文件，您会看到有几行代码，您测试了每个函数、模块和文件以识别它在项目中的作用，并且您发现一个函数看起来没有做任何事情。您试图确定从任何地方调用它的原因，您要求您的团队成员了解此函数的用途，但没有人确定它在做什么。
此函数是几个月前在贵公司工作的前工程师留下的。大家太着急了，删掉这个函数。有时您会看到它在做什么，但缺少上下文。您了解流程，但您的文件中似乎不再需要此函数。这种类型的反模式被称为死代码。顾名思义，它在您的代码中什么都不做。
死代码主要是几年前为构建某些功能而编写的文件中的一段代码，但现在不再需要了。如果此函数将被完全删除，您的程序将不会在任何地方终止。
完全删除死代码是有风险的。如果您不想删除死代码，您可以进行猴子测试。把这段代码注释掉，关掉这些东西，看看生产中会发生什么。您还可以采用迭代方法从代码库中逐段删除代码。不断检查软件中的功能以确保您没有破坏任何东西。
5.神物与神级
是否有任何对象或类在您的代码中做了太多事情？这个类或对象负责太多的事情。用户的名字、姓氏、用户ID、交易ID、交易总额、用户购买的物品列表等。
一个典型的神类/神对象承担着许多责任和许多依赖。神类控制着许多其他的类。如果大部分代码需要访问一个对象，那么该对象可能是一个上帝对象。
这种反模式打破了“单一职责”的原则。你能想象一个场景，你实现了一个类，你开始向它添加东西（因为你懒得创建另一个类），你继续这样做，这个类随着时间的推移而增长，所有其他代码都在访问这个类有一天你发现它变得难以维护。
这种情况对于许多开发人员来说可能是一场噩梦。 God 类很难进行单元测试、维护、调试和记录。您可能已经开始设计没有神级的应用程序，但是当需求增加并且团队规模一天天增长时，一个明确定义的类在某个时候变成了神级。
为了解决这个问题，你需要更好地分离和模块化你的代码。有时程序员会将其与一个非常有趣的例子进行比较。你要一根香蕉，但你收到了一只拿着香蕉的大猩猩。你得到了你想要的，但比你需要的更多。
下面是一个包含太多信息的界面示例……
interface Car {
carName: string;
engine: string;
model: string;
year: number;
numOfLegs: string;
weight: number;
sound: string;
claws: boolean;
wingspan: string;
customerId: string;
}清楚地观察上面的界面。你可以看到它有太多的信息。如此多的职责使它变得过于宽泛，需要重构。这是一个神物。现在下面是上述问题的解决方案……
interface Car {
carName: string;
engine: string;
model: string;
year: number;
}
interface Animal {
numOfLegs: string;
weight: number;
sound: string;
claws: boolean;
}
interface Bird {
wingspan: string;
}
interface Transaction {
customerId: string;
}遵循单一职责和接口隔离原则来解决这种反模式。此外，请确保您经常进行代码审查并检测技术债务。
6. 复制粘贴编程
在对初级开发人员或实习生进行代码审查时，您可以轻松找到这种反模式的示例。初级开发人员或实习生缺乏开发经验，他们在构建某些功能或从头开始编写某些代码时面临困难。他们尝试从 StackOverflow、Github 或其他博客或视频等一些资源中复制和粘贴代码。他们将这些代码复制并粘贴到自己的文件中，而无需进行任何测试或影响分析。
这种反模式在您的软件中就像病毒一样，要解决此问题，您需要在复制代码的任何地方更改代码。发生这种情况是因为对循环结构、函数和子例程等基础知识缺乏了解。
你可以避免这种反模式 通过经常和仔细地进行代码审查。如果您在程序中实现该代码，则应正确测试代码并分析其影响。它应该由团队中的高级开发人员仔细审查和批准。此外，进行代码重构以将每个外观抽象为单个函数或方法。
结论
如果您在代码中看到反模式，请不要惊慌，也不要认为自己是一个糟糕的开发人员。犯错误会导致改进。对于软件中的大多数反模式，您会为所有这些反模式找到一个通用的解决方案，那就是……代码审查和代码重构。希望这篇文章对你收集一些关于反模式的信息有用。
如果您想阅读有关代码重构的更多信息，那么下面是一些对您有用的链接……
- 代码重构在软件开发中很重要的 7 个原因
- 软件工程中的 7 种代码重构技术