世界上所有东西的总量是在一直增加的:星体间的距离、宇宙中的平均信息量,还有该死的业务需求。很多文章都说过度技术设计是个不好的东西,但是它们却没说如何避免过度技术设计。下面10个症状说明你已经过度技术设计了。

2. 可重复使用的业务模块

当客户业务给我们提出越来越多的功能要求时,我们有的时候会这样反应:

我们会尽可能的进行归类,并且生成其中的逻辑。正是出于这个原因,MVC才会最终变成Fat Model或是Fat Controller。但是我们刚刚提到了,业务要求只会分岔,不会汇集。因此,我们的反应应该是这样的:

在自然系统中,通用的逻辑和抽象概念会随着时间逐渐趋于稳定。在功能变得更广泛的情况下,他们要么停留在扁平的状态,要么慢慢沉没。否则的话,系统的体积就会变得过大,导致各种错误的出现,在这种情况下,你就要对系统进行彻底的重写了。

例如,我们曾经给一个客户创建了用户资料系统。刚开始的时候,我们使用了CRUD控制器,以及通用的功能设计,因为我们觉得所有人的注册过程都是相似的。但是结果我们发现,用户有13种注册流程,这让我们使用的方法难以为继。

3. 所有东西都是通用的

想要连接数据库?写一个通用Adapter吧

对那个数据库进行Query?写一个通用的Query

要传递一些参数?通用参数

要架构参数?通用Builder

对反应进行Map? 通用Data Mapper

处理用户请求? 通用Request

执行整个系统? 通用Executor

有的时候工程师会对此过于着迷。我们会忘记解决商业问题,而是将是将浪费在寻找完美的抽象概念上

我们在设计的时候,总是要试图满足真实世界中不断变化的各种要求。因此,即使我们真的遇上了奇迹,摘到了完美的抽象画概念,它也会有不再适用的那一天,因为真实世界的要求变了。

4. 过于粗浅的封装

在 使用每一个外部库之前,我们都会把它包裹起来。不幸的是,我们所使用的大多数封装都非常粗浅。我们在投递功能性和编写好的封装之间挣 扎。我们的封装大多数情况下都与当前的库紧密结合。如果我们在未来改变了所使用的库,它所对应的封装也必须要改变。有的时候我们还会 把业务逻辑也放在这个封装内,这样导致我们即无法得到好的封装,也无法得到好的业务解决方案,而是介乎两者之间的某种粘性层。

现 在已经是2016年了,外部库和客户端都已经得到了快速的发展。OSS库就很好,它有着很高的质量,一些优秀的人写了很好的数据库。它们大多数都有着清 晰、可测试的API,让我们可以使用一种标准的Initialize — Instrument — Implement模式。

5. 将特性当做常用工具使用

盲目的使用特性概念(例如将所有变量变成“private final”、为所有类编写界面等)并不能让代码变得更好。

去看看Enterprise FizzBuzz吧。它有着体量极大的代码。在微层面上,每一个类都遵循了SOLID原色,使用了各种各样的优秀设计模式和变成技巧。它在CQM工具中获得了极高的代码质量评分。

5.1. 三明治层

我们来简要说明一下,创建一个结合紧密的反应,并且将其拆分为10或20个三明治曾,每一个单独的层面都需要整体架构来运行。

在过去,我们需要一个连锁反应来实现。A导致B导致C导致D……

而现在,我们还是在用这种方式,只不错我们给一个类都添加了界面/执行,然后将其注入下一个层面,因为我们现在有了SOLID。

但是SOLID这样的概念导致了连锁反应和其他OOP概念的滥用。大多数工程师都不知道这些概念是怎么来的,只是在不断的使用。

6. Adopter依赖综合征

在发现了Generics之后,现在,就连一个简单的“HelloWorldPrinter”都变成了“HelloWorldPrinter<String,Writer>”。

在数据类型如此明显的情况下,我们并不需要使用Generics。

在发现了策略模式后,连“if”条件都变成了一种策略。

为什么?

学会了DSL之后,我们在哪里都在使用DSL。

在用过Mocks之后,我们就对每一个对象进行模拟。

Metaprogramming真好用,我要在任何地方都使用。

这样做并不好。

7. <X>–ity

  • 可配置性
  • 安全性
  • 可扩展性
  • 可维护性
  • 可延伸性

 

实例1:我们来做一个可延展的CMS吧,负责商务的同事可以轻松的添加新的领域。

结果:负责商务的同事从来就没用过。当他们必须要添加新领域的时候,他们也会找来一名开发人员帮他们完成。也许我们需要的只是一个简单的开发者指导。

实例2:我们来设计一个拥有可配置性的大型数据库层面吧。我们应该拥有只用一个Magic文件就可以切换数据库的能力。

结果:近10年来,我只见过一家公司用过这样的功能。而在切换数据库的时候,那个Maigc文件并没有发挥什么作用。

实例3:我们来打造一个OAuth系统吧,让软件更具安全性。

结果:如果真的有人要黑我们的系统,他们不会经过OAuth层面,他们随便找一个其他曾的漏洞就黑进来了。

8. 内部“发明”

刚开始的时候你会感觉不错。但是今年之后,你的发明就会成为通用资源。例如:

内部库(HTTP, mini ORM/ODM, Caching, Config等)

内部框架(CMS, Event Streaming, Concurrency, Background Jobs, etc)

In-house tools (Buildchains, Deployment tools等)

9. 跟随现状

当某个东西按照某种特定方式部署完成之后,所有人都会在其基础上进行开发。没有人会质疑这种现状。只要代码能够工作,我们就默认这种方式为“正确的方式”。

有的时候现有的方式并不是最简洁的方式,有的东西完全是可以去除的。

10. 糟糕的自我评估

很多次我都见过非常优秀的团队做出糟糕的软件。在看到他们的代码库的时候,我们不禁在想:“怎么回事?这真实那个团队/人做的吗?”

优秀的质量不仅需要技巧,还需要时间。一个优秀的开发者总是会高估自己的能力,给自己定了不切合实际的开发截止日期,导致最终软件呈现的质量让所有人失望。

过分的自信在项目刚刚开始之前就会毁掉产品的最终质量。

余下全文(1/3)

本文最初发表在www.sdk.cn,文章内容属作者个人观点,不代表本站立场。

分享这篇文章:

请关注我们:

发表评论

电子邮件地址不会被公开。 必填项已用*标注