Course 模块 3 - Lecture: 反模式

反模式简介

反模式与模式完全相反。回想一下，设计模式是良好编程实践的示例，即用于解决某些问题的模式。但反模式是它们的完全对立面，即在解决各种问题时所犯错误的模式。

良好编程实践的一部分恰恰是避免反模式。不要认为这是一个难以理解的理论垃圾——这些是几乎每个开发人员都遇到过的具体问题。谁知道，他有武器！

让我们看一下初学者中常见的一些反模式：

幻数是代码中用于某些事物（通常是数据标识）的常量，如果没有相应的注释，其数字本身没有任何意义。数字绝对没有语义。

当数字开始出现在你的项目代码中时，其含义并不明显，这是非常糟糕的。不是此类代码作者的程序员将难以解释其工作原理。久而久之，连魔数代码的作者都解释不清了。

数字使代码难以理解和重构。造成这个错误的主要原因是开发仓促，缺乏编程实践。通过在开始开发之前规定数字常量的使用，应该将这种反模式消灭在萌芽状态。

要解决这个问题，您需要创建一个变量，其名称解释数字常量的用途，并为其分配所需的值。

divine object是一种反模式，在 OOP 开发人员中很常见。这样的对象承担了太多的功能和/或存储了几乎所有的数据。结果，我们有一个不可移植的代码，而且很难理解。

此外，这样的代码很难维护，因为整个系统几乎完全依赖于它。出现此错误的原因：开发人员能力不足，一个开发人员承担了大部分工作（尤其是当工作量超过该开发人员的经验水平时）。

有必要通过将任务分解为不同开发人员可以处理的子任务来处理这种方法。

过早的优化是在程序员获得关于在哪里以及如何做的明智决定所需的所有信息之前执行的优化。

实际上，很难预测哪里会出现瓶颈。在获得实证结果之前尝试优化会导致代码复杂和错误的出现，但不会带来任何好处。

如何避免？首先，使用众所周知且经过验证的算法和工具编写干净、可读、有效的代码。如有必要，使用分析工具查找瓶颈。依靠测量，而不是猜测和假设。

在分析之前缓存。使用复杂且未经证实的启发式方法而不是数学上正确的算法。精选的新的、未经测试的框架可能在负载下表现不佳。

确定优化何时为时尚早并不容易。提前预留成长空间很重要。您需要选择能够轻松优化和发展的解决方案和平台。有时过早的优化也被用作错误代码的借口。例如，他们采用 O(n2) 算法只是因为该算法会更难 O(n)。

这种反模式的意思是程序员开发自己的解决方案来解决已经存在的问题，而且通常是更成功的解决方案。

开发人员认为自己更聪明，因此他尝试为每项任务提出自己的解决方案，尽管他的前辈有经验。大多数情况下，这只会导致时间的浪费和程序员效率的降低。毕竟，即使找到解决方案，也可能不是最佳解决方案。

当然，你不能完全放弃独立解决方案的可能性，因为这会导致直接复制粘贴编程。开发人员必须导航可能出现在他面前的任务，以便胜任地解决它们，使用现成的解决方案或发明自己的解决方案。

很多时候，出现这种反模式的原因很简单，就是没时间。时间就是金钱。

这种反模式与简单地重新发明轮子密切相关——当存在更好的解决方案时创建你自己的糟糕解决方案。

这种反模式需要两倍的时间：首先，时间花在发明和实施你自己的解决方案上，然后是重构或替换它。

程序员必须了解针对特定任务范围的各种解决方案的存在，并以它们的优缺点为指导。

作为程序员，你将面临的所有问题都可以分为两部分：

大多数编程问题在您出生之前就已成功解决。无需发明任何东西 - 只需研究其他人的经验（这就是写书的目的）。

2022年，我们可以庆祝以下生日：

编程语言
- C 语言 50 周年（1972 年）
- Java 语言 27 周年（1995 年）
- Python 31 岁生日 (1991)
联系
- 互联网 39 周年 (1983)
- 手机满49岁（1973年）
- 30 年前（1992 年）发送了第一条短信
图案
- MVC 模式诞生 44 周年（1978 年）
- SQL 发明于 48 年前（1974 年）
- 26 年前（1996 年）发明了 Java Beans
图书馆
- Hibernate 发明于 21 年前（2001 年）
- Spring 是 20 年前发明的（2002 年）
- 23 年前发布的 Tomcat（1999 年）
操作系统
- Unix 发布 51 年前（1971 年）
- Windows 诞生于 37 年前（1985 年）
- 21 年前（2001 年）发布的 Mac OS

所有这些东西不仅仅是发明出来的，它们是作为解决当时非常普遍和相关问题的解决方案而开发的。