我的大部分技术职业生涯都是在初创公司度过的。我喜欢快节奏和学习新事物的机会，以及成功将新产品推向市场的成就感。我的职业生涯始于QA。在初创公司中，开发人员与测试人员的比例不太可能像在大型企业中那样低。作为初创公司的QA工程师，收件箱收到的电子邮件总是比发件箱多得多。您是新版本发布的最后一个级别，因此您始终处于显微镜下。在初创公司的早期阶段，你很可能也会加入“客户支持”团队，所以当产品出现问题时，你将是最忙的。和其他做同样工作的人一样，我总是非常专注于寻找合适的工具来减轻我的负担，但又不会牺牲我对工作质量的个人定位。所以我在10年前遇到了FindBugs。我第一次使用这个工具时，我与团队中的开发工程师分享了它的结果，他们觉得这个工具产生的误报比真正的错误要多，或者以一种“吹毛求疵”的方式。然而，随着我们继续微调和扩展我们根据自己的需要执行的检查，并将FindBugs获得的数据与测试和生产中发现的实际错误数量相关联，FindBugs已成为夜间构建和按需构建构建的组件。这些报告是对潜在问题进行早期预警的良好线索，并允许开发人员在占用测试时间或操作停机时间之前修复错误。另外，对于我团队的开发人员来说，因为他们每天都能收到构建系统的提醒，而这些提醒会帮助他们改掉坏习惯，写出更安全、更高效、更稳定的代码，所以他们有产生的缺陷也越来越少。更短的发布周期、更高的产品质量和更高的客户满意度证明预防确实比治疗更重要。随着企业IT继续采用敏捷开发实践并采用DevOps模型以更快地将更好的产品推向市场，DBA实际上也开始感受到压力。前面介绍的初创软件公司的QA工程师，同样适用于DBA。随着发布变得越来越频繁，DBA收到的需要编写、检查、修改或优化的SQL脚本远远多于完成的数量。DBA是数据质量、数据安全、数据平台性能的最后一道防线，所以DBA也是最先响应问题的。在我们合作过的500强企业DBA中，他们日常工作中最耗时的工作就是检查SQL。一些DBA花费70%的时间手动检查SQL脚本。他们检查SQL的方式与FindBugs等工具检查Java代码的方式相同：指示逻辑问题、安全漏洞、性能问题和违反内部强制最佳实践或外部法规的合规性问题的编码模式。显然，DBA需要像FindBugs十年前那样的工具。SQL静态分析并不是新技术，但目前市面上的产品只能做静态分析。通常，他们评估SQL语句而不考虑上下文。这种限制会影响最终的生产力和质量，因为大多数时候数据库生命周期管理都知道谁在做什么、在何时何地做什么。例如，组织可能允许在测试环境中分配权限和执行INSERT语句，但绝不允许在生产环境中的自动化任务中执行这些操作。任何SQL静态分析工具都必须考虑环境参数。另一个复杂的问题是数据库“版本更改”。虽然应用程序的版本被打包、版本控制和完全替换，但支持应用程序的数据模式一直存在并继续发展。此外，外部合规标准和内部审计要求通常要求严格控制对数据库的增量更改，并使用严格定义的流程跟踪更改。这意味着DBA还必须确认（通过手工流程和检查SQL注释）修改的原因是可追溯的，并且修改的执行结果必须在每个环境中被跟踪。DaticalDB规则引擎的设计和实现特别考虑了SQL检查和静态分析带来的特殊挑战。以下是DaticalDB通过静态分析安全可靠地提高生产力的一些原因：用于执行强大评估的模型-DaticalDB将应用程序的模式抽象为严格定义和验证的对象模型。这些强大规则的授权过程既快速又简单。一旦写入，它们将在每个数据库在生命周期中执行Forecast或Deploy时生效。Environment-AwareModificationValidation-该模型包含有关客户端环境和应用程序生命周期中各种数据库实例的信息。您可以编写规则，为早期部署阶段的环境提供最大的灵活性，同时为敏感环境提供最大的安全性。内外部审计需求的早期识别——在DaticalDB中，为了符合外部和内部审计需求，你只需要紧紧绑定数据模型的每一次修改。每次（或自动化框架）Forecast或Deploy执行的自动检查取代手动检查以确认修改的可审查性。自动验证对您最重要的内容-提供自定义分析的能力，覆盖您自己的内部最佳实践，例如命名约定、允许和禁止的SQL以及对象依赖性管理。自动执行重复性任务——与许多分析源代码的静态分析工具类似，只需单击几下鼠标即可将DaticalDB集成到构建或部署系统中。现在，每次构建或部署应用程序时，它都会执行验证规则，然后生成供整个组织使用的报告。由于DBA花更少的时间盯着屏幕，他们可以专注于更重要的项目和问题。更好的代码质量意味着更少的错误——DBA制定规则，然后与开发人员共享。然后，开发人员就可以了解在他们的组织中什么是可接受的编码，什么是不可接受的编码。减少错误数量的开发将节省节点时间和金钱。让运维人员更多地参与数据库开发——该规则引擎与DaticalDBForecast高度集成。此功能支持模拟数据库修改，而无需实际修改目标数据库。当DBA将自己的规则分享给运维人员时，运维人员可以每晚对STAGE或PROD环境进行Forecast，确保DEV或TEST环境当前的修改也符合下游进行的严格验证，这也可以在生命周期中实现，问题在早期发现，因此修复问题的代码较低，难度较小。原文链接：https://img.ydisp.cn/news/20220804/ue2d420gmzg
