«У Нас Кончились Столбцы» — Лучшая Худшая Кодовая База. Начало
Все мы мечтаем работать с передовыми технологиями, современными системами, чистым и понятным кодом. Однако, если вы приходите в компанию, где кодовой базе исполнилось 10+ лет, вы неизбежно столкнётесь с тем, что взорвёт ваш мозг (не спрашивайте, откуда я знаю). Но эта история поразила даже меня. Текст довольно длинный, будет разбит на несколько постов, но я решил его не сокращать, чтобы не лишать вас удовольствия.
Когда я начал программировать в детстве, я не знал, что людям платят за программирование. Даже когда я окончил среднюю школу, я предполагал, что мир «профессиональной разработки» выглядит совсем иначе, чем код, который я писал в свободное время. Когда мне повезло попасть на свою первую работу в сфере ПО, я быстро понял, насколько я был прав и неправ. Моя первая работа была испытанием огнём, и по сей день эта кодовая база остается худшей и лучшей кодовой базой, над которой мне когда-либо доводилось работать. Хотя кодовая база навсегда останется в этой конкретной компании, я хочу поделиться с вами некоторыми из её самых забавных и страшных историй.
База данных живёт вечно
В большой устаревшей системе БД — больше, чем место для хранения данных, она — источник культуры. БД устанавливает ограничения на то, как работает система в целом. Это точка, где встречается весь код. БД — это место водопоя, и в нашем случае он был довольно загрязнён.
Вы знаете, что у SQL Server есть ограничение на количество столбцов в таблице? Я тоже не знал. В то время их было 1024, сегодня, похоже, 4096. Само собой, большинству людей это знать не нужно. Мы знали. Причина в том, что в Merchants (наша таблица для хранения информации о клиентах) давно закончились столбцы. Решением стала Merchants2. Таблица с (если правильно помню) 500+ столбцами.
Merchants (и её лучшая подруга Merchants2) были источником жизненной силы системы. Всё крутилось вокруг Merchants так или иначе. Но Merchants не была единственной (или двойной) таблицей. Было много правильно нормализованных таблиц, все с внешними ключами к Merchants. Но одна из них всегда будет занимать особое место в моем сердце, SequenceKey.
SequenceKey
------------
SequenceKey
------------
1251238
------------
Для простоты понимания я воссоздал всю таблицу SequenceKey выше. Да. Вы правильно прочитали, это вся таблица. Таблица с одним ключом и одним значением. Можно сказать, что SequenceKey - идеальная таблица. Что может быть проще?
Но вы можете спросить себя, какое возможное применение может иметь таблица с одним столбцом и строкой? Генерация идентификаторов. Как мне сказали в то время, когда-то давно SQL Server не поддерживал автоинкрементные идентификаторы. Это был принятое, правильное решение. Мои попытки выяснить, правда ли это, были безрезультатными. Но на практике её роль была гораздо большей.
SequenceKey была связующим звеном. В каждой хранимой процедуре, которая создавала новые сущности, вы сначала брали ключ из SequenceKey, увеличивали его. А затем вставляли его в качестве идентификатора в N разных таблиц. Теперь у вас было неявное соединение между всеми этими таблицами сущностей. Если вы видели идентификатор в системе, то была большая вероятность, что связанные таблицы будут иметь строку с точно таким же идентификатором. Честно говоря, довольно умно.
Календарь
База данных может существовать вечно, но наша система входа была ограничена календарём. Я не имею в виду настоящий календарь. Я имею в виду таблицу базы данных под названием calendar. Что она содержала? Заполненный вручную календарь. Когда я спросил нашего местного гуру (которого звали Мунч), он сообщил мне, что, когда календарь заканчивается, мы не можем входить в систему. Это произошло несколько лет назад. Поэтому они заставили стажёра заполнить ещё 5 лет, чтобы убедиться, что этого не произойдет в ближайшее время. Какая система использовала этот календарь? Никто не знал.
Продолжение следует…
Источник: https://jimmyhmiller.github.io/ugliest-beautiful-codebase
Автор оригинала: Jimmy Miller