反模式简介
软件开发中不良设计主要有4个方面:
1、不动性: 以这种方式开发的应用程序非常难以重用.
2、刚性: 以这种方式开发的应用程序, 任何小的修改会导致软件的大多部分必须进行相应的改动.
3、脆弱性: 当前应用程序的任何更改都会导致现有系统变得非常容易奔溃.
4、粘滞性: 由于架构层面的修改非常困难, 因此修改必须由开发人员在代码或环境本身中进行.
反模式是处理重复出现问题的某些解决方案的后果. 假设你遇到了一个软件设计问题, 然后, 着手解决了这个问题. 但是, 该解决方案是否对设计产生负面影响, 或影响应用程序的性能? 因此, 反模式是应用软件中常见的有缺陷的过程的实现.
反模式产生的原因:
1、开发人员不了解软件开发实践.
2、开发人员没有将设计模式应用到正确的上下文中.
通过反模式我们可以实现以下目标:
1、识别软件行业中经常出现的问题, 并为其中的大多数问题提供详细的补救措施.
2、开发应用的工具来识别这些问题, 并确定其根本原因.
3、描述可用于应用程序和架构层次上的改进措施
反模式可以分为两大类:
1、软件开发反模式.
2、软件架构反模式.
02
软件开发反模式
在进行软件开发时, 往往会偏离最初的代码结构:
1、开发人员的想法会随着开发过程的推进而发生变化.
2、用例通常会随着客户的反馈而进行更改.
3、最初设计的数据结构可能会随功能或可伸缩性等方面的考虑而发生变化.
由于上述原因, 软件要进行重构. 虽然重构带有许多负面含义, 实际上, 重构是软件开发过程的关键部分之一. 为开发人员提供了一个机会重新评估数据结构, 并重新审视可扩展性和不断变化的客户需求.
我们将列举软件开发和架构中的几种反模式.
03
意大利面条式代码
这是软件开发中最"喜闻乐见"的反模式. 像意大利面条那样复杂. 如果以特殊的方式开发结构, 软件控制流也会变得错综复杂. 意大利面条代码是非常难以维护和优化的.
意大利面条式代码的典型成因包括:
1、对面向对象编程和分析的无知.
2、没有考虑产品的架构或设计.
3、快餐式思维.
意大利面条式代码会有如下问题:
1、结构的重用性将会降到最低.
2、维护工作量过高.
3、进行修改时, 扩展性和灵活性会降低.
04
金锤式代码
软件行业中, 由于某个解决方案(技术、设计或模块)在多个项目中效果不错, 所以就把它推广到更多的地方. 而团队或软件开发人员通常会有这样一种倾向: 一头扎进一个成熟的解决方案, 而不管其是否满足适用性. 这就是"金锤"这个名称的由来, 意思就是一把锤子搞定所有的钉子(解决所有问题).
出现金锤的原因有如下几个:
1、来自不了解具体问题的高层(架构师或技术领导)的建议.
2、虽然某解决方案在过去多次验证有效, 但当前项目却具有不同的背景和要求.
3、公司已经被这种技术"绑架了", 因为他们已经在它上面投资了大量资金来培训员工, 或员工们对这种技术情有独钟, 因为已经用顺手了.
金锤有如下影响:
1、痴迷于一个解决方案, 并把它应用于所有软件项目.
2、不是通过功能, 而是通过开发中使用的技术来描述产品.
3、你会在公司走廊中听到开发人员说"怎么可能比这个解决方案更好呢".
4、没有满足需求, 造成与用户的预期不符.
05
熔岩流式代码
这个反模式与软件应用程序中的死代码或一段用不到的代码有关, 人们害怕一旦对其进行修改, 会产生新的问题. 随着时间的流逝, 这段代码就像熔岩变成硬岩一样. 开发的软件是用来支持某个用例的, 刚开始没什么问题, 但若用例本身会随时间变化的话, 那么问题就会迎面而来了.
熔岩流形成的原因有:
1、产品中有大量的试错代码.
2、一个人单独写的代码, 未经审查, 直接移交给了其他开发团队.
3、软件架构或设计的初始思想是通过代码库实现的, 但没人能理解它.
熔岩流表现为:
1、开发的测试工作(如果完成的话)具有很低的代码覆盖率.
2、代码中含有莫名奇妙的注释.
3、过时的接口, 或开发人员需要围绕既有代码展开工作的.
06
复制粘贴或剪切粘贴式编程
这是常见的反模式之一. 许多经验丰富的开发人员将自己的代码放到网上, 从而为一些常见问题提供相应的解决方案. 这就导致了会有人原封不动的复制这些代码, 放在自己的应用程序中. 这就导致开发的软件应用程序缺乏灵活性, 同时变得难以维护.
导致这种现象的原因为:
1、新手开发不习惯写代码或不知道如何开发代码.
2、快速修复bug或"急就章"式的开发.
3、代码重复, 无法满足跨模块标准化以及代码结构化的要求.
4、缺乏长远打算或深谋远虑.
剪切粘贴或复制粘贴式编程的后果有:
1、多个软件应用程序存在同种类型的问题.
2、维护成本会更高, 同时bug的生命周期也会变得更长.
3、较少的模块化代码库, 相同的代码会散落于多处.
07
软件架构反模式
软件架构是整个系统架构的重要组成部分. 软件架构侧重于软件建模, 以便于开发和测试团队, 产品经理和其他利益相关者充分理解系统. 这个架构在软件的实现能否成功以及确定产品的工作方式方面发挥了关键作用.
08
重新发明轮子
"不要重新发明轮子", 这句话到底是什么意思呢? 对于一些人来说, 这可能意味着代码或库的重用. 实际上, 指的是架构的重用. 如你已经解决了一个问题, 并提出了一个架构级的解决方案. 如果你在其他应用程序中遇到了类似的问题, 那么就可以重用在此前开发过程中所形成的思维流程(即架构或设计). 重新审视相同的问题并为它重新设计解决方案并没有什么意义, 这就是重新发明轮子.
重新发明轮子原因如下:
1、缺乏中央文档或存储库来讲解架构级问题和存放已实现的解决方案.
2、社区或公司内的技术领袖之间缺乏沟通.
3、组织中遵循的流程是从头开始构建的, 通常情况下, 这样的流程是不成熟的, 并且流程的实现通常是不严谨的, 并且很难坚持.
这种反模式的后果如下:
1、解决一个标准问题的解决方案太多, 其中许多解决方案考虑的并不周全.
2、耗费工程团队更多的时间和资源, 导致预算超标, 上市时间延后.
3、封闭的系统架构(仅适用于一种产品的架构), 重复劳动和糟糕的风险管理.
09
供应商套牢
产品公司往往依赖于供应商提供的某些技术. 这些技术对于他们的系统来说如此密不可分, 以至于系统很难摆脱这些技术.
被套牢的原因:
1、熟悉供应商公司的权威人士以及技术采购的可能折扣.
2、基于营销和销售业务而不是技术评估选择的技术.
3、当前项目中使用经过验证的技术(验证表明, 使用此技术的投资回报率非常高) .
4、技术人员/开发人员已经接受过相关技术的培训.
被套牢的后果：
1、公司产品的发布周期和维护周期直接取决于供应商的发布时间.
2、该产品是围绕该技术而不是根据客户的要求开发的.
3、产品上市时间不可靠, 不能满足客户的期望.
10
委员会设计
有时, 根据组织中的流程, 一群人会坐在一起来设计特定的系统, 所得到的软件架构通常是复杂的或不合格的.
委员会设计的原因如下:
1、根据组织的流程, 产品的架构或设计是由众多的利益相关者批准的.
2、没有指定单独的联系人或负责设计的架构师.
3、由营销或技术专家确定设计优先级, 而不是由客户反馈来确定.
委员会有关的症状如下:
1、开发人员和架构师之间的观点冲突, 即使在设计完成后依旧如此.
2、过于复杂的设计, 很难记录.
3、规格或设计的任何改动都需要经过多次审查, 导致实现延迟.
