十一、反模式

这章讨论反模式

本章主题

• 反模式简介
• 反模式示例
• 开发过程中常见的陷阱

1. 反模式简介

不良设计主要表现在4个方面：

• 不动性：代码难以重用。
• 刚性： 代码改动影响很多，“牵一发而动全身”。
• 脆弱性： 系统容易崩溃。
• 粘滞性： 由于架构层面的修改非常困难，因此修改必须由开发人员在代码中进行。

反模式，是应用软件中常见的有缺陷的过程和实现。

反模式出现的原因：

• 开发人员不了解软件开发实践。
• 开发人员没有将设计模式应用到正确的上下文中。

反模式可以分为两大类：

• 软件开发反模式。
• 软件架构反模式。

2. 软件开发反模式

首先需要考虑代码的结构。
由于需求的变更、功能的扩展、开发人员的想法等等因素，代码的整体结构会发生变化。
基于上述原因，软件通常需要进行重构。

2.1 意大利面条式代码

错综复杂，非常难以维护和优化。

成因：

• 对面向对象编程和分析的无知；
• 没有开发产品的架构或设计；
• 快餐式思维。

面临的问题：

• 结构的重用性将会降到最低；
• 维护工作量过高；
• 进行修改时，扩展性和灵活性会降低。

2.2 金锤

妄想一把锤子搞定所有的钉子（解决所有问题）

成因：

• 来自不了解具体问题的高层的建议；
• 当前项目具有特殊性，不适用原来那套成熟的方案；
• 公司被这种技术“绑架”，培养了大量这种技术员。

金锤的影响如下所示：

• 痴迷与一个解决方案，并把它应用于所有软件项目。
• 不是通过功能，而是通过开发中使用的技术来描述产品。
• 没有满足需求，造成与用户的预期不符。

2.3 熔岩流

有些死代码或用不上的代码，人们害怕一旦对其修改，就会破坏其它东西。
随着时间流逝，这段代码一直留在软件中并固话器位置，就像熔岩变成硬岩一样。

成因：

• 在产品中有大量的调试代码；
• 一个人单独编写的代码，未经审查，在没有交代情况下移交给其他开发团队；
• 软件架构的思想是通过代码库来实现的，但没有人能理解它。

症状：

• 开发的测试工作具有很低的代码覆盖率。
• 代码中含有莫名奇妙的注释。
• 过时的接口，或开发人员需要围绕既有代码开展工作。

复制粘贴式编程

从网络上（GitHub或Stackoverflow）原封不动复制代码应用于自己的程序。

成因：

• 新手开发者不习惯编写代码或不知道如何开发代码；
• 快速修复Bug 或“急就章”式的开发；
• 代码重复，无法满足跨模块标准化以及代码结构化的要求。
• 缺乏长远打算或深谋远虑。

后果：

• 多个软件程序存在同种类型的问题；
• 维护成本更高，同时Bug 的生命周期更长；
• 较少的模块化代码库，相同的代码会散落于多处；
• 继承问题。

3. 软件架构反模式

侧重于软件建模

3.1 重新发明轮子

成因：

• 缺乏文档或存储库，没有找到已实现的解决方案；
• 缺乏沟通；
• 组织中遵循的流程是从头开始构建的。

后果：

• 解决方案多，但考虑不全面；
• 耗费工程团队更多的时间和资源；
• 封闭的系统架构、重复劳动和糟糕的风险管理。

3.2 供应商套牢

过于依赖供应商提供的技术

成因：

• 供应商的权威或折扣；
• 基于营销和销售业务而不是技术评估选择的技术；
• 在当前项目经过验证的技术，但满足不了其他需求；
• 技术人员已经接受或相关技术的培训。

后果：

• 依赖供应商的发布时间；
• 该产品是围绕技术开发而不是客户；
• 产品上市时间不可靠，不能满足客户的期望。

3.3 委员会设计

成因:

• 软件架构由众多利益相关者决定；
• 没有指定单独负责设计的架构师；
• 由营销或技术专家确定设计优先级，而不是客户反馈。

后果：

• 开发人员和架构师之间的观点冲突，即使在设计完成后依旧如此；
• 过于复杂的设计，很难记录；
• 规格或设计的任何改动都需要经过多次审查，导致实现的延迟。

4. 小结

了解了反模式的定义及其分类。反模式与软件开发或软件架构密切相关。
必须从中吸取教训，从而避免在自己的项目中出现类似的情况。