Что такое технический аудит фронтенда
Любой проект рано или поздно сталкивается со сложностями масштабирования: чем больше работ производится, чем больше людей подключается, тем больше проблем возникает. Это приводит к тому, что на исправление ошибок, рефакторинг, обслуживание технического долга уходит больше времени и сил, чем на непосредственно разработку.
Для таких ситуаций существует технический аудит. Он позволяет не только выявить слабые места проекта, но и составить стратегию по усилению этих мест. Сам по себе аудит не дает прямой ценности для продукта, как написание функциональности, но оптимизация кода облегчает поддержку и развитие проекта, что дает выгоду в долгосрочной перспективе.
Для чего важно проводить технический аудит
Самая частая причина, по которой проводится аудит клиентской части приложения — это какие-то проблемы. Например, долгая загрузка страницы сайта, эффект мигания при загрузке, сломанная верстка, непонятные скрипты и ошибки. Зачастую сложно понять, откуда эти проблемы берут свое начало, и тогда необходим углубленный анализ.
Услуга аудита важна не только при наличии очевидных проблем. Владельцу продукта может казаться, что приложение работает стабильно, но на самом деле «под капотом» могут быть проблемы, которые всплывут на поверхность только спустя определенное время и могут сильно повлиять на дальнейшие работы. Особенно важно это понимать в следующих ситуациях:
- На этапе покупки и внедрения стороннего продукта. Когда компания приобретает результаты работ сторонних разработчиков, нужно убедиться, что система сама по себе работает стабильно и не потребует значительных доработок при внедрении.
- При масштабировании продукта. Перед внесением глобальных изменений в приложение важно провести аудит, чтобы понимать, сможет ли система выдержать возрастающую нагрузку.
- Если вы новый IT-директор/менеджер продукта и не знаете всех особенностей проекта: какие технологии применяются, есть ли архитектурные ограничения, устаревшие библиотеки, что требует повышенного внимания.
- Весь проект был завязан на исполнителях, с которыми нет возможности связаться. В таких случаях базу знаний нужно восстанавливать, чтобы владелец мог иметь представление о текущем состоянии проекта и возможностях его развития.
Как проводится технический аудит
Проведение технического аудита фронтенда состоит из нескольких этапов:
1. Анализ с помощью готовых инструментов
Отправная точка для углубленного анализа. На этом этапе проводится анализ с помощью готовых инструментов, например, Google Pagespeed, Lighthouse и Web.dev. Они позволяют понять, какие скрипты тяжелее всего грузятся, как быстро происходит первая отрисовка контента и покажут, что можно оптимизировать: изображения, шрифты, стили, обработку кэша и т.д.
Стоит обратить внимание, что сервисы по типу Google Pagespeed Insights дают только рекомендации по улучшению сайта, но выполнение этих рекомендаций не гарантирует прироста баллов или скорости загрузки. Поэтому программист должен лично решить, на какие рекомендации стоит тратить время.
2. Исследование запросов через API.
На этом этапе разработчик проверяет взаимодействие клиентской части приложения и серверной. В рамках этого анализа проверяются запросы, которые могут сильно нагружать систему, возвращаются с ошибкой, не отправляются или дублируются.
3. Анализ внешних скриптов.
Практически ни один современный сайт не обходится без использования сторонних скриптов. Даже на лендинги устанавливаются скрипты для сбора метрик и аналитики от Яндекс или Google. Метрики тормозят загрузку, так как собирают все данные о пользователе при посещении сайта. Удалить их нельзя, изменить код тоже, так как ресурс внешний. Поэтому разработчик изменяет время запуска метрик, чтобы это не отразилось на времени первичной загрузки контента.
4. Профилирование загрузки страниц.
С помощью специального ПО выявляются слабости технологической составляющей проекта. Собираются данные о производительности веб-приложения, и на их основе программист выделяет самые проблемные места, которые нужно оптимизировать.
5. Нагрузочное тестирование
Сервис может стабильно работать в «вакуумных» условиях, когда все проходит идеально: нагрузка сервера слабая, клиент имеет стабильное подключение к интернету и мощное устройство. Но в жизни важно учитывать, что такие условия соблюдаются далеко не всегда. С возрастающей нагрузкой на сервер время выполнения запросов может многократно увеличиваться, что отразится на клиентской части приложения.
6. Семантический и статический анализ кодовой базы
На этом этапе анализируется исходный код. Программист делает это как вручную, так и с помощью линтеров и другого ПО. В некоторых компаниях есть свои стандарты оформления кода (код-стайл), но на практике они не всегда соблюдаются.
Например, могут быть обнаружены неиспользуемые функции, дублирующийся код, пустые блоки и другие детали, которые не несут прямого вреда, но накапливают мусор в кодовой базе. Со временем этот мусор начинает превращаться в баги и технический долг, поэтому лучше чистить его своевременно.
Результат технического аудита
В результате грамотно проведенного анализа получится уникальный документ на десятки страниц, в котором будут отражены все самые важные моменты. Специалист отметит не только проблемные места проекта, но и способы их исправления. В перспективе аудит поможет любому привлеченному на проект исполнителю быстрее погрузиться в контекст, а также составить представление об объеме предстоящих задач.
Исполнители могут порекомендовать сделать полный рефакторинг проекта, но так как это дорогостоящая и долгосрочная работа, то такая рекомендация обязательно должна быть аргументирована.
Наши специалисты по техническому аудиту фронтенда
Технический долг на проекте может быть неумышленным. Причины для этого разные: неверно выбранные технологии, слабый менеджмент, низкая квалификация программистов или несоблюдение методологий разработки. В таком случае понадобятся рекомендации со стороны.
Исполнители, которые разрабатывали продукт, могут защищать свои разработки даже при наличии проблем. Это называется умышленным техдолгом. Например, недобросовестный специалист не будет сообщать о том, что созданный им компонент содержит множество ошибок. Поэтому важно, чтобы аудит проводила третья сторона, которая не соблюдает интересы конкретных людей или компаний.
Провести аудит может не каждый фронтенд-специалист. Умения хорошо писать код недостаточно, программист должен уметь его оптимизировать. Поэтому в Work Solutions аудит делают только старшие специалисты с соответствующими компетенциями.
Почему мы
В процессе знакомства с проектом мы часто сталкиваемся с техническим долгом и легаси кодом. К нам приходили проекты, которые теряли своих исполнителей, или системы, которые переставали функционировать, из-за чего владельцам начислялась неустойка. У нас имеются кейсы как полного рефакторинга, так и частичной оптимизации проектов. Поэтому мы можем не только предложить варианты решения существующих проблем, но и предусмотреть возможности для масштабирования продукта.
