Python 设计模式——反模式

软件设计模式提供了一套规则或标准，能够帮助开发人员在设计层面进行决策。不良的设计主要表现在四个方面：

• 不动性：开发的应用程序非常难以重用
• 刚性：任何小的更改需求都会导致软件的太多部分必须进行相应的改动，牵一发而动全身
• 脆弱性：应用程序的任何更改都会导致现有系统变得非常容易崩溃
• 粘滞性：由于架构层面的修改非常困难，修改必须由开发人员在代码层面或环境本身中进行

软件开发反模式

在软件开发过程中，往往会偏离最初的代码结构，原因一般有：

• 开发人员的想法会随着开发过程的推进而发生变化
• 用例通常会随着客户的反馈而进行更改
• 最初设计的数据结构可能会随功能或可伸缩性等方面的考虑而发生变化

基于上述原因，软件通常需要进行重构。

意大利面条式代码

典型成因包括：

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

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

金锤

金锤的意思是一把锤子搞定所有的钉子（解决所有问题）。软件开发人员或团队通常会有一种倾向，一头扎进一个成熟的解决方案，而不管其是否满足适用性。

典型成因：

• 来自不了解具体问题的高层的建议
• 某解决方案在过去多次验证有效，但当前项目有不同的背景和要求
• 公司已被这种技术“绑架”，或员工们因为顺手对这种技术情有独钟

金锤的影响：

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

熔岩流

熔岩流与软件应用中的死代码或一段用不到的代码有关，人们害怕一旦对其进行修改就会破坏其他东西。随着时间的流逝，这段代码会一直留在软件中并固化其位置，就像熔岩变成硬岩一样。

熔岩流的成因：

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

熔岩流的症状：

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

复制粘贴式编程

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

• 多个软件应用存在同种类型的问题
• 维护成本更高，bug 的生命周期也会变得更长
• 较少的模块化代码库，相同的代码会散落于多处

软件架构反模式

重新发明轮子

• 缺乏中央文档或存储库来讲解架构级问题和存放已实现的解决方案
• 社区或公司内的技术领袖之间缺乏沟通
• 组织中遵循的流程是从头开始构建的

• 解决一个标准问题的方案太多，其中有许多考虑得并不周全
• 会耗费工程团队更多的时间和资源，导致预算超标，完成时间延后
• 封闭的系统架构、重复劳动和糟糕的风险管理

供应商套牢

• 熟悉供应商公司的权威人士以及技术采购的可能折扣
• 基于营销和销售业务人员而不是技术评估选择的技术
• 在当前项目中使用经过验证的技术，即使它不适合当前项目的需要
• 技术人员已经接受过相关技术的培训

• 公司产品的发布周期和维护周期直接取决于供应商的发布时间
• 该产品是围绕该技术而不是根据客户的要求开放的
• 产品上市时间不可靠，不能满足客户的期望

委员会设计

• 根据组织的流程，产品的架构或设计是由众多的利益相关者批准的
• 没有指定单独的联系人或负责设计的架构师
• 由营销或技术专家确定设计优先级，而不是客户反馈

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