О том, почему следует использовать по максимуму нативные решения в программных продуктах

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

История раз. Не моя. В аську написала девушка, с которой мы однажды работали над неплохим интернет-сайтом. Жаловалась девушка на программиста, который тормозит со сроками решения задач по нескольким сайтам на CMS NetCat. В бытность уже после проекта я сам, вообще-то не баловал быстротой и отзывчивостью, просто потому что форматы задач наши окончательно перестали совпадать. Но, видимо, в разгильдяйстве я таки не чемпион.
Любопытство победило апатию от тяжелой осенней погоды, и я таки решил глянуть, что там как. Сам, без оркестра.

Значит, что тут у нас по списку – форма не отправляется в англоязычной копии сайта, а в русской все хорошо? Ну хорошо, смотрим в код. Форма как форма, код, кажись, правильный. На форме висит JS, который почему-то подтягивается с другого домена. Может ли быть тут проблема? Ну, теоретически, да, мало ли там где жесткую привязку к родному домену захардкодили. Посмотрим, проходит ли вообще отправка и куда. Обработчик формы описан как будто в структуре системы. Посмотрим, что он вернет. Включаем монитор HTTP-запросов, заполняем форму, отправляем. Опа! А ответил нам вовсе даже не обработчик внутри системы, а какой-то mail.php! В НетКате никакого такого скрипта я не припомню, но это и неважно. Вернулся код ошибки 404, то есть нет там никакого обработчика. Не-ту! Смотрим в русскоязычную версию сайта, где форма работает ок, не теряя время на форму, обращаемся к обработчику напрямую, через адресную строку – риск ложноотрицательного результата есть, но вдруг? А вот тут  – обработчик таки есть.

Ситуация становится ясной. Движок НетКат – редкостный уродец с точки зрения удобства разработки. Платный, между прочим. Настолько уродец, что даже сами разработчики в форуме техподдержки рекомендуют взамен нативных инструментов феерически монструозные колхозы. Тут, конечно, не тот случай, но тем не менее, разработчик решил не тратить время на описание процедуры отправки письма в странном и фантастически неудобном интерфейсе разработчика в движке, а воспользовался легким и удобным для него внешним скриптом, на который как-то хитро приделал редирект. Вот только при “клонировании” сайта для перевода на другой язык файлик со скриптом благополучно забылся. Или редирект потерялся.
Результаты осмотра  и опытов  я радостно и доложил коллеге, приложив ценник на устранение проблемы, естественно с учетом того процесса, что я сейчас только что описал. Прикинув, что на эти деньги можно неплохо посидеть в каком-нибудь японском ресторане или вкусно поужинать в обычном, девушка ушла отвешивать пендаля штатному работнику. Может, еще вернется. Но экономика разработки проектов сурова – исправление чужих косяков всегда недешево.

История два. Моя. Клиенты пожаловались на то, что “сайт тормозит”. Вообще-то, давно уже жаловались, но сейчас, в сезон высоких продаж, допускать минутные простои и белые экраны вместо интернет-магазина стало совсем неприлично.

Опросил жалобщиков из числа работников, понаблюдал сам. Действительно, виснет. Жестко причем. Рвется соединение  с базой данных MySQL. Вскрытие показало, что база исчерпывает число одновременных соединений и отваливается. Это при том, что включено кэширование результатов запросов – ага, не впервой уже тормозим.

Ну хорошо. Раз у нас не хватает числа соединений, озадачиваю хостера – а чо так мало их? Парни с хостинга парируют, что  должно хватать, и проблемы надо искать на стороне скрипта. Ну, в общем-то логично, если выстроить цепочку “долгий запрос = долгое соединение = новые соединения добавляются = достигают лимита = БД кирдык”. День я провел за наблюдениями за процессами через phpMyAdmin. Да, запросы висят аж по минуте, но в интерфейсе не. Совместно с парнями с хостинга мы таки выделяем проблемный запрос. ребята ставят опыты – запрос тормозит даже на пустом сервере, но существенно, более чем в 1000 раз ускоряется, если убрать из условий “родную” случайную сортировку. Поскольку мое знакомство с DBA и LAMP-админством именно что “менеджерское”, иду изучать матчасть. Гугление проблемы показало, что таки да, проблема у СУБД MySQL с рандомным выбором имеется, как и имеется немало способов ее решения, например, как в этой статье: “MySQL оптимизация: ORDER BY RAND()”.

Итак, с указанием от сисадминов, в какую сторону копать, я возвращаюсь к скриптам. Архитектура движка Zen Cart, даже после наших прошлых оптимизаций – адский ад. Вообще говоря, о том что это поделие – не лучший выбор для построения большого интернет-магазина в 2009 году, и стоит, пока не поздно, рассмотреть вопрос замены платформы, я сообщил хозяину проекта буквально на первых же переговорах по вовлечению меня в тогда еще разработку магазина. Но поскольку на тот момент часть работы была сделана, хозяину она представлялась как “почти готовой” и вообще “уплочено”, пришлось работать с тем, что есть.  Но как бы то ни было – погружаюсь в код. Погружаюсь, и  вижу, что несмотря на общий мрак и ужас в архитектуре скрипта, конкретно эта проблема решена весьма изящно – случайный выбор полностью перенесен в приложение, и, более того, осуществляется на уровне слоя работы с БД, то есть универсально. Проглядываю, тем не менее, все места, где может использоваться “рандом” – нигде, кроме одного малозначимого места, нативный механизм случайного выбора ни подменен, ни продублирован. Казалось бы, тупик.

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

Нативный драйвер БД от магазина сюда, конечно же, не приплести. Но перенести логику случайного отбора идентификаторов товаров из всех имеющихся из БД в скрипт, а из БД тащить уже конкретные товары – задача, которую я решил на PHP за 15 минут, не обращаясь к кодерам. На этапе тестирования решения обнаружилось еще и то, что система интеграции интернет-магазина с системой учета и торговли (1С, конечно же) исправно засирает базу данных дублями, которые не вылезают в скриптах благодаря грамотным запросам, но, конечно, изрядно тормозят систему – таки есть разница, перебрать в таблице вместо 1000 строк все 50000, да еще и с “отягчающими данными” из других таблиц? Интеграция, конечно же, тоже самодельное поделие, доставшееся мне “по наследству”.

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

Написать ответ

*
Введите латинские буквы\цифры, показанные на картинке
Anti-Spam Image