自动化
作为工程师，我们始终铭记将成本和时间降至最低的需求。经验告诉我们，虽然自动化在减少代码方面很有价值，但我们还必须保留设计灵活性并启用敏捷迭代。让我们分解一下，然后举例说明。
自动化（减少例程代码-可执行规范）
为了保证学习曲线，自动化必须大大减少常规编码。减少25％的代码不足以吸引人。
机会就在这里-5条语句的简单“鸡尾酒餐巾规范”可能导致数百行代码。目标是使这些规范变得严格且可执行。
但是要交付价值，还存在其他关键的自动化要求：
- 可扩展性- 因此我们可以使用标准语言和方法来构建非自动化的内容
- 可管理性-因此我们可以使用现有工具和过程来管理我们的系统（例如，很难将数据库行推送到git）
- 可扩展性-因此无需支付大量的性能税
设计自动化（不仅仅是减少代码）
我们都看到过自动化工具可以减少代码，但会迫使我们进入不符合我们需求的设计选择。这样的“灵活性税”会否定自动化的价值。
因此，真正的需求是设计自动化-自动化不仅可以减少代码，而且可以保留我们的设计灵活性。
敏捷设计自动化
敏捷倡导者们，即使面对诸如数据大小和事务量之类的未知数，项目也要尽早开始实施。然后，我们被迫对诸如性能非规范化之类的事物进行假设，这些假设已融入我们编写的应用程序中。
问题在于，这些未知数通常要等到后期的“上线”测试才能发现。那是在开发迭代的漫长阶段之后 。
敏捷设计自动化减少了代码，保留了我们的设计灵活性，并使我们能够进行迭代而无需重新编码。福州小程序开发公司
案例研究：敏捷设计自动化
对于典型的数据库系统，后端几乎要花费一半的精力。下图说明了一些可以提供帮助的自动化服务：
- 我们的设计（左），也许是数据库图，以及交易逻辑的“鸡尾酒餐巾规格”。
- 产生的代码（右下），实现我们设计的众多模块。如上所述，在没有自动化的情况下，设计要编码的数量级激增。
- 自动化服务 （右上），包括：
- 数据库管理系统
- 对象关系映射（ORM）系统，例如适用于Python的SQLAlchemy
- 逻辑，例如逻辑库（在下面说明）
- UI构建器，例如Flask App Builder（如下所示）
让我们探究这些技术如何自动减少繁琐的编码，保持设计灵活性并提供敏捷性，以便我们可以对现有系统进行更改。
示例：只有销售代表才能下订单
为了使事情确定，让我们考虑一个示例，在该示例中，我们拥有员工拥有的订单。我们的要求：
- 一些员工被“委托”
- 订单只能与委托员工相关
数据库设计
我们可以将数据库设计表示如下：
为了避免出现一致性问题，或者可能是因为架构已被锁定，让我们想象一下，我们不想像order_count斜体字所示存储（没有性能非规范化）。
逻辑鸡尾酒餐巾设计
我们可以按“添加顺序”实现逻辑，但是我们也想解决其他用例。例如，如果未委托员工分配了订单，则他们的“更新员工”应该失败。
还有其他我们可能忽略的用例吗？保持那个想法…
因此，我们用于“添加订单”和“更新员工”的鸡尾酒餐巾设计是：
- 定义
Employee.order_count - 确保仅在调试时
order_count可以大于0的约束
示例1：添加缺少的索引
我们的第一个示例是众所周知的，但很好地说明了敏捷设计自动化。
回顾过去，关系前的DBMS系统要求我们在每个程序中的每个查询中明确命名索引。然后，在项目后期，我们会发现某些访问是通用的，并且需要索引。
很快发现并添加索引。问题是所有现有程序都不知道索引-它们不独立于数据库设计的这一关键方面。因此，我们将审查所有这些内容并进行所需的修订。这花了很多时间。
关系：访问数据独立
随着现代数据库系统的出现，这个巨大的问题被消除了。从每个应用程序中提取索引结构的知识，由查询优化器代替。
在我们的示例中，也许我们忘记在上放置索引Order.EmployeeId。即使我们可能发现它很晚，但在上线测试期间也没问题-我们添加了索引，并且我们已经编写的所有程序都会自动使用它，并且运行速度更快。
关系数据库已经实现了敏捷设计自动化：我们可以表达添加索引的设计意图，优化器将使用它们来显着提高性能。它是敏捷的，因为我们可以更改设计而无需更改程序代码。
示例2：添加性能非规范化
但是索引结构并不是我们需要尽早做出的唯一关键设计决策。另一个是“性能非规范化”。考虑一个汇总，例如Employee.order_count：
- 我应该将汇总存储为物理列吗？
这提供了近乎即时的访问（没有SQL select sum），但是需要所有访问程序来一致地对其进行维护。这意味着更多的工作，更多的出错机会。
- 还是即时获得它？
这种方法消除了一致性问题，但执行速度可能很慢。
性能影响可能很大，尤其是在链接汇总的情况下-一个汇总取决于另一个。例如，客户余额取决于另一个汇总Order.AmountTotal（来自OrderDetail.Amount的汇总）。这导致一组求和查询。
这种链式汇总实际上可能会阻止部署。我个人的情况是服务水平协议（SLA）为3秒，但在上线测试期间观察到的结果为3分钟。很明显，工作即将开始。解决方案很明确：性能非规范化。
没有明显的答案—打电话并开始实施
与大多数有趣的问题一样，没有正确的答案-它取决于数据和事务量，我们可能不知道项目何时开始。即使面对这些未知数，也必须开始发展。
在我们的示例中，我们调用了“动态派生”。完全合理。然后将此假设编码到数十个应用程序模块中，包括Web应用程序，Web服务，报告等。
问题：上线测试发现性能问题
然后，在上线测试中，我们发现一个“销售代表”是自动化网站，并且有数千个订单。总结这些太慢了。我们需要进行非规范化，以避免求和查询。
如果没有设计自动化，这将是一个问题，因为我们必须浏览所有应用程序才能发现我们假设“动态派生”的位置并更改逻辑。这非常类似于我们的关系前需要重新编码以使用新索引。自动化可以提供帮助。
解决方案：使用ORM虚拟属性隐藏信息
许多项目使用ORM（对象关系管理器）为数据访问提供抽象层。ORM可以提供更好的编程接口（更好的属性/对象名称，类型检查/代码完成等）。许多属性还提供虚拟属性-定义未存储在数据库中但由ORM实现的属性的能力。
SQLAlchemy就是这样的一个例子，其中这种支持称为“混合属性”。例如，您可以这样定义order_count：
快速定位背景。在上面的屏幕截图中，models.py包含了映射到我们表的Python类。这里显示的是Employee类的一部分 （注意：可以生成此文件）。特别注意：
- 第110-115行定义了存储的列，因此您可以进行编码
anEmployee.Salary - 第119行定义了自我关系，因此您可以进行编码
anEmployee.Manager以获取雇员经理行，并anEmployee.Manages获取受管理雇员的列表
第123-131行将我们的混合（虚拟）属性定义为Python代码。请注意，您可以设置断点（红点）。
它引用order_count_sql，定义如下：
员工。order_count_sql = column_property（
选择（[ FUNC。计数（订单。标识））。\
其中，（订单。编号 == 订单。雇员））
敏捷：非规范化，无需更改应用程序
因此，现在，我们所有的应用程序都可以访问此属性，而无需知道它是存储还是派生（也称为“信息隐藏”）。为什么这么重要？
让我们回到非规范化和存储order_count列的需求。
我们可以快速更改架构以创建物理列，并对ORM模型进行较小的更改以将123-131行替换为order_count = Column(Integer)。这几乎不需要时间。但是，所有已经编写的代码呢？
重要的是，ORM模型更改不会影响其外部接口。而且，由于这些应用程序已编码为ORM模型（而非架构），因此我们已经编写的所有应用程序代码都没有更改。
SQLAlchemy提供了敏捷设计自动化：保留了“存储与派生”设计的灵活性，并保持了敏捷性，因为我们可以更改设计而无需重新编码。
示例3：敏捷协作-基本Web应用
敏捷强调早期工作软件来促进业务用户协作以驱动迭代周期。因此，我们希望将数据库与可用的软件结合使用，而不是数据库图（对业务用户而言意义不大）。就像运行屏幕一样，具有真实数据。
但这需要很长时间。需要更多的自动化。
Flask App Builder位于SQLAlchemy之上。我们已经构建了一个生成器-fab-quick-start-它可以在几分钟内创建多页面，多表的基本Web应用程序，如下所示：
这些对于原型设计，测试和充实逻辑要求而言是超级好的。有关更多信息，您可以阅读有关Instant DB Web Apps的本文。
示例4：业务逻辑
现在，让我们考虑如何准确地构建实现“鸡尾酒餐巾”设计的业务逻辑，只有委托员工才能获得订单。
Logic Bank使鸡尾酒餐巾规范可以执行
有许多实现业务逻辑的遗留方法：触发器和存储过程，ORM事件或用户界面中的控制器。但是，这些都是相当繁琐的代码密集型工作，风险很高-后端逻辑通常接近系统的一半。
我们将使用Logic Bank来自动执行更新事务逻辑-多表派生，约束和诸如发送邮件或消息之类的操作。Logic Bank基于SQLAlchemy，可处理事件以实施逻辑。逻辑包括：
- 规则-使用类似电子表格的范式（总和，计数，公式等）更简洁40倍，并且
- Python —使用标准工具和技术（代码编辑器，IDE，源代码控制等）的可扩展性和可管理性
基于规则的方法不仅简洁40倍，而且可以解决超过95％的后端数据库逻辑。这意味着您的系统将近一半简明了40倍。
让我们面对现实：这是一个不错的主张。您可以在此处查看Logic Bank， 以获取40倍简洁性的运行示例（完整的实际旧代码与逻辑代码比较），以及可扩展性，可管理性和可扩展性能等关键挑战的解决方案。这些示例可供探索并在GitHub上运行。
使用Logic Bank，我们可以使用Python声明逻辑。类似电子表格的规则方法使我们能够直接输入鸡尾酒餐巾设计，如第68-72行（我们无法抗拒显示自己喜欢的规则，第74-82行）：
最重要的是，该设计可通过Logic Bank运行时系统（作为SQLAlchemy事件处理程序）执行（自动化）。这解决了我们想象中的用例：
- 添加订单-逻辑银行规则引擎将：
Employee.order_count根据第72行的规则进行调整- 验证第68行的约束
- 更新
Employee.IsCommissioned-逻辑银行规则引擎将：- 在第68行上验证我们的约束条件（例如，通过引发异常并回滚交易，拒绝对已分配订单的委托员工进行重新分类）
关系数据库以同样的方式为数据检索提供了声明式自动化，而Logic Bank提供了数据更新逻辑的声明式自动化。您可以在Chris Date的《What，Not How》一书中阅读有关声明式方法的更多信息。
Logic Bank已交付了敏捷设计自动化：后端代码减少了40倍，保留了设计选择（如非规范化），并具有无需应用程序重新编码即可更改业务逻辑的敏捷性（请参见下文）。
摘要：敏捷设计自动化
这个简短的例子说明了敏捷设计自动化如何为您和您的组织带来好处。
赢得＃1：自动化-使用Logic Bank将后端代码减少40倍
Logic Bank使用类似于电子表格的规则使您的鸡尾酒餐巾规格可执行，从而将后端数据库逻辑减少40倍。 本文提供了有关该成熟技术的示例和一些历史背景。
胜利2：保留设计灵活性（例如，性能非规范化）
逻辑库规则位于SQLAlchemy类模型之上，而不是 数据库架构之上。因此，无论您是否规范化或改变主意，您的逻辑都是相同的。
但是，如果您进行非规范化，那么一致性又如何呢？回想一下，这是传统方法的风险。现在消除了这种风险，如下所示。
您的逻辑将从应用程序代码中提取到Logic Bank中。Logic Bank对使用SQLAlchemy的所有应用程序自动执行您的派生和约束。而且它是自动执行的，无需应用程序操作-消除了一致性错误。
当代工程专注于实现重用；这引入了自动重用。
胜利3：应用程序的逻辑敏捷性
让我们调整一下上线的性能场景，以想象我们发现了一个逻辑错误-我们忽略了委托订单的要求。在传统（逻辑银行之前）的方法中，我们可能会在Web服务，Web应用程序等中缺少逻辑。要审查，重新设计和测试的代码很多。
由于Logic Bank从应用程序中提取逻辑，因此您现在具有逻辑敏捷性，而不仅仅是非规范化敏捷性。您可以添加上面显示的2条规则，所有应用程序都会相应地运行，而无需更改。自动重用。
由于基于系统发现的依赖关系自动对规则执行进行排序，因此进一步提高了敏捷性。rules_bank.py在任意位置将规则添加到您的代码中（上方）；它会被激活。
胜利＃4：自动重用可捕获丢失的用例
除了逻辑敏捷性之外，还有其他好处。经常会发生一些我们忘记考虑的用例。例如，我们忽略了将订单从Employee-1转移到Employee-2的含义。没问题，以上规则会自动解决此问题：
- 将订单从Employee-1转移到Employee-2-逻辑银行规则引擎将：
- 将Employee-1.order_count向下调1（不是一个总和-逻辑引擎尊重我们的非规范化设计决策）
- 将Employee-2.order_count调高1；这个变化会触发…
- 验证第68行的约束
这是一个很大的问题。通过使用声明性方法，我们的逻辑将自动 在涉及数据的所有事务（甚至是我们可能忽略的事务）中重新使用。甚至我们已经编写的代码。
结论
自动化通常会征收“灵活性税”，从而降低了实现项目目标所需的灵活性，但是正确的做法是，例如SQLAlchemy和Logic Bank，您可以节省自动化时间，同时又保留了对关键设计灵活性的控制权。设计自动化。
这不仅是灵活性，还在于数据独立性-在编写所有应用程序后做出这些设计决策的能力。 那就是敏捷设计自动化。
