Читая русские переводы Worse Than Failure мне вспоминаются во многом похожие ситуации из моей собственной рабочей практики. За 8 лет в ИТ накопилось таких примеров много, приведу один из наиболее запомнившихся.
Много лет назад лет назад я работал в одной крупной и весьма известной компании и руководитель одного из проектов обратился ко мне с вопросом знаю ли я MS SQL и ASP. Я тогда не считал себя выдающимся специалистом в обеих этих технологиях, более того это были мои наименее любимые технологии из всех имеющихся, но соврать что незнаю я не решился и ответил «Немного». Так в одночасье я был подключён к этому проекту и представлен заказчику в качестве «MSSQL Гуру» для решения, немного-немало, а проблему крайне низкой производительности одной из частей – админского интерфейса.
Первое что я сделал, постарался вытянуть из пользователей максимум информации при каких обращениях идёт торможение, всегда ли оно есть или зависит от времени суток и так далее. Информация была очень противоречивой, начиная с того что иногда «всё летало» иногда были задержки при загрузке до 10-20 секунд. Главное что удалось так это сузить область «торможения» до одной конкретной страницы.
Итак, имея на руках эту информацию и уже узнав что база данных над которой этот интерфейс работает является если не огромной, то весьма большой – несколько десятков гигабайт. А также что объёмы прокачиваемых данных там огромны и постоянны, и есть N-ное число Job’ов выполняющихся по несколько часов, я сделал первое, и ошибочное предположение, что проблема в нагрузке на SQL. На следующий мне удалось провести перехват SQL запросов с этой страницы в разное время суток, от раннего утра и до практически ночи и результат был один – SQL запросы в худшем случае проходили за 2 секунды, что никак не укладывалось в предположения о проблемах в производительности именно в этой части.
Предположение второе было в том что вдруг код ASP страницы написан так что при разборе SQL запроса тормозит именно он, благо с подобным в своей практике я сталкивался не раз. После тщательной обвязки трассировочными запросами во всех кусках страницы где эти SQL запросы происходили и это предположение не подтвердилось.
Не веря что такое может быть я обвязал трассой буквально всю страницу, сделав её особый вариант и, обнаружил тот самый искомый бермудский треугольник. Среди выбираемых из СУБД данных, был ряд булевых значений которые в дальнейшем программист проверял своей специальной функцией, что-то вроде checkBoolean. Эта функция работала очень просто она преобразовывала значение в строку и сравнивала его со значением в «True». Учитывая что таких булевых значений было несколько тысяч, то, понятное дело, страница конкретно тормозила при отображении. После исправления функции на проверку в используя стандартные средства VBScript’а, отображение стало буквально мгновенным, а различная скорость отображения в разное время суток зависело от числа строк на странице, в разное время их было разное число, вот и цифры существенно различались.
Поэтому когда я читаю про схожие примеры кода от индийских программистов, я совершенно неудивляюсь и скажу больше такие ошибки вредны не только с точки зрения красоты кода, но и с точки зрения того как потом другим приходится решать проблемы вроде тех что описываю выше.
