删除|注意你的抽象,伙伴

删除|注意你的抽象,伙伴


什么是组件化【删除|注意你的抽象,伙伴】组件化或基于组件的开发是一种编写软件的方法 , 它基本上包括将您的逻辑构建成较小的单元 , 其他人可以使用标准接口重用这些单元 。 它可以来自前端组件库甚至微服务应用程序 。
这个概念是由 Douglas Mcllroy 在 196 年8首次提出的 , 当时他在北约软件工程会议上介绍了“批量生产的软件组件” 。 如今 , 您可以看到这个概念无处不在 , 尤其是因为它与另一个著名的编程概念“不要重复自己”(简称 DRY)密切相关 。 它基本上建议将重复的代码段封装到可重用的函数中 , 这样您就可以减少正在编写的行数和潜在的错误数量 。
主要挑战基本的东西吧?但在学术墙外 , 你会发现事情并非那么简单 。 您是否曾经不得不维护一个让您感觉不舒服更改它的代码?也许它的接口(API/参数)变得如此之大 , 以至于随着可能性的总量成倍增加了复杂性 , 或者它可能在您的范围之外被重用并且您害怕潜在的副作用 。
另一种常见情况是必须部署新版本的应用程序 , 因为在其依赖项中发现了一个错误 。 即使您没有注意到 , 自动化工具也会让您了解已发布的修复程序 , 尤其是在涉及安全性时 , 您会收到来自我们的好友“Dependabot”的友好提醒 。
无论如何 , 我带来这个是为了说明组件化不是那么简单 。 您真的应该注意您作为 API 公开的内容以及您添加到代码中的依赖项 , 或者您可能正在创建一个火箭筒来杀死一只简单的蚂蚁 。 那么 , 我们是否应该放弃重用并开始“把所有东西都写两次”(WET)?我不这么认为 , 就像生活中的大多数事情一样 , 问题在于“如何”而不是“什么” , 所以让我告诉你我现在是如何解决这个问题的 。
美国心脏协会不久前 , 一位朋友向我介绍了一篇来自
肯特·C·多兹
称为“AHA 编程” 。 AHA 代表“避免草率抽象” , 基础知识说一开始要避免重用某些东西 , 因为您不完全了解将来可能出现的所有需求 。 我花了一些时间来消化这篇文章 , 尤其是因为它违背了 DRY 而这篇文章是我在大学里学到的第一件事 , 我认为它是绝对真理 。 我强烈建议以开放的心态阅读它 , 它可能会改变你的观点 。
可移除性这个有点出乎意料 , 因为我们正在谈论尚未创建的东西 , 但是请稍等 , 假设您的组件/功能确实存在并且您不再需要它 , 删除它会有多困难? 如果你可以通过删除代码库中的一个文件夹来删除它 , 这意味着这段代码给你的代码库带来的所有复杂性都很好地封装在一个逻辑单元中 , 文件夹 , 删除它而不必触及它的任何其他地方意味着所有依赖项彼此靠近 , 您不必担心破坏可能正在使用它的人 , 因为依赖项位于同一文件夹中 。
有一些与您正在使用的堆栈相关的限制 , 例如 , 可能翻译消息需要在其他地方 , 但这里的主要思想是使与功能相关的代码彼此靠近 , 以便您可以轻松地进行更改因为潜在的副作用仅限于某个区域 。 加分点是 , 这种保护措施还可以让您远离重用代码片段的冲动 , 因为您将按功能拆分代码 。
TLDR;结论我的工作经验告诉我 , 创建新功能/解决方案/服务非常简单 , 真正的挑战在于维护和发展它 。 就像生孩子一样 , 制作很简单 , 我们都知道怎么做 , 但养育部分是每个人都试图找出完美解决方案但尚未找到的部分 。 我知道写出完美的抽象来解决所有问题的感觉很好 , 包括气候变化和饥饿 , 感觉很聪明 , 我们喜欢它 , 我们为写出聪明的抽象感到自豪 , 但请记住 , 你未来的自己可能无法理解它从现在起六个月 。 根据克尼汉定律: