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

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

源文: Modern Software Over-Engineering Mistakes

1. 工程师比业务人员更聪明

工程师认为自己是周围最聪明的人，因为他们做的创造性的工作。这第一个错误往往使得工程师过度设计。 但是，如果工程师已经计划做100件事情，业务人员总会想出第101件工程师从未想过的事情。 如果工程师解决了1000个问题，业务人员就会提出10000个问题。工程师认为自己 已经控制了一切，殊不知不知道是什么样的问题正在向他们走来。

在我15年的编码工作中，我从未见过任何一个企业在业务需求上是"趋同"的。业务只会不一样，这是业务的本质，不是业务人员的错。

总结 — 业务总是赢家

提示: 如果你没有时间去看整个帖子，那么上面这一点就足够了。

2. 可重复使用的业务功能

当业务人员不断地抛出越来越多的功能时，我们是这样看的：

我们尽可能地对业务逻辑进行分组和归纳。这就是为什么大多数 MVC 系统最终都会出现 Fat Models 或 Fat Controllers 的原因。 但是，正如我们已经看到的，业务需求只会不同，从来都不会趋同。

相反，我们应该这样看：

系统中的公共逻辑和抽象往往会随着时间推移而稳定下来。它们要么保持稳定，要么随着功能的扩大而相对下降。

例子：我们为以前的一个客户开发了一个用户档案系统。从一个具有公共功能的 CRUD 控制器开始，因为我们认为一切都将是相似的。 但是最后有13个不同的注册流程--最初的社交关系，第一次进入时的长长的注册表单，较小可编辑的页面部分， 完全不同的个人资料页面等等--以至于最后公共的东西的意义不大。 同样地，一个订单查看和订单编辑流程最终与实际的订购流程有着本质的区别。

尽量先纵向分割业务功能，再横向分割。这适用于所有情况--孤立的服务、基于主干的服务、特定语言的模块，等等。 也有助于轻松地从一种形式切换到另一种形式。否则，改变系统的一部分会变得越来越复杂。

总结 — 倾向于孤立而不是组合

3. 一切都是通用的

4. 浅包装

5. 把质量当作工具来运用

6. 过度使用适配器模式综合症

7. 非功能性需求

8. 内部“发明”

9. 顺应现状

10. 错误的估计

(全文完)