web开发编码_Web开发：必须避免的10种编码反模式

设计网站或应用程序的体系结构，或建立有效的编码工作流程通常会使我们处理重复出现的问题。 我们不必从头开始解决这些软件设计问题，因为架构级别的解决方案可以像微级别的代码片段一样重用 。

尽管设计模式是通过使用久经考验的公式来改善我们的开发过程的绝佳手段，但有时我们也可能会犯错。 这些被称为反模式。

什么是反模式？

“反模式”一词是在1998年的一本名为《反模式》的书中提出的。它指的是重用的解决方案，这些解决方案最初似乎有用 ，但后来却弊大于利。

发生这种情况的原因可能多种多样，例如，如果我们没有在正确的上下文，设置或时间中使用这些模式（过去有效的解决方案在当前可能并不总是有效的），或者在其他情况下，则是整个范式从一开始就很糟糕。

反模式通常也称为失败模式 。 好消息是可以识别和避免它们 。

在本文中，我们将介绍Web开发中的10种常见编码反模式，这可能会让我们误以为我们拥有经过优化的代码。 （请注意，本文中列出的反模式不一定与上述书籍中的反模式相同。）

1.过早的优化

良好的时序是代码优化中的关键因素。 如果我们关注小的效率并在开发过程中过早地对它们进行优化，那么在我们完全不知道要做什么之前，我们可以轻松地复制“过早优化”的反模式。

根据唐纳德·克努斯 （ Donald Knuth ）的名言“ 过早的优化是万恶之源 ”，这也许有些夸张，但仍然表明过早的优化会在以后引起严重的问题。

如果我们在建立有效的体系结构之前针对性能进行优化，则可能会降低代码的可读性 ，使调试和维护更加困难 ，并在代码中添加多余的部分 。

为了防止过早的优化，最好遵循YAGNI（您不需要）编程原则，该原则建议“始终在实际需要时执行事情，永远不要在仅预见到需要时就执行。”

2.重塑车轮

有时也将“重塑车轮”反图案称为“真空设计” 。 当我们想要自己做所有事情并从头开始编写所有内容而又不寻找已经存在的方法，API或库时，就会发生这种情况。

重新发明轮子不仅是浪费时间，而且自定义解决方案（尤其是针对基本功能的解决方案）很少像许多开发人员和用户已经测试过的标准解决方案那样好 。

3.依赖地狱

“重塑车轮”反模式的反面是另一种常见的反模式，称为“依赖地狱” 。

如果我们使用太多依赖于其他库特定版本的第三方库而不是从头开始编写所有内容，则当我们要更新时，我们很容易遇到难以管理的情况，因为这些子依赖关系在许多情况下与彼此 。

依赖关系地狱可以通过使用能够智能更新相互依赖关系的程序包管理器来解决。 如果我们对此问题不知所措，那么重构也是一个好主意。

4.意大利面代码

“意大利面条式代码”可能是最著名的编码反模式。 它描述了由于缺乏适当的体系结构而难以调试或修改的应用程序 。

软件设计不佳的结果是产生了一堆代码，这些代码在结构上类似于一碗意大利面条，即缠结和盘绕 。 意大利面条代码的可读性很低，通常很难理解它的工作原理。

Spaghetti代码通常源于各种不良编码做法的组合 ，例如，代码不包含适当的条件块，具有许多goto语句，异常和线程，其中包含属于其他位置的部分，对象之间的关系最少，具有功能或不能重用，或者没有正确记录或根本没有记录的方法。

5.排列编程

当我们尝试通过依次进行小修改，逐个测试和评估并最终实施一个可行的方法来找到问题的解决方案时，就会发生“ 按置换编程”或“意外编程”的情况。

通过置换编程可以轻松地将新错误引入我们的代码中 ，更糟糕的是，它们是我们不一定立即识别的错误。 在许多情况下，也无法预测该解决方案是否适用于所有可能的方案。

6.复制和粘贴编程

当我们不遵循“ 不要自己重复”（DRY）编码原则时，就会发生“复制和粘贴编程” ，而不是创建通用解决方案，而是将现有的代码段插入不同的位置，然后对其进行编辑以适合给定上下文。

这种做法导致代码具有高度重复性 ，因为插入的代码部分通常仅在微小差异上有所不同。

复制和粘贴编程不仅由新手开发人员负责，而且由经验丰富的程序员负责，因为他们中的许多人倾向于使用自己编写的，经过良好测试的代码段来完成特定任务 ，这很容易导致意外的重复 。

7.货物崇拜编程

“货物崇拜编程”的名称来自一种特殊的民族志现象，即“货物崇拜”。 在第二次世界大战之后，南美洲的货物崇拜者出现了，当时与先进文明的强迫接触使当地人认为，制成品，如可口可乐，电视和由货船运到该岛的冰箱，是超自然的创造的。方法; 如果他们执行类似于西方人习俗的魔术仪式，装满货物的货物将再次出现。

当我们提交货物崇拜编程的反模式时，我们基本上会执行相同的操作。 我们使用对其他用户有效的框架，库，解决方案，设计模式等， 而不了解我们为什么这样做或上述技术如何正常工作。

在许多情况下，开发人员只是习惯性地做当时没有真正目的的事情 。 这种做法不仅不好，因为它会使我们的应用程序变得多余，而且还很容易将新的错误引入我们的代码中。

8.熔岩流

当我们需要处理包含冗余或低质量部分的代码时，我们谈论“熔岩流”反模式， 而这些部分 似乎是程序不可或缺的，但我们还不完全了解它的作用或如何影响整个应用程序。 这使得删除它有风险。

通常在遗留代码中发生，或者在其他人编写代码 （通常没有适当的文档 ）时发生，或者当项目从开发阶段快速过渡到生产阶段时，通常会发生这种情况。

反模式的名称源于它与火山熔岩的相似之处，即，起初它在没有采取过多预防措施的情况下快速，流畅地运动，但后来凝固并变得难以去除。

从理论上讲，我们可以通过大量的测试和重构来摆脱熔岩流，但是在实践中， 实现通常是困难的，甚至是不可能的 。 由于熔岩流通常会带来较高的性能成本，因此最好从一开始就建立一个设计良好的架构和完善的工作流程来防止熔岩流流失。

9.硬编码

“硬编码”是一种众所周知的反模式，大多数Web开发书籍都在序言中警告我们。 硬编码是一种不幸的做法，在这种做法中， 我们将配置或输入数据 （例如文件路径或远程主机名）存储在源代码中，而不是从配置文件，数据库，用户输入或其他外部源中获取它。 。

硬代码的主要问题是， 它只能在特定环境中正常工作 ，并且在任何情况下 ， 只要 条件发生变化 ， 我们通常都需要在多个单独的位置修改源代码。

10.软编码

如果我们尽力避免硬编码的陷阱，那么我们很容易碰到另一种称为“软编码”的反模式，这与它完全相反。

在软编码中， 我们将应包含在源代码中的内容放入外部源中 ，例如，将业务逻辑存储在数据库中。 我们这样做的最常见原因是担心业务规则将来会更改，因此我们需要重写代码。

在极端情况下，软编码程序可能变得如此抽象和复杂，以至于几乎不可能理解它 （尤其是对于新的团队成员），并且很难维护和调试 。

翻译自: https://www.hongkiat.com/blog/code-optimization-coding-antipatterns/