抽象是一个强大的工具。 一些最伟大的技术发明：操作系统、编程语言、编译器等都是基于抽象构建的。 但是，如果抽象被误用或误解，它们可能具有巨大的破坏性。

抽象

过度抽象会产生不可维护、不可测试的怪物。但抽象不足可能意味着重复的代码，但是重复的代码几乎总是比不可维护的代码好。

重复的代码可以通过重构来修复；但过度抽象的代码就有可能无法修复了。这就引出了一个问题：如果抽象不足是不好的，但仍然比过度抽象好，那么合适的抽象程度是怎样的呢？

多少抽象是必要的？

答案和像其他事情一样，取决于你所处的上下文环境。与抽象相关的上下文有三个主要组件:业务领域、团队和任务。

上下文对于抽象非常重要，因为某些业务领域需要抽象，但团队可能无法理解不同深度业务抽象。

这种情况在复杂业务领域很常见，或者一些刚从事开发的初级程序员或者对于转换行业的资深程序员，他们几乎没有或根本没有实际经验来理解对他们来说新的业务领域。

我们的系统将实现的任务也很重要，因为它存在于一个时间跨度内。 有些任务只持续一个月，而另一些则持续十年或二十年。

业务领域的影响

让我们首先看一下业务领域对抽象的影响。 每个业务领域都包含不同程度的复杂性。

业务领域知识

业务领域是指需要专业知识的工作。 它需要实际的业务领域知识，如：法律、医学、财税领域，或者像PDF文件格式。

抽象有助于将复杂性封装并包含到组件中去，从而让使用者不需要了解这其中的复杂性，把它当成黑盒。

如果你正在处理PDF，但不了解这个文件格式或PDF的结构，您可以使用一个开源库来显示它的结构并学习如何使用该文件格式。 这些抽象对于提高团队效率非常有用，但并不是免费的。

如果某些需求超出了现有库的功能范围，但问题仍需要解决，那么团队必须去了解所需的领域部分的知识。 在某些情况下，可能是整个领域，这就可能大大降低了他们在短期内创造价值的能力。

团队动力学

不同团队成员的才能、经验、技能和团队规模各不相同。 很多问题需要超出当前团队能力的抽象。

团队动力学

如果问题领域没有被执行团队完全或大部分理解，那么抽象就会被遗漏或被置于太低的层次而无法真正有效的工作。

问题被充分分析，且问题的复杂性、陷阱和问题领域都被足够的理解，这样才能确保选择有能力的团队来完成这项工作。

这也是为什么很多大公司通常有架构师来确保将工作分配给正确团队的原因之一。 如果一个团队或个人的能力不足，无法通过正确的抽象进行思考，就要将该人或团队与能够做到这一点的人或团队配对。

尽管如此，即使是“完美的团队”，第一次就完成一个伟大的抽象概念也是非常困难的。如果一个领域不被理解，预先做太多假设将导致一个有漏洞的抽象，甚至更糟：错误的抽象。

一次构建一个抽象片段通常是找到最适合所解决问题的抽象片段的最佳方式。 因此，让您的系统准备好迭代它包含的抽象是非常重要的。

一次构建一个抽象片段通常是找到最适合所解决问题的抽象片段的最佳方式。 因此，让您的系统准备好迭代它包含的抽象是非常重要的。

对于要解决的问题来说，最好的方式是一次只构建一个抽象片段。然后让你的系统准备好迭代演进抽象。

抽象的跨度

抽象可以持续数月或数年。如果你的公司正在执行一项任务，这个这个任务将持续10年，那么持久的抽象将有助于公司的发展。相反地，如果你正在尝试着创建一个大约需要一个月时间的原型，那么抽象就不那么重要了。

项目生命周期

为工作选择适当的抽象意味着要了解你正在从事的任务的上下文，以及这个抽象将要起作用的时间。

不正确地构建和使用太长时间的抽象会变得漏洞百出并且分散注意力，因为它们不再能很好的解决问题。以一种允许以后重构的方式来构建抽象是避免这种情况并确保最终选择最佳抽象的方法。

有很多很棒的设计模式就可以快速重构抽象，可以学习一下函数式和面向对象的设计模式。

维护所创建抽象的日志记录和创建背后的逻辑也很重要，这样在出现问题时就可以重新查看它们并进行重构。这将为以前的决策提供洞察力，并将有助于新的抽象。

抽象对于开发人员和团队的效率及有效性至关重要。合理调整决策并确保不断重新审视抽象，对系统的发展至关重要。

参考资料：

https://skiplist.com/insights/blog-software-principle-7-abstraction-why-underabstraction-is-almost-always-better