Цена плохого кода.

История одной ошибки плохого проектирования базы данных.

Привести БД к первой нормальной форме.
Запись в бактрекере.

Описание задачи.
В разрабатываемом продукте есть два объекта связанные отношением многие ко многим. Структура БД просто напрашивается. Две таблицы связываются промежуточной таблицей связей, с дополнительным столбцом типа связи (можно по-другому, но это не принципиально).

Техническое решение.
В таблице скриптов в столбец типа скрипта дополнительно прописывается идентификатор ссылки и тип скрипта.

Результат.
Ошибка детская и имеет очень простое название: «База данных не приведена к первой нормальной форме». Но вот цена ее оказалась неожиданно высокой. Программист, в какой то момент уволился из фирмы, а код остался. Да код работает, но его надо тестировать, развивать и сопровождать. И каждый работник, сталкивавшийся с этим участком, был вынужден тратить массу своего времени на то, чтобы понять, как же это работает, и как с этим поступить. Сначала возникли сложности с тестированием целостности данных, затем с дальнейшим развитием кода, потом понадобилось изменить формат идентификаторов. Все задачи тривиальны, если все сделано правильно, но, сколько усилий требуется при работе с такой вычурностью! По моим подсчетам из-за этой тривиальной ошибки фирма потеряла около двух человеко недель или, в переводе на деньги, более тысячи долларов.
Хорошо бы заложить в план рефакторинг, но, но, но… Проект не стоит на месте, клиенты требуют новой функциональности, сроки поджимают, ресурсов не хватает… А плохой код ждет очередной жертвы.

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

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.