Что десктопу хорошо, то вебу ― смерть

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

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

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

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

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

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

Зона ответственности ни разработчиков сайта, ни менеджеров по развитию, ни тестировщиков, не включает нормальную скорость работы сайта. Обычно скорость эта колеблется от удовлетворительной до грани с критической. Для решения этого не существует правил разработки, так как текущие и повсеместно распространённые критерии - сделать программный продукт максимально гибким, уменьшить связанность его компонентов и задать стандарты для новичков. Цель таких рекомендаций очень благородная, для улучшения жизни разработчиков, предсказуемости и быстроты внедрения нововведений и быстрого следования по лабиринту развития программы вслед за мыслями продакт-менеджера.

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

"Правильная" архитектура для абстрактного кода, в конкретном случае, для веб-приложений подходит только частично. В среде веб-программистов сложилось противоречие, когда быстро работающее приложение или фреймворк исключают из рейтинга из-за того, что код написан не по канонам, но в то же время не исключают оттуда приложения написанные "по учебнику", но работающие медленно и жрущие много ресурсов. Раньше такие заявления мне часто встречались по поводу фреймворка FatFree, мол, да он быстрый, но так как создатели его прибегли ко всяческим ухищрениям для этого, то понятное дело, он отверженный, неприкасаемый и вообще фу! и это писали люди, связанные с веб-разработкой, краеугольный камень которой как раз скорость работы. Классическая ситуация в таком случае, это когда владелец компании спрашивает разработчика, почему сайт так медленно работает, а ведь его только начали делать, тот отвечает, мол, мы же используем Laravel и диалог на этом исчерпан. Несомненно, что это означает удобство для разработки, комфорт для программистов, но не для пользователей ресурса и как выясняется не для его владельца.

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

В реальности коду приходится миновать логичные стадии - легаси в стартапе, рефакторинг при развитии стартапа в ООП, глобальная переделка на DDD на следующих этапах, когда код начинает приносить доход и внешний вид его сформировался, а компания заняла нишу и можно строить внятные модели. Многие затягивают на этих этапах, не расширяя штат разработчиков, экономя на архитекторах, поэтому мы получаем то что есть. Тем не менее стоило бы создать отдельные правила и паттерны для веб, даже для каждого языка программирования и следовать им. Тем более, что у веб есть аксиомы при которых оно вообще существует, обработка запроса от пользователя и специфические условия его обслуживания и другие, которые не нужно делать излишне независимыми, так как в этом нет смысла.