"Подарки" на Рождество

Лёгкая мишень

Если в вашем поле зрения есть парень по имени Legacy - стреляйте в него. Призрак прошлого не сможет вас достать. Или сможет?...

Что в имени тебе моём?

Legacy - широко распространённый термин в мире программного и аппаратного обеспечения. Это так же распространённый ответ на "почему ваш программный продукт похож на инженерный кактус"?

Инженерный кактус

"Проблема в том, что это Legacy-система". Возможно... Но у меня есть две мои проблемы с этим выражением.

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

Вторая проблема связана с первой - инженерный кактус всю свою жизнь был кактусом. Даже по Legacy-меркам.

Призрак прошлого

Логично ожидать, что постоянно ссылающаяся на Legacy, как причину проблем, софтверная компания пытается понять уроки прошлого. Очень странно, что при этом она продолжает делать кактусы... Или нет?

В ночь перед рождеством

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

Вы не должны знать это

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

Зачем им нужна эта фраза, возвращённая в виде конкатенации кодов символов, чтобы её было нельзя рассмотреть открытым текстом после работы wrap? Если вы надеетесь на утилиту wrap, как сохранность своих секретов... Этот тонкий лёд не сможет выдержать никого.

Ох... ситуация с шифрованием паролей настолько классическая, что такого я не ожидал. Это оказался ключ шифрования DES. У меня заняло примерно 5 минут, чтобы понять, как расшифровать любой пароль в этой системе. Если вся ваша защита построена на недоступности исходных кодов - то это уже security through obscurity. Похоже, что призрак прошлого в очередной раз замаячил где-то неподалёку...

Всё дело в параметрах

Это просто смешно. Вам нужно сделать выборку из all_tab_columns на основе переданных в процедуру параметров - чтобы получить описание колонок в таблице. Проблема в том, что кто-то умудрился обозвать параметры как owner и table_name - точно так же, как и колонки во view :) Что теперь? Ах - мы оформим select в виде динамического SQL и приклеим туда наши параметры owner и table_name. Хм - увидят ли разработчики тот день, когда в качестве параметра им передадут имя функции, которая (например) просто дропнет таблицу, для которой запрошено описание колонок? Кому-нибудь здесь хочется иметь процедуру, которая выполнит любой код с правами владельца схемы?... Между прочим - причём здесь bind-переменные? Они не умели их использовать и 5 лет назад...

Декларативная процедурность

Меня всегда забавляло, зачем люди изобретают процедуры вида DeleteFromTableById. В конечном итоге, чем DeleteFromTableById('my_tab', 'id', 10) проще, чем delete from my_tab where id=10? Зато, какие большие просторы для полёта фантазии любителей SQL Injection... В реальности эта процедура должна называться DoWhateverYouWant.

Какие колонки

Это я приберёг на последок. Контролировать количество и имена возвращаемых запросом колонок можно, если переписать всё на динамический SQL и сразу после select клеить функцию, которая этот список возвращает. Дайте мне отдохнуть - я забыл, когда в Oracle появились view...

Призрак в ваших дверях

Вы видите его. Он никуда не делся. И, что самое страшное, - он не похож на Legacy.

Можно ли убить призрака

Нет. Но его можно отправить в Legacy-мир. Для начала призрака прошлого стоит найти. И я посоветую им начать свой поиск с зеркала.