Представим, что любой проект в IT-компании — это живой организм. С живым организмом могут случаться траблы, что-то болит, а что — не понятно. Обычно, людям в таких случаях помогает тщательный осмотр специалиста и намеченный план лечения. И вот мы однажды задумались, а почему бы не поиграть в докторов и не проводить исследования на поиск и решение проблем и для наших проектов. В этой статье расскажу, как мы это реализовали и покажу реальные кейсы.
Есть у нас очень классный проект Тайрай, мобильное приложение для сети массажных салонов по всей России. На каком-то этапе разработки мы поняли, что что-то идет не так. Баги сыпятся со всех сторон, непонятно, откуда ждать новые просадки. Оказалось, что наш пациент проект немножко заболел и ему требовалось тщательное обследование. Вариантов было несколько:
1. Исправлять баги по мере поступления.
2. Вносить изменения в проект без четкой системы и организации процесса.
3. Забить и счастливо жить дальше.
4. Продумать конкретный механизм для полного анализа проекта, который будет охватывать несколько областей.
Конечно же, мы выбрали 4й вариант. Нам важно создавать качественный продукт, который будет отвечать всем запросам заказчика. Мы провели исследование и продумали четкие шаги, которые помогли нам тщательно проверить и устранить все неровности проекта. Так и было придумано МРТ при разработке проектов. И да, никакой особой расшифровки тут нет, все, как и в медицине — магнитно-резонансная томография 🙂
МРТ (в понимании Флага) — глубинный анализ проекта. Выявление узких мест при разработке для их последующего исправления.
Для начала мы выделили несколько областей, по которым мы проводим МРТ:
👉 Разработка (разработчик)
👉 Тестирование (тестировщик)
👉 Управление (проект-менеджер/продукт-менеджер)
👉 Инфраструктура (DevOps инженер)
👉 Документация (Системный аналитик)
Посмотрим, как проводить МРТ в каждой из этих областей.
Для удобства мы создали Google таблицу, в которой обозначили все необходимые колонки.
Категория. Области исследования, о которых писали выше. Документом пользуется вся команда, поэтому в нем мы указываем все области, в которых необходимо провести МРТ.
Уровень. Указывает важность и приоритет конкретной задачи. Это помогает команде декомпозировать свои задачи и приступать к ним по мере необходимости.
Проблема. В этом столбике указываем саму проблему. Здесь могут быть как баги, так и вопросы по интеграции, добавлению новых фич и т.д.
Причина. Немаловажный столбик. В нем указывается причина возникновения конкретной причины. Естественно, у многих проблем может быть одна причина. Это помогает нам отследить закономерность и не допускать эти проблемы в дальнейшем.
Решение. С проблемами и причинами определились, пора их решать. Прописываем конкретные шаги для устранения неприятностей.
Уровень (проект/студия). Важный столбик, который помогает отследить возникновение проблем у конкретной команды на конкретном проекте, или же на уровне студии. Например, проблемой на уровне проекта может быть отсутствие мониторинга на проде, а на уровне студии отсутствие регламента по мониторингу на проде.
Ответственный. Тот, с кого Миша будет спрашивать результат 🙂
Исполнитель. Супермен или супервумен, которые занимаются устранением конкретной проблемы.
Задача. Линкуем проблемы с конкретной доской Трелло или задачей в Jira. Все задачи находятся на своих местах, ничего не теряется и не игнорируется.
Срок. Ну а куда без дедлайнов?
Статус. У задач есть несколько статусов: готово, WIP (от англ. «work in progress» — в процесса), проверка, под вопросом,
Артефакт для клиента. Если задача связана с конкретным документом, например, ТЗ, то мы указываем ссылку на него. Но зачастую это может быть просто какой-то факт того, что задача выполнена.
Результат. Прописываем, как удалось решить проблему, что получили в итоге.
Теперь давайте разберем, что мы проверяем на конкретных областях. Для вашего удобства подготовили мини чек-листы.
Не стоит объяснять, насколько важна эта область МРТ при создании цифрового продукта. В этой области мы проводим тщательный анализ всех страниц, скорость их загрузки, код ревью компонентов, аудит инфраструктуры проекта и другое. Мы разбили область проверки разработки на несколько категорий, чтобы не упустить ни одной детали.
✅ Слабый пароль на админку?
✅ Есть ли защита от перебора паролей на админку?
✅ Пакеты с известными уязвимостями установлены?
✅ SQL-инъекции. В особенности, характерные для данного фреймворка.
✅ Защита от DDOS-атаки.
✅ Защита SSH от подбора паролей.
✅ Закрыт порт к БД.
✅ Нельзя вывести список файлов на сервере в браузер.
✅ Насколько быстро открывается главная страница/экран приложения?
✅ Насколько быстро открываются нагруженные страницы. Например, поисковая выдача, применение фильтров, вывод объектов на карте и т.д.
✅ Насколько быстро на приведенных выше примерах отвечает сервер? Загружается статика? Рендерится JS?
✅ Насколько большой размер у приложения? JS-бандла? HTML-страницы?
✅ Какую нагрузку может выдержать проект по одновременным посетителям или запросам в секунду?
✅ Используется ли типизация для параметров и возвращаемых значений методов?
✅ Есть ли «магические» числа? Хардкод?
✅ Есть ли замыкания в роутинге?
✅ Есть ли обращения к .env где-то кроме config?
✅ Используются ли миграции, сиды, фабрики? Используются ли ограничения для связей и предусмотрена ли логика удаления родителей?
✅ Есть ли бизнес-логика в контроллере? Контроллеры должны быть максимально тонкими (в них не должно быть никакой бизнес-логики и реализаций методов кроме запросов POST, GET).
✅ Используются ли Resources?
✅ Используются ли Requests?
✅ Есть ли бизнес-логика или обращения к БД в шаблонах Blade?
✅ Есть ли документация для API (Swagger, Scribe)? Актуальна ли? Проверить 🙂
✅ Логируются ли HTTP-запросы (Graylog) при обмене данными с 1C?
✅ Соблюдаются ли соглашения об именовании таблиц в СУБД, переменных, методов, классов, констант и т.д.
✅ Используется ли DTO (Data Transfer Object)
✅ Компонентная структура, использование стейт-менеджеров, проверка кода на bad practices, типизация, тесты.
✅ Аудит верстки (корректность, количество и правильное подключение внешних скриптов).
✅ HTTP-запросы (сжатие данных в запросах, отсутствие избыточных данных, корректная обработка ошибок запросов, нет дублирующих запросов).
✅ Аудит инфраструктуры проекта (размер бандла, правильная настройка webpack для разных окружений, корректное подключение стилей и js, линтеры).
✅ Оптимизации. Корректные размеры и форматы изображений, видео, оптимизация изображений, размеры и форматы шрифтов.
✅ Проверить на возможность реиспользования, разделения или выноса частей кода.
✅ Предусмотрена ли Retina.
✅ Проверка верстки на частые косяки (внешние ссылки без rel nofollow noopener, нет дефолтных размеров для картинок и видео и т.д.).
✅ Проверка на доступность интерфейсов.
✅ Проверить соблюдение семантики.
✅ Проводится ли код-ревью на проекте? Когда проводилось в последний раз?
✅ Пишутся ли unit тесты?
✅ Как часто проводится рефакторинг?
✅ Установлены ли линтеры и используются ли?
✅ Собирается ли Docker образ на продакшен сервере? Хранится ли код сайта наживую на продакшен сервере?
✅ Есть ли другие ошибки/недочеты в docker-compose.yml. Например, зафиксированы ли версии родительских образов (без всяких latest).
✅ Правильно ли хранится состояние проекта? Медиафайлы хранятся прямо на вычислительной машине (неправильно) или отдельно на S3?
✅ Где хранятся логи PHP и веб-сервера? На вычислительной машине или отдельно в Graylog? Есть ли ротация логов?
✅ Есть ли на сервере SWAP и каков его размер?
✅ Есть ли мониторинг ресурсов? Правильно ли подобраны ресурсы сервера: RAM, CPU, жесткий диск.
✅ Настроен ли мониторинг свободного места на диске?
✅ Как организованы бэкапы? Бэкап базы данных, загруженных медиафайлов? На отдельном хранилище (правильно) или прямо на вычислительной машине?
✅ Есть ли алерты на заканчивающееся место на сервере?
✅ Правильно ли организованы релизы. Используются ли релизы в джире и все ли там верно сделано. Совпадают ли релизы джиры с тегами в Git
✅ Выполняются ли автотесты в CI/CD?
✅ Используются ли git хуки для линтеров и автотестов?
✅ Есть ли на проекте Nova Bar с актуальными данными? В помощь на открытый пакет.
✅ Нотификации в Mattermost по выкатам (или пайплайнам).
✅ Закрыты ли тестовые и стейджинг площадки от индексации поисковыми системами?
✅ Есть ли в проекте дока по развёртыванию? Актуальна ли она? Попробовать запустить проект по этой доке.
✅ Какая версия HTTP используется? (должна быть 2+)
МРТ — это необходимый этап проверки качества ваших услуг. Проводите глубинный анализ ваших проектов с периодичностью в полгода или год, а также, когда чувствуете, что скоро возникнут проблемы. В дальнейшем это поможет систематизировать все ваши пробелы, исправить их, и стать еще круче 🙂
Остались вопросы? Пишите в комментариях, все обсудим.
А если вашему проекту нужен технический аудит, то для этого у нас есть специальная услуга. Подробная информация у нас на сайте.
