Для эффективного управления жизненным циклом базы данных, вам нужно автоматизировать как можно больше рутинных задач просто потому, что любой переход к более быстрым циклам разработки и более частое внесение изменений означает, что и множество простых проверок, тестов и анализа кода будет проводиться гораздо чаще.

Если ваш исходный код находится в системе управления версиями и у вас есть возможность выпускать стабильные версии с исходных позиций, вы можете приступать к автоматизации других процессов. Анализ кода базы данных является очевидным выбором, поскольку вы получаете немедленную выгоду, и его относительно легко автоматизировать.

В этой статье кратко объясняются преимущества анализа кода базы данных, как статического, так и динамического, инструменты, доступные для выполнения и автоматизации этого анализа.

Какие существуют возможности применения анализа кода базы данных?

В целом, анализ кода – это не только помощь отдельному разработчику, но и польза для всей команды. Это связано с тем, что он делает состояние и цель кода более наглядными, что позволяет каждому, кто отвечает за доставку, получить лучшее представление о прогрессе и гораздо раньше предупредить их о потенциальных задачах и проблемах в дальнейшем. Это также позволяет каждому лучше понять, какие стандарты кодирования согласованы, и какие существуют ограничения в области эксплуатации, безопасности и соответствия.

Анализ кода базы данных – немного более сложная тема, чем статический анализ кода, используемый при разработке приложений Agile. Этот процесс сложнее, потому что вы можете проводить динамический анализ в дополнении к статическому, а также потому, что базы данных имеют несколько разных типов кода, которые имеют разные соглашения и соображения. Существует DML (язык манипулирования данными), DDL (язык определения данных), DCL (язык управления данными) и TCL (язык управления транзакциями). Каждый из них требует довольно разного анализа.

Что касается цели анализа кода базы данных, их, вероятно, лучше всего понять, если взглянуть на требования группы доставки и руководства, поскольку всем им потребуется анализ кода базы данных, но для довольно разных целей.

Доставка

Даже в процессе разработки команда доставки будет иметь как минимум три разные цели для анализа кода. Это решение нескольких проблем: разработчики должны иметь возможность проверять свой собственный код в своей IDE, чтобы убедиться, что он подходит для слияния с основной веткой; процесс сборки нуждается в проверке кода, чтобы убедиться, что ничто не нарушит сборку. Предварительно выполняя анализ кода базы данных, вы знаете, что его сломает, и, следовательно, быстрее сможете устранить проблему и перезапустить сборку. Обычный процесс сборки сам по себе является способом обеспечения того, чтобы рабочая база данных могла быть собрана из того, что находится в системе контроля версий, но проверка кода помогает избежать дополнительной работы и задержки перед повторением сборки; команда должна проверить код на наличие проблем безопасности, прежде чем они попадут в сборку. Любой код контроля доступа (DCL) должен быть проверен перед сборкой.

Руководство

Руководство захочет проверить текущую сборку, чтобы получить общее представление о том, где находится код между «рабочим» и «производственным качеством».

Руководство также должено получить представление о степени компромисса, достигнутого группой разработчиков для соблюдения сроков. Это так называемый «технический долг».

Статический и динамический анализ кода

Анализ статического кода обрабатывает код так, как это делает компилятор, но с целью проверки синтаксиса, а не его компиляции. Статический анализ кода – это укоренившаяся техника, изначально основанная на программе Lint Unix, которая была разработана в 1979 году в качестве препроцессора для компилятора Си. Он анализирова исходный код C. Этот препроцессор выполнял несколько задач, которые в настоящее время чаще всего покрываются компилятором, и выявлял подозрительные и непереносимые конструкции в исходном коде, которые могут вызывать ошибки. Большинство людей по-прежнему называют любой инструмент, который помечает подозрительное кодирование, как «lint» или «linter», независимо от того, на каком языке оно написано для анализа. Инструменты типа Lint обычно выполняют только статический анализ исходного кода.

Для баз данных статический анализ очень полезен при проверке подпрограмм, таких как функции и процедуры, на наличие запахов кода, которые требуют анализа самого кода. Динамический анализ кода базы данных расширяет диапазон проверяемого. Созданная пользователем реляционная база данных, по сути, построена с использованием системной реляционной базы данных, и запросить природу и структуру пользовательской базы данных с помощью SQL-запросов к системной базе данных достаточно просто. Эти данные о вашей базе данных, так называемые «метаданные», можно использовать для проверки структуры объектов базы данных, для изучения взаимосвязи объектов базы данных, а также для поиска ошибок и сомнительных методов.

Помимо информации об объектах базы данных, их структуре и взаимосвязях, вы также получаете доступ к информации о динамическом поведении метаданных объектов в системных представлениях с помощью динамических представлений управления. Это значительно облегчает выполнение ряда проверок. После создания базы данных мы можем, например, проверить наличие отсутствующих индексов, неиспользуемых индексов, проблем с зависимостями, отсутствующих ограничений и медленных запросов.

В общем говоря, комбинация статического и динамического анализа дает вам возможность для очень широкого анализа.

Выводы

Никто не станет утверждать, что анализ кода базы данных критичек. Можно обойтись без этого, но если он у вас есть, он скорее всего приносит дивиденты. По моему опыту, больше всего преимуществ принес факт его наличия в IDE, как часть SSMS в моем случае, и я готов проверить наличие проблем с базой данных разработки. Я встречал все виды проблем, от члена команды, занимающегося копи-пастом с устаревшим синтаксисом, до разделов кода, которые я прокомментировал как «todo» или «отмененный», но о которых я забыл позднее. Я считаю, что анализ SQL-кода как инструмента персональной базы данных – это то место, с которого нужно начинать. Я всегда дополнял это рядом динамических тестов, написанных на SQL, чтобы выявлять более неясные «запахи» в коде. Например, важно выделить те «суперфункции», которые пытаются сделать слишком много, просто перечислив функции или другие подпрограммы с наибольшим количеством зависимостей.

Я не уверен в использовании анализа кода с целью обеспечения соблюдения стандартов кодирования, главным образом потому, что лучшие практики в SQL гораздо менее "черно-белые", чем в процедурном коде. Соглашения об именах, безусловно, приносят плоды после тщательного изучения, но некоторые из лучших практик, которые я видел в политиках кодирования, просто смешны.

Когда дело доходит до анализа "технического долга" с помощью анализа кода SQL, все становится немного сложнее. Я видел показатели сложности кода для подпрограмм SQL, которые, кажется, работают, но нам нужно больше поработать над тем, как создать показатель, который соответствует тому, что люди считают базой данных в контексте технической задолженности. Нам нужно понять, что такое эквивалент связности и сплоченности, как мы оцениваем читаемость и насколько значительна цикломатическая сложность для кода SQL. Однако количество предупреждений, помеченных во время сборки, является достаточно хорошим показателем и, безусловно, лучше, чем ничего.

Определенно хотелось бы иметь простой способ проверки того, что код будет компилироваться без ошибок перед автоматическим процессом сборки, потому что на этом этапе исправить вещи намного проще.

Самая большая проблема с анализом кода SQL заключается в определении и согласовании всех сомнительных практик и проблемного кода: в выборе наилучших соглашений об именах и в достижении консенсуса относительно того, что представляет собой запах кода SQL или анти-шаблон SQL. Фактический процесс обнаружения не самая сложная часть.