Чек-лист: технический аудит IT проекта

35 вопросов для быстрой оценки качества IT проекта.

Привет, Хабр! Бывают в жизни ситуации, когда надо оценить качество проекта сразу по всем статьям. Можно заказать аудит извне, а можно проверить все самостоятельно, воспользовавшись следующим гайдом. 

У меня бакалаврская степень по Прикладной информатике (Корпоративные информационные системы) и 6 лет опыта в веб-разработке, поэтому я составила данный чек-лист (который вы найдете в конце) со 100-балльной системой, который даст примерное представление о качестве проекта. Материал больше подойдет свежим проектам, хотя и для несвежего тоже может быть полезно.

Я разделила статью на подпункты проверки с кратким описанием критериев. Возможно вы найдете в них инсайты и углубитесь в какую-то тему глубже.

1. Требования и обязательства

Прежде всего изучаем требования от заказчика — основные сроки сдачи / выкатки фич. Проверяем обязательства перед организациями, если имеются аккредитации (условия получения/поддержания). Выписываем все контрольные даты.

Тут же проверяем документацию требований — описание процессов системы. В идеале BPMN/Activity/IDEF0. Почему? Графический способ представления информации наиболее быстр в понимании, а популярные нотации понятны всем и однозначны в интерпретации.

2. Методология разработки

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

3. Система управления проектами

Необходима система управления проектами, предпочтительно Jira / Redmine / Trello / Asana / Microsoft Project. 

Для Agile нужна доска задач текущего спринта с тестированием, для Waterfall — диаграмма Ганта. Важен беклог с задачами. В Agile/Scrum задачи должны быть структурированы (Epic > Story > Задачи + Test execution).

Важны чёткое описание и заголовок задачи, указание на тестирование и прикрепление коммитов для интеграции с репозиторием.

Тут же сверяемся со сроками из пункта 1. Возможно планы будут в другой системе, это не проблема. Проверьте соответствие планам и риски. Очевидно если есть несоответствие — надо что-то менять.

4. Репозиторий

Смотрим на ветки в проекте, по ним будет понятен git flow. Плохо если веток мало — только master и develop, например. Фичи должны разрабатываться в отдельных ветках, они должны существовать. 

Далее идем в Merge requests. Там должно быть:

• Нормальное описание

• В коммитах должен быть указан номер задачи, без этого код через пару лет превратится в ад, не найдешь концов

• Должны быть дискуссии, по крайней мере в больших MR’ах, Approves — иначе произвол

• Pipeline — должен быть. В проверках — сборка, линтер, тесты (+ результат развертывания, статический анализ по желанию)

5. Состав команды

Тут много вариантов, но хороший базовый вот такой:

• фронтенд

• бекенд

• дизайнер

• продакт

• проджект

• тестировщик

• девопс

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

6. Релизы и окружения

Несмотря на стадию проекта — план должен быть. Самый стандарт по окружениям — dev, prod, stage. По релизам должен быть план — Git flow, Continuous Deployment.

Также должен быть план для управления hotfixes и emergency releases, чтобы гарантировать стабильность и непрерывность работы в production среде.

7. Развертывание

Если девопс все-таки есть, стоит для начала посмотреть на диаграммы развертывания. Тут стоит оценить, нужен ли докер или другие инструменты контейнеризации, а также приложения для оркестровки контейнеризованных приложений (k8s и т.п.). Особенно актуально для нескольких окружений, если хочется автоматического развертывания (например, чтобы избежать ошибок при развертывании очередного окружения) и в целом для больших приложений, микросервисных архитектур.

8. Тестирование

Тут мы говорим о тестировании отдельно от разработки. По моему опыту самое важное тут — exploratory testing. Поскольку задачу после выполнения может проверить и сам разработчик при помощи друзей-разработчиков, а вот промежутки между задачами особо никак не проверишь. Некоторые вещи просто стоит порой протыкивать вручную. И это на мой взгляд самое важное. Конечно лучший вариант — когда есть и ручное, и автоматизированное тестирование, но даже когда оно только ручное — это уже хорошо.

Плюсом будет также нагрузочное тестирование.

9. Код

Прежде всего — должны быть выбраны современные технологии. Чтобы никого не обидеть, скажем так: версии фреймворков, библиотек, интерпретаторов/компиляторов не должны быть древними, соответствовать современным тенденциям. Пример (февраль 2024):

PHP 8 — норм, PHP 7 — устаревший. 

Node 16 норм, Node 13 — устаревший.

Если есть экспертиза — можно проверить, есть ли архитектура в приложении и современная ли она. 

Тесты должны быть.

Проверьте любой файл — насколько он читабелен, есть ли комментарии. Eсли есть экспертиза — можно взглянуть поглубже (SOLID, принципы проектирования).

Есть ли линтеры.

Если фронтенд должен индексироваться — очень желательно SSR.

Документация — как устроено приложение. Я предпочитаю диаграммы классов (вообще все UML диаграммы мне симпатичны), но подойдут и другие популярные способы представления информации.

10. Техническое соответствие

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

Безопасность: Проверки на уязвимости и сканирование кода на наличие потенциальных угроз (можно прямо в Gitlab сделать отчет или воспользоваться другими инструментами).

Логирование: очень полезно будет иметь инструмент мониторинга и логирования. Например, Sentry. Это будет очень полезно когда продукт выйдет на пользователей и посыпятся непонятные ошибки.

Производительность: Тесты на скорость загрузки и отклика системы, особенно важны для фронтенда.

Совместимость с браузерами и устройствами: беглая проверка отображения и функционала на разных устройствах и в браузерах.

Доступность (Accessibility) и SEO: Убедиться, что продукт доступен для пользователей с ограниченными возможностями, сделать SEO проверки или проверить отчет

11. Итоговая таблица

Выводы

Спасибо всем, кто прочитал до конца! Надеюсь данный материал был вам полезен. Делитесь своими критериями проверки проектов!