十个现代软件过度工程的错误

16-10-17 banq
世界很少有东西是随着时间一直增加的,这些稀有之物包括:恒星之间的距离,在可见宇宙中的熵,和业务需求。许多文章说不要过度工程,但没有说为什么以及怎样做到。这里有10个清晰案例告诉你这些细节。

1.软件工程比业务更加聪明

工程师们往往认为自己是最聪明的人。这第一个错误往往容易导致过度工程。假如我们计划了100件事,业务将永远会是第一百零一件事,也就是你从来没有想到过的。如果我们解决了1000个问题,他们会再有10000个问题。我们认为,我们已经控制了一切,其实 - 但我们不知道我们在干什么。

业务需求是发散,他们永远不会凝聚

发散是业务的自然本质,不是业务人员自己的错。

2.业务功能的可重用

我们尽可能的尝试对业务逻辑进行抽象分组和概括。这就是为什么大多数MVC系统最终会变成胖肪控制器或胖模型原因。但正如我们已经看到的,业务需求是发散,他们永远不会凝聚。

在自然系统中,共享的逻辑和抽象随着时间的推移倾向于稳定。随着功能越来越广他们要么保持持平或相对下降。如果不顺这个自然之势,而是主观往相反的情况去“作”时,就会创建太大而不能失败的系统(导致可怕的重写)。

案例:我们为前一个客户创建了一个用户配置文件系统。开始CRUD控制器是共享其功能的,因为我们以为一切都是相似的。但最终有13个不同的注册流程 - 开始是社交账户连接,而第一次进入时需要一个漫长的注册表单,这些都是看上去完全不同的页面等等,最终控制器共享已经变得没有任何意义,从而导致共享终结。

在水平拆分业务之前先尝试垂直拆分业务功能。这适合所有的情况下 - 隔离服务,基于主干的服务,特定的语言模块等,也有助于轻松从一种形式到另一种。否则,系统会变得越来越复杂以至于难以改变。

先隔离才能组合

3.每件事都是通用

要连接到数据库吗?让我们写一个通用适配器;

查询数据库?通用查询;

传递参数?通用参数;

构建参数?通用的构建器;

映射响应?通用的数据映射器;

处理用户请求?通用的请求;

要求执行整个事情?通用的执行者;

等等

有时工程师们会被业务问题带着走。而不是试图解决业务问题,这种试图找到完美的抽象实际是在浪费时间。

重复胜于错误的抽象

恰恰相反,重复有时是正确抽象的关键。因为只有当我们看到系统的许多部分共享“相似”的代码时,一个更好的共享抽象才会出现。抽象的质量是最薄弱的环节。重复暴露许多用例,使边界更清晰。

4.浅显的封装

这是这篇文章中最难的一个问题。

将一个外部库包在使用之前进行封装是常做的事情,实际大部分我们这种封装是很浅显的,我们总是挣扎于保证功能能够实现以及封装又要足够好之间。所以我们的封装大多是紧密与基础底层库耦合。如果我们以后改变底层库,封装器wrapper通常也会被改变。有时我们也把业务逻辑混合到封装器中,使它既不是一个好的封装也不是一个好的业务解决者,不伦不类。

开源软件库是神奇的。他们有很高的质量和可怕的人写的专门的测试代码库,他们是集中时间专门编写。大多数都是明确的、可测试的、真正有作用的API,允许我们遵循标准模式:初始化 - 准备- 实施。

封装是异常,而不是规范常必的。不要为了封装而封装好的库包,因为这些库包已经哟足够好的API

5.将无形的质量作为有形的工具

盲目应用质量概念(如改变所有的变量到“private final”,为所有类写一个接口等)反而不会让代码变得更好。

看看企业编程FizzBuzz,它有大量微观层面的代码。每个类遵循SOLID原则,采用各种设计模式(工厂、建筑、策略等)和编码技术(泛型、枚举等)。它从CQM工具获取高代码质量评级。

但如果我们退后一步,才能看到宏观。

自动化CQM工具跟踪测试覆盖率是好的,但不能告诉我们是否正确测试了。一个基准工具可以跟踪性能,但不能判断它是并行或顺序运行。人必须看大局。

学习一种不同的语言,尝试以另一种思维方式做事情。这从根本上促进开发人员更好。但是不能新瓶子装旧酒。我们永远不需要用一个概念的名称来撕裂一个清晰的设计。

6.过度热心综合症

如果明显的一个问题可以由特定的数据类型处理,或当正常类型的签名已经足够,就不要使用泛型。

发现策略模式,将每个if条件变成策略?

先问问自己为什么这么过度热心?

发现如何编写DSL,将DSL到处应用?

等等。

7.<X>–ity

可配置性

安全性

可扩展性

可维护性

可扩展性

这些目标很好,很难反驳。

但是,问自己一个简单问题,业务案例的上下文场景是什么?然后深入挖掘,这暴露了在大多数预先主观设计的缺陷。

8.关在房间里的发明

关在房间自己搞自己的专门发明,开始感觉很酷。

1.In-house库包 (HTTP, mini ORM/ODM, Caching, Config)

2.In-house 框架 (CMS, Event Streaming, Concurrency并发, Background Jobs后台任务)

3.In-house 工具 (Buildchains, 部署工具)

最终这些闷在房间搞的软件框架虽然开源了,但是自己公司却不再使用,别人因为其公司名声大反而盲目采用这些专有发明,掉入大坑。

还有两个错误见原文:

10 Modern Software Over-Engineering Mistakes – Med

              

1
猜你喜欢