前言
反模式不同于设计模式，它是说明软件设计或开发的时候不应该做什么，换言之，应该尽量避免的事。
1. 反模式简介
软件设计有一些不良设计的主要表现：
- 不动性：以这种方式开发的应用程序非常难以重用。
- 刚性：以这种方式开发的应用程序，任何小的修改都会导致软件的太多部分必须进行相应的改动。
- 脆弱性：当前应用程序的任何更改都会导致现有系统变得非常容易崩溃。
- 粘滞性：由于架构层面的修改非常困难，因此修改必须由开发人员在代码或环境本身中进行。
反模式是处理重复出现问题的某些解决方案的后果，是应用软件中常见的有缺陷的过程和实现。
2. 反模式的分类
- 软件开发反模式
- 软件架构反模式
3. 软件开发反模式
意大利面条式代码：代码错综复杂，非常难以维护和优化。影响如下：
- 结构的重用性将会降到最低。
- 维护工作量过高。
- 进行修改时，扩展性和灵活性会降低。
金锤：由于某个解决方案（技术、设计或模块）在多个项目中效果不错，所以就把它推广到其他场景，但不管其是否适用，一锤子搞定所有，那就 是金锤。影响如下：
- 痴迷于一个解决方案，并把它应用于所有软件项目。
- 不是通过功能，而是通过开发中使用的技术来描述产品。
- 没有满足需求，造成与用户的预期不符。
熔岩流：这个反模式与死代码或一段用不到的代码有关，人们怕修改了会影响到其他东西就一直留着，最终固化了。熔岩流的症状如下：
- 开发的测试工作（如果完成的话）具有很低的代码覆盖率。
- 代码中含有莫名其妙的注释。
- 过时的接口，或开发人员需要围绕既有代码展开工作。
复制粘贴式编程：不考虑代码是否最大程度地优化，不考虑是否适合场景，直接复制粘贴使用。后果如下：
- 多个软件应用程序存在同种类型的问题。
- 维护成本会更高，同时bug的生命周期也会变得更长。
- 较少的模块化代码库，相同的代码会散落在多处。
- 继承问题。
4. 软件架构反模式
重新发明轮子：是指架构层面上的。之前已经针对一个问题提出了架构级的方案，再次遇到类似的问题又要重新设计方案，这没有必要。后果 如下：
- 解决一个标准问题的解决方案太多，许多方案考虑并不周全。
- 耗费工程团队更多的时间和资源，导致预算超标，上市时间延后等。
- 封闭的系统架构（仅适用于一种产品的架构）、重复劳动和糟糕的风险管理。
供应商套牢：产品公司依赖于供应商提供的某些技术，这些技术与系统密不可分，导致系统很难摆脱。后果如下：
- 该产品是围绕该技术而不是根据客户要求开发的。
- 产品上市时间不可靠，不能满足客户的期望。
委员会设计一群人在一起设计特定的系统，所得到的软件架构通常是复杂的或不合格的。症状如下：
- 开发人员和架构师之间的观点冲突，即使设计完成后依旧如此。
- 过于复杂的设计，很难记录。
- 规格或设计的任何改动都需要经过多次审查，导致延迟。
后记
小结一下：
- 反模式的定义。
- 反模式的两种分类：软件开发反模式、软件架构反模式。
设计模式暂时就到这里，接下来想整一点web安全、Linux编程基础和算法，可能会穿插着写吧。
