Как вы относитесь к изменениям дизайна?

Question

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

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

Вкратце, как бы вы эффективно решали кардинальные изменения дизайна приложения (как DB, так и код)?

Answer 1

Дизайн базы данных отличается от дизайна приложения в этом отношении.

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

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

Если ваш дизайн базы данных не выделяет слои, подобные этому, трудно сказать, что затронуто, а что нет. Начните с таблиц и столбцов. Спросите себя, требуется ли какой-либо из изменений удалить любой столбец из таблицы, в которой он находится, или потребовать изобрести новые столбцы. Если ответ отрицательный, вам повезло. Затем рассмотрим ограничения, размещенные в базе данных (такие как PRIMARY KEY, FOREIGN KEY, UNIQUE и NOT NULL). Эти ограничения могут быть затянуты или ослаблены изменениями клиента. Если нет, вам повезло. Если вы не объявили никаких ограничений в базе данных и решили сделать всю свою защиту целостности в коде приложения, вам, вероятно, не повезло.

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

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

Answer 2

Если это так сильно, что это было бы лучше всего начать. Я работал над рядом проектов, которые прошли через кардинальные изменения.

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

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

Удачи вам!

Answer 3

Как бы вы переделали дизайн таким образом, чтобы оставаться уверенным в том, что материал, который вы меняете, не разрушает другие вещи? Короче говоря, как бы вы эффективно решали кардинальные изменения дизайна приложений (как DB, так и код)?

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

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

Answer 4

Предполагая, что у вас есть модульные тесты на месте, это всего лишь рефакторинг.

Если у вас нет модульных тестов на месте, то

1. тесты Запись единицы для деталей вы, вероятно, чтобы сохранить.

2. Напишите модульные тесты для деталей, которые вы собираетесь изменить.

3. Запуск тестов. «Держать» должно пройти. «Изменение» должно завершиться неудачей.

4. Начать рефакторинг до прохождения тестов.

Answer 5

Это НЕ-НОВАЯ вещь в программном обеспечении, и люди это сделали и много писали об этом.

Попробуйте прочитать

• Working Effectively with Legacy Code
• Refactoring Databases: Evolutionary Database Design

методики описаны здесь незаменимы для поддержания какой-либо давно работает ИТ-проектов.

Answer 6

Иногда вы делаете что-то лучше во второй раз, поэтому просто старайтесь оставаться позитивным. Кроме того, на этот раз у вас будет больше знаний о домене.