概念压缩和更深层次的模式

Basecamp和Ruby-on-Rails的&＃64;DHH撰写的这篇文章引发了网络上的大量讨论&＃xff0c;也引起了我的一些思考。 作者认为&＃xff0c;各种存储抽象现在已经足够强大&＃xff0c;以至于许多数据库支持的应用程序开发人员都可以成功而又有效&＃xff0c;而无需了解SQL语法的细节或存储系统的工作原理。 他给出了一个具体的示例&＃xff0c;该示例可以为数百万人提供服务&＃xff0c;但在整个代码库中都没有完全形成的SQL语句&＃xff0c;而是依靠Rails公开的“ Active Record”抽象。 Active Record是对象关系映射器的一个示例&＃xff0c;它使程序员可以使用其本机编程语言处理对象&＃xff0c;然后将其&＃xff08;相对&＃xff09;透明地持久存储到基础存储系统中。

他将其用作“概念压缩”的示例-程序员不再需要了解某些特定技术的混乱细节即可有效地利用其提供的功能。 建立这些更强大&＃xff08;甚至更简单&＃xff09;的抽象的结果是&＃xff0c;程序员可以提高生产效率&＃xff0c;并且可以向更广泛的开发人员开放一般的编程。 不再需要有效的知识和秘诀来有效完成工作。 这为应用程序领域的专家提供了编程机会&＃xff0c;而不仅仅是编程专家。

我花了一段时间才能整理出为什么我觉得这篇文章如此令人讨厌。

创建包含更基本功能的层&＃xff0c;组件或框架的整个过程是一种非常常见的模式。 用户界面和存储框架是一些最常见的示例&＃xff0c;但是它们确实存在于您在软件中看到的任何位置。 随着时间的流逝出现的挑战也很普遍&＃xff0c;这就是使这种感觉不像他在博客文章中所宣称的突破&＃xff0c;而更像是一个持续的周期。

低级系统通常会提供很大的灵活性-灵活性带来了该基础技术用户的复杂性和挑战性选择。 通过认识到许多应用程序遵循通用模式&＃xff0c;可以简化分层框架。 通过做出选择&＃xff0c;该框架简化了与该模式匹配的应用程序类的开发。

在最丰富的示例中&＃xff0c;简化框架创建了自己的附加组件生态系统。 例如&＃xff0c;在NodeJS世界中&＃xff0c;Express框架提供了一种启动和运行Web应用程序的简便方法&＃xff0c;并且还定义了一种插件中间件机制&＃xff0c;该机制允许以非常简单的方式合并许多附加功能。

Microsoft基础类&＃xff08;作为一个老化的例子&＃xff09;在基础Windows UI组件上提供了一个C &＃43;&＃43;的面向对象的习惯用法。 从功能上讲&＃xff0c;它使构建基于C &＃43;&＃43;的应用程序变得更加容易&＃xff0c;因为它允许这些C &＃43;&＃43;惯用语与Windows环境的更基本的API和消息传递完美地结合在一起。

任何分层方法都面临着各种各样的挑战-我在Leaky by Design中谈到了这些挑战。

首先是分层不完整。 尽管该层试图简化&＃xff0c;但不可避免地会泄漏一些潜在的复杂性。 程序员被告知他们正在处理一个简单的系统&＃xff0c;但是随后出现了问题&＃xff0c;这些问题来自底层系统的约束和限制&＃xff08;或者相反&＃xff0c;是灵活性&＃xff09;。 如果开发人员尚未建立关于这些潜在特征是什么的思维模型&＃xff0c;则他们将很难识别它们所带来的漏洞和挑战的根源&＃xff0c;以及随着应用程序的日益复杂而可能找到的解决方案。

或者&＃xff0c;分层太完整。 该应用程序面临挑战&＃xff0c;因为较低级别系统中可用的功能被较高级别框架所做的假设所掩盖或交互差。 因此&＃xff0c;即使应该有某种解决方案&＃xff0c;该解决方案也会被该层阻止&＃xff0c;并且应用程序需要进行翻筋斗来解决这些问题。 这些挑战通常与性能有关。 由于性能随着底层硬件环境的快速发展而永远发生变化&＃xff0c;因此一代人无法接受或过于局限的简化对于另一代人来说是可以接受的。 使用“ X”太疯狂了&＃xff01; 直到不是那样&＃xff0c;而是因为某些基础技术已经改变&＃xff0c;并不是因为原始评估是错误的。

另一个分层问题是该层变得功能过度。 这实际上是组织和技术问题的结合。 该层本身就成为创新的场所&＃xff0c;而投入了成功的团队或社区也可以成为这一层。 因此&＃xff0c;实际上应该内置到最低层的功能将作为分层组件的一部分而构建。 随着时间的流逝&＃xff0c;由于没有建立新的功能和要求&＃xff0c;也不通过系统垂直传播新的功能和要求&＃xff0c;因此将组织/所有权问题转变为技术问题。 使整个系统看起来像巴洛克式的和临时的。 这转化为难以接近且难以学习。

我在这篇文章的前提下面临的另一个挑战是&＃xff0c;“压缩”最有趣和最重要的部分通常不是删除的内容&＃xff08;在这种情况下&＃xff0c;有关SQL语法和管理的许多细节&＃xff09;而是剩下的。 对于任何存储系统而言&＃xff0c;始终重要的是局部性。

无需查看任何代码&＃xff0c;我就能保证在BaseCamp的设计及其对Active Record抽象的深入使用中加深对本地性的了解&＃xff0c;以及对提供良好性能的重要性。 实际上&＃xff0c;几乎每个非平凡的应用程序设计中的挑战都是试图平衡局部性和复杂性。

标准化的原理深深地体现在数据库模式设计中。 但是这种直觉对于最环保的程序员&＃xff08;或文件文员&＃xff09;来说是显而易见的。 不要两次存储相同的信息。 挑战在于标准化几乎是局部性的对立面。 导致将其存储两次的原因是&＃xff0c;您需要在多个地方&＃xff08;通常是客户列表和发票&＃xff09;使用它。 因此&＃xff0c;开发人员将规范化并添加“业务逻辑”&＃xff08;而不是模式设计&＃xff09;以确保语义一致性。 随着时间的流逝&＃xff0c;业务逻辑层变得越来越复杂&＃xff0c;保持一致性变得越来越困难。

这些问题无法通过更简单的存储层解决。 不管程序员是否理解SELECT语句的语法或如何定义数据库视图&＃xff0c;他们都可以更好地理解局部性。 这些技术有更深层次的模式&＃xff0c;这些模式不会消失。

From: https://hackernoon.com/conceptual-compress-and-deeper-patterns-6a12e2a7d5c8