“警惕！过度抽象的代码库，是开发者看不见的隐形噩梦”

【CSDN 编者按】在软件开发的世界里，抽象是一个强大的概念，它允许我们创建更干净、更模块化的代码结构。而本文作者指出，虽然抽象旨在简化并提高代码的可复用性和灵活性，但如果不加节制地追求“完美”的抽象层次，反而会引入不必要的复杂性，使代码难以理解和维护。

原文链接：https://itnext.io/what-are-the-hidden-costs-of-over-abstracting-your-codebase-8b6a8ab0ab2b

作者 | Maxime     翻译 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

抽象本身看起来像是一种超能力，但前提是它还奏效的时候；而过度抽象就像是把一个简单的礼物包装得层层叠叠，结果没人能打开它——包括你自己。

几乎每个开发者都喜欢干净、可重用的代码。我曾多次陷入过度抽象的“深渊”中，而事实证明，过度抽象并不像听起来那么光鲜亮丽。

在本文中，我将分享我对“完美抽象”的痴迷是如何适得其反的，为什么这会让我的项目变得更难（而不是更好），以及应该如何避免犯下同样的错误。

复杂度：从简单变得混乱

在我的职业生涯早期，我有一个“绝妙”的想法：创建一个通用的 API 客户端，它可以处理每个服务的所有请求类型。

当时我的想法是，为什么要给每个端点都写一个新函数呢？我们完全可以创建一个能动态构建 URL、参数和负载的函数，来一次性解决。

听起来简直是天才之举，对吧？其实不然：六个月后，我的“杰作”变成了一场维护噩梦。

每次有新的服务提出有些不同的需求——比如需要某个特定的头部信息或独特的响应格式——我就必须在抽象层添加更多的条件逻辑。最终，它变得超级臃肿，我每调试一个失败的请求，感觉就像在拆炸弹一样困难。

最讽刺的是，我团队中的一位初级开发人员曾问我：“为什么不为每个服务分别写单独的函数呢？”当时我笑了笑敷衍过去，但内心深处，我知道他说得对。

教训总结：过度抽象并不会简化问题，它只是将复杂性隐藏在了层层叠加的外壳之下。当这些层次累积起来时，你的代码就会变得难以驾驭。

性能瓶颈：抽象还会拖慢速度

在一个项目中，我抽象了一个前端表单生成器。它可以根据模式动态地生成输入字段：文本框、下拉菜单、复选框等等，应有尽有。

原本，我对此感到非常自豪——直到 QA 报告指出该表单在较慢的设备上加载需要三秒钟。

为什么会这样？每个字段都要经过一个复杂的工厂模式来初始化组件、处理验证规则并触发不必要的重新渲染。

我花了好几天时间进行代码性能分析和优化，而回过头来看，那些代码根本不必存在。如果我只是为这个特定的表单硬编码字段，那么半个小时就能搞定，而且不会出现任何性能问题。

教训总结：抽象不是“免费”的。你添加的层数越多，越容易引入低效的部分从而影响性能。

上手困难：吓跑新开发者

几年前，我加入了一个项目，项目中的所有东西——没错，就是字面意义上的“所有”东西——都进行了抽象。

模型有它们接口的接口；服务调用工厂，工厂又调用其他工厂；即使是更新一个简单的用户资料，也需要深入探究复杂的抽象层。

我花了几周时间才适应过来。每当我问“这个功能的逻辑在哪里？”时，得到的回答往往是：“哦，它分布在三层抽象中以保证灵活性。”

……这种所谓的灵活性是为了什么？项目变得如此复杂僵化，想添加个新功能都像在一座纸牌屋上做手术般小心翼翼。

教训总结：过度抽象不仅会拖慢你的速度，还会劝退你的团队成员。下一个接手你代码的开发者大概率会在心里咒骂你，这也完全是可以理解的。

僵化：极度追求灵活性的结果

过度抽象最讽刺的地方是什么？它本应让你的代码更灵活，实际上却常常带来相反的效果。

记得有一次我参与了一个数据管道项目，该项目被抽象为可以处理“任何类型的转换”——听起来很棒，直到客户要求了一个不符合该抽象的自定义特性。

我本可以直接添加这个功能，最终却不得不重构整个管道，以使其兼容。最终，这个抽象扭曲得几乎不像是原来的设计。更糟糕的是，我浪费了几周时间去做本应在几天内完成的事。

教训总结：过度抽象会将你锁定在一个僵化的结构中，一旦需求发生变化，它就会崩溃。有时候，简单且具体的做法比通用抽象更好。

如何避免过度抽象

1、从具体的解决方案开始

在大多数情况下，你并不需要为每个用例创建通用的工具。先写简单、具体的代码，如果确实需要，抽象可以在后期进行。

2、考虑可维护性

在添加新一层抽象之前，先问问自己：“六个月后，其他人能理解这个吗？我还能理解这个吗？”

3、遵循“三次法则”

在遇到同一问题至少三次之前，不要进行抽象。过早的抽象往往是复杂度增加的根源。

4、定期审查你的抽象

随着需求的变化，你的抽象可能不再适用。做好准备，重构甚至删除那些不再服务于代码库的部分。

最后的思考

过度抽象不仅仅是一个编程错误，它更是一种优先考虑理论上的完美、而忽视了实际需求的思维方式。我曾多次犯过这样的错误，但每一次失误都给我上了一课：抽象应该是为了简化，而不是让事情变得更复杂。

下次当你想要为代码添加更多抽象层时，请停下来问问自己：“我是在解决问题，还是在制造问题？”

发布于：江苏

相关推荐

看不见隐形家务，就是看不见女性
当ChatGPT被广泛使用，有哪些值得我们警惕的风险？
苹果换芯，成了开发者们的噩梦？
迷失在前端框架中的初级开发者，总觉得大厦要从二层开始建
未成年人遭遇“隔空猥亵”？警惕“看不见”的伤害
苹果换芯成开发者噩梦：Docker运行受影响，众多工具和库不支持ARM64
36氪首发 | 以数据驱动研发团队效能提升，代码库分析平台「思码逸Merico」获数千万元Pre-A轮融资
从 C++之父的视角来解锁性能与抽象的关系
开发者噩梦！69% 的程序员每周浪费 8+ 小时，技术债是最大“时间黑洞”
换协议、改代码，Elastic要逼开发者二选一？

网址: “警惕！过度抽象的代码库，是开发者看不见的隐形噩梦” http://www.xishuta.com/newsview131086.html