1. 反模式简介
1.不良设计的主要表现：
1.1 不动性：以这种开发的应用程序非常难以重用
1.2 刚性：以这种开发的应用程序，任何小的修改都会导致软件的太多部分必须进行相应的改动，所谓“牵一发而动全身”。
1.3 脆弱性：当前应用程序的任何更改都会导致现有系统变得非常容易崩溃。
1.4 粘滞性：由于架构层面的修改非常困难，因此修改必须由开发人员在代码或环境本身中进行。
2.导致原因：
2.1 开发人员不了解软件开发实践。
2.2 开发人员没有将设计模式应用到正确的上下文中。
3. 认识反模式的重要性
3.1 识别软件行业中经常出现的问题，并为其中大多数问题提供详细的补救措施。
3.2 开发相应的工具来识别这些问题，并为其中的大多数问题提供详细的补救措施。
3.3 描述可用于应用程序的架构层次上的改进措施。
4. 分类
4.1 软件开发反模式。
4.2 软件架构反模式。
2. 软件开发反模式
2.1 意大利面条式代码
2.1.1 成因
2.1.1.1 对面向对象编程和分析无知
2.1.1.2 没有考虑产品的架构或设计
2.1.1.3 快餐式思维
2.1.2 面临问题
2.1.2.1 结构的重用性将会降到最低
2.1.2.2 维护工作量过高
2.1.2.3 进行修改时，扩展性和灵活性会降低
2.1.3 示例
def a(i, j):
print('a')
h = b(c(5, j), d(6, 4, j), i, j)
if j >= 0:
return c(h, j)
else:
return 0
def b(e, f, i, j):
print('b')
if j >= 0:
return e + f - i
else:
return 0
def c(h, j):
print('c')
if j >= 0:
return b(2, 4, h, j)
else:
return 0
def d(e, d, j):
j -= 1
print('d')
if j >= 0:
return e - d * a(e + d, j)
else:
return 0
print(a(3, 100))
作者：菊叔
链接：https://www.zhihu.com/question/37791607/answer/276290304
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。2.2 金锤
一个方案想解决所有的事情。
2.2.1 成因
2.2.1.1 来自不了解具体问题的高层的建议
2.2.1.2 虽然某解决方案在过去多次验证有效，但当前项目缺具有不同的背景和要求。
2.2.1.3 公司已经被这种技术“绑架了”，人员资金已经大量投入，技术人员对此技术顺手
2.2.2 面临问题
2.2.2.1 痴迷于一个解决方案，并把它应用于所有软件项目
2.2.2.2 不是通过功能，而是通过开发中使用的技术来描述产品
2.2.2.3 你会在公司走廊中听到开发人员说“怎么可能比这个解决方案更好呢”
2.2.2.4 没有满足需求，造成与用户的预期不符。
2.3 熔岩流
软件中用不到的代码
2.3.1 成因
2.3.1.1 产品中的大量试错代码
2.3.1.2 一个人单独编写的代码，未经审查，就在没有任何培训的情况下移交给了其他开发团队
2.3.1.3 软件架构或设计的初始思想是通过代码库实现的，但没有人能理解它
2.3.2 面临问题
2.3.2.1 开发的测试工作具有很低的代码覆盖了
2.3.2.2 代码中含有莫名其妙的注释
2.3.2.3 过时的结构，或开发人员需要围绕既有代码展开工作
2.4 复制黏贴或剪贴黏贴式编程
2.4.1 成因
2.4.1.1 新手开发者不习惯编写代码或不知道如何开发代码
2.4.1.2 快读修复bug或紧急式开发
2.4.1.3 代码重复，无法满足跨模块标准化以及代码结构化的要求。
2.4.1.4 缺乏长远打算或深谋远虑
2.4.2 面临问题
2.4.2.1 多个软件应用程序存在同种类型的问题
2.4.2.2 维护成本更高，同时BUG的生命周期也会变得更长
2.4.2.3 较少的模块化代码库，相同的代码会散落于多出
2.4.2.4 继承问题
3.软件架构反模式
3.1 重新发明轮子
架构不进行重用
3.1.1 成因
3.1.1.1 缺乏中央文档或存储库来解决架构级问题和存放已实现的解决方案
3.1.1.2 社区或公司内的技术领袖之间缺乏沟通
3.1.1.3 组织中遵循的流程是从头开始构建的，通常情况下，这样的流程是不成熟的，并且流程的实现通常是不严谨的，并且很难坚持。
3.1.2 面临问题
3.1.2.1 解决一个标准问题的解决方案太多，其中许多解决方案考虑的并不周全。
3.1.2.2 会耗费工程团队更多的时间和资源，导致预算超编，上线时间延后。
3.1.2.3 封闭的系统架构，重复劳动和糟糕的风险管理
3.2 供应商套牢
产品过度依赖供应商提供的某些技术。
3.2.1 成因
3.2.1.1 熟悉供应商公司的权威人士以及技术采购可能折扣。
3.2.1.2 基于营销和销售业务而不是技术评估选择的技术。
3.2.1.3 在当前项目中使用经过验证的技术，即使它并不适合当前项目的需要或要求。
3.2.1.3 技术人员、开发人员已经接受相关技术的培训。
3.2.2 面临问题
3.2.2.1 公司产品的发布周期和维护周期直接取决于供应商的发布时间。
3.2.2.2 该产品是围绕该技术而不是根据客户要求开发的。
3.2.2.3 产品上线时间不可靠，不能满足客户的期望。
3.3委员会设计
根据组织中的流程，一群人坐在一起来设计特定的系统，所得到的软件架构通常是复杂的或不合格的
3.3.1 成因
3.3.1.1 根据委员会流程，产品的架构或设计是由众多的利益和相关者批准的。
3.3.1.2 没有指定单独的联系人或负责设计的架构师
3.3.1.3 由营销或技术专家设定优先级，而不是由客户反馈来确定
3.3.2 面临问题
3.3.2.1 开发人员与架构师之间的观点冲突，即使在设计完成后依旧如此
3.3.2.2 过于复杂的设计，很难记录。
3.3.2.3 规格或设计的任何改动都需要经过多次审查，导致实现延迟。
本系列项目代码地址：Python-design-pattern
