Есть ли надежда на написание хорошего кода поверх ужасно спроектированной базы данных?

18

Вот мое затруднительное положение. Одна из нескольких программ, которые я недавно унаследовал, построена с ужасной базой данных на сервере. Уважаемые создатели этого, очевидно, не оценили реляционные концепции. Таблица для каждого клиента, названная как уникальный идентификатор клиента. Восемьдесят три загадочно названных поля. Весь код является процедурным с десятками объединенных встроенных операторов SQL.

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

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

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

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

Джон Страка
источник
2
Подумайте только, как бы вы кодировали библиотеку, в которой особый случай «2 + 2» не вернул 4. Это не легко.
8
Итак, все, что я слышу, это то, что у вас есть 30 дней, чтобы найти другую работу. попробуйте careers.stackoverflow.com ;-)
Стивен А. Лоу
@gnat: Даже не близко.
Роберт Харви

Ответы:

27

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

Мой совет - создать достаточно абстракций над базой данных, чтобы само приложение было чистым и правильно разработанным; таким образом, если вы когда-нибудь сможете исправить базу данных, приложение не будет затронуто, так как ей все равно, как была разработана база данных.

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

Уэйн Молина
источник
1
+1 Я в основном сказал то же самое в своем ответе, прежде чем полностью прочитать ваш, однако я не вижу способа удалить свой ответ, поскольку ваш охватывает тот же материал.
Оминус
Как я прокомментировал другим, делающим это предложение, это хорошее предложение, но весьма вероятно, что если дизайн базы данных дерьмовый, то и код приложения, скорее всего, дерьмовый. Я не вижу смысла в этой проблеме, если код приложения должен быть также подвергнут рефакторингу.
maple_shaft
3
@maple_shaft Согласовано, но ОП говорит, что его попросили создать с нуля новое приложение, которое будет взаимодействовать с базой данных. В таком случае имеет смысл правильно создать новое приложение.
Уэйн Молина
1
@maple_shaft, единственная часть дерьма приложения будет частью, которая взаимодействует с базой данных дерьма. В этом суть архитектуры N-Tier и SOC.
StuperUser
1
@maple_shaft Цель состоит в том, чтобы поместить базу данных в своего рода «черный ящик» и дать приложению интерфейс, который был бы более идеальным и не обязательно представляющим дизайн базы данных.
Майкл Дин
10

Создайте интерфейсный слой, который обрабатывает все содержимое БД, а затем напишите свое приложение для взаимодействия с ним. В случае, если база данных когда-либо будет «исправлена», вы просто замените / обновите свой «интерфейс». Этот подход сэкономил мне массу времени, когда я имел дело с плохой базой данных или базой данных, которая подпитывала другие приложения и не могла быть испорчена.

Ominus
источник
Как вы можете удалить свои собственные ответы или это не возможно?
Оминус
Вы можете удалить свои собственные ответы. Вы продолжаете видеть их с окрашенным фоном, и он будет что-то вроде «удалено владельцем». Кроме вас это увидят только люди с полномочиями модератора.
Марьян Венема
@Ominus: Это должно быть возможно, но почему вы хотите? У тебя 3 отзыва!
FrustratedWithFormsDesigner
1
@Marjan: Модераторы и все, кто имеет> 10K респ.
Джерри Гроб
1
Почему вы хотите удалить этот ответ? Я думаю, что это отличное решение.
Джим Г.
6

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

Я уверен, что вы могли бы рефакторинг, но, конечно, не в такое количество времени.

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

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

maple_shaft
источник
Несмотря на то, что все остальные не знакомы с программированием, я ясно дал понять, как качество этой кодовой базы повлияет на удобство обслуживания. Они находятся на борту с огромным усилием по рефакторингу, чтобы привести все в более подходящее состояние, поэтому я не рискую поставить под угрозу свою работу, но я не думаю, что это произойдет в этом месяце.
Джон Страка
3
Иногда успешный взлом в качестве вашего первого опыта работы с проектом может дать вам возможность рефакторинга в более поздних проектах для того же приложения. Грустно, но правда. Сначала они должны поверить, что вы знаете, что вы делаете, прежде чем они рассмотрят любые радикальные изменения. Плакат в трудном положении, чтобы быть уверенным.
HLGEM
1
@John, это хорошо, что они ПРИЗНАЮТ необходимость рефакторинга. Это признак хорошего долгосрочного менеджмента и первый шаг к фактическому рефакторингу.
maple_shaft
3
+1 за отличный, реалистичный ответ. У вас есть месяц, но на самом деле только полмесяца, потому что вы работаете на полставки на операциях. Это 11-15 дней в зависимости от того, проводите ли вы выходные. Ненавижу это говорить, но я согласен, что вам лучше всего собрать что-то, что работает как можно скорее, и сделать заметки о том, как улучшить или переписать это позже, тем более что ваше руководство работает с рефакторингом.
Боб Мерфи
6

Базы данных могут быть реорганизованы так же, как и другой код. Исправьте часть, на которую влияет код, который вам нужен для написания и написания тестов, чтобы убедиться, что больше ничего не сломается. Делайте по одному маленькому кусочку за раз, как и любой другой рефакторинг. Есть хорошая книга по рефакторингу базы данных, которая может помочь вам начать работу по устранению проблем. http://www.amazon.com/Refactoring-Databases-Evolutionary-paperback-Addison-Wesley/dp/0321774515/ref=sr_1_1?ie=UTF8&qid=1307025831&sr=8-1

Есть и другие, но я лично читал и работал с методами в этом.

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

HLGEM
источник
Это все хорошо, но у меня есть сильное подозрение, что если дизайн базы данных беспорядок, то код приложения, вероятно, тоже ничего не стоит.
maple_shaft
@maple_shaft, это может быть, хотя, по моему опыту, даже хорошие разработчики приложений проектируют ужасные базы данных. В любом случае, только постепенный рефакторинг исправит беспорядок, он не может просто заменить его сразу, хотя я уверен, что ему это понравится.
HLGEM
+1 @HLGEM, это хорошие моменты. Ваш совет верен, если код приложения хорошо разработан. Рефакторинг по частям, наверное, лучший путь, но за всю свою карьеру я никогда не видел такой работы успешно. Возможно, это произошло из-за плохого управления проектами, а не потому, что это неправильная идея.
maple_shaft
5

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

Майк Шеррилл 'Cat Recall'
источник
Это было бы хорошим началом. Если база данных денормализована, то я бы добавил триггеры или хранимые процедуры, чтобы изолировать приложение от денормализации.
Кевин Клайн
4

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

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

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

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

Джерри Гроб
источник
+1, это тоже может быть хорошей идеей, если весь код доступа к данным приложения должным образом отделен от других уровней, и этот код доступа к данным может быть реорганизован для работы с новой схемой
maple_shaft