Является ли непрерывное создание и удаление таблиц признаком архитектурного недостатка?

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

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

Мне с каждым днем ​​становится все более и более очевидным, что «проворный» становится синонимом плохо продуманных, хаотичных, спешащих и сидящих на ваших штанах. И ни одна из этих вещей не совместима с Agile-подходом, насколько я понимаю.

Иметь эффективный и повторяемый Agile-процесс непросто, и я не верю, что он по своей сути сокращает общий объем выполняемой работы, даже если он вполне может привести к улучшению качества продукции.

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

В конце концов, Agile - это просто слово. То, что вы делаете изо дня в день, определяет, будете ли вы успешны или нет.

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

Да, Agile - это все о рефакторинге, но если они сейчас говорят, что система слишком велика для рефакторинга, они перестали заниматься Agile и теперь просто программируют на Cowboy. Команде разработчиков не понравится, когда ее так называют, но это то, что они делают. Ездить на дальности стрельбы все, что движется.

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

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

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

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

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

В свете комментариев - как правило, на их фоне кучка ковбоев, оправдывающих себя как ловкие, - бегите с криками. Быстро. И опубликуйте все, что можете, на thedailywtf.com, чтобы мы могли насладиться вашим ужасом.

Как и большинство ответов здесь на StackExchange, ответ должен быть «это зависит». В гибкой разработке требования и спецификации обнаруживаются во время реализации.

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

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

Чтобы ответить на ваш вопрос, нет, это не нормально в Agile процессе.

То, что может показаться следствием Agile, - это короткий цикл итерации / разработки / тестирования Agile и акцент Agile на легких решениях, которые отвечают известным требованиям, но хорошо структурированы, чтобы соответствовать новым требованиям с минимальное изменение. Учитывая эти две вещи, вы можете сказать, что разработчик, не зная, что может произойти, но зная, что его изменение не должно влиять на БД таким способом, который невозможно отменить, просто вносит необходимые изменения в схему в возможен «самый легкий» путь, и затем через несколько интервалов несколько наборов «легких» изменений будут преобразованы во что-то более постоянное и стабильное.

Сказав это, я еще не работал с разработчиком, который подписывался на теорию и методологию Agile, а также думал, что регулярное создание и удаление таблиц в схеме необходимо по любой причине. Ловкий не означает удар по лицу или удар. Если вам дается история, требующая добавления нового поля данных, принадлежащих определенной записи, вы добавляете это поле в таблицу. Если это изменение что-то нарушает, вы понимаете, почему, и вносите другие изменения, которые могут потребоваться (я могу вспомнить очень мало вещей, которые могут сломаться при добавлении столбца в запрашиваемую БД; если это не так с такими изменениями, вы есть большие проблемы). Рефакторинг обычно ограничен кодом; изменение схемы обычно является более сложным процессом, чем изменение кода, и поэтому, когда изменения схемы должны произойти, они обычно делаются с большей осторожностью, и, по крайней мере, некоторое внимание уделено знанию будущего направления проекта. Необходимость реструктуризации части или всей базы данных указывает на фундаментальный сбой проектирования; Быть гибким не означает, что не существует «генерального плана» базовой архитектуры и правил проектирования, которым необходимо следовать при органическом построении программы и структуры данных.

Теперь в Agile есть случаи, когда то, что вы «знаете» сейчас, будет противоречить тому, что вы узнаете позже. Скажем, у вас есть требование, чтобы в вашей системе был адрес для каждого человека. Поскольку это соотношение 1: 1, и в большинстве случаев данные понадобятся, вы просто добавляете поля Address в таблицу Person. Неделю спустя вы получаете требование, чтобы Лицо могло иметь более одного адреса. Теперь это отношение 1: N, и для правильного моделирования вы должны отменить ваши предыдущие изменения, разбив поля на новую таблицу адресов. Это не рутина, особенно среди старших разработчиков. Опытный разработчик увидит, что у Person есть Address, рассмотрит их как концептуально отдельные, и создаст таблицу Person и таблицу Address, связывающую Person с Address с помощью ссылки FK на AddressID. Такая схема легче изменить, если изменится характер отношений; без создания или удаления целых «широких» таблиц данных связь между Person и Address может быть легко изменена с 1: 1 до 1: N до N: N.

При работе под Agile не уделяется столько внимания дизайну, поэтому я не вижу в этом большой проблемы, особенно для первого выпуска.

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

Даже в agile для большой системы достаточно часто иметь кого-то / команду, отвечающую за схему.

Если они часто делают такие изменения - особенно удаляя таблицы и столбцы в живых приложениях - это кажется признаком неопытности. Это не имеет никакого отношения к какому-либо процессу, которому они утверждают. «Agile» - это не повод, чтобы не садиться и не думать о данных, которые нужно хранить, и о том, как они связаны, прежде чем начинать писать код. Если они обнаруживают, что они изменяют более 10-20% первоначальной структуры, для меня это показатель, что они либо не продумывают вещи, либо у них нет большого опыта анализа требований и проектирования баз данных, и поэтому они просто получают слишком много информации. многое из этого неправильно в начале.

Хотя кажется, что ваша команда действительно занимается ковбойским кодированием, с рефакторингом кода ИЛИ баз данных не должно быть никаких проблем. Это не потерянная работа - это адаптация к недавно изученной реальности.

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

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

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

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