Архитектура
- Вопрос: Чётко ли выделены слои/модули (UI, бизнес-логика, доступ к данным, конфигурация)?
Критерий: каждый слой инкапсулирует ответственность, зависимости идут «вниз» по слоям; интерфейсы ясны и небольшие.
- Вопрос: Соответствует ли дизайн принципам SRP, DRY, KISS?
Критерий: классы/модули имеют узкую ответственность; повторный код вынесен; отсутствуют чрезмерные оптимизации/усложнения.
- Вопрос: Есть ли явные точки расширения и слабые места (tight coupling)?
Критерий: зависимости инвертированы через интерфейсы/DI; модули можно тестировать изолированно.
- Вопрос: Как устроена работа с конфигурацией и средами (dev/staging/prod)?
Критерий: конфигурация отделена от кода, нет секретов в репозитории; поддерживается переключение сред через переменные/файлы.
- Вопрос: Как организовано хранение данных и миграции?
Критерий: схема/модели документированы; есть миграции и стратегия отката; транзакции используются там, где нужно.
- Вопрос: Как проект масштабируется и как он обрабатывает ошибки/отказоустойчивость?
Критерий: дизайн допускает горизонтальное масштабирование; ошибки логируются и имеют понятные уровни; есть обработчики исключений/фолбеков.
- Вопрос: Есть ли контракт API и документация (например OpenAPI/README)?
Критерий: API документирован, примеры запросов/ответов, формат ошибок описан.
Стиль и качество кода
- Вопрос: Соблюдается ли единый стиль кода и правила форматирования?
Критерий: проект использует линтер/форматтер (например ESLint, Prettier, Black) и конфигурация в репозитории.
- Вопрос: Насколько читаемы имена, комментарии и структура файлов?
Критерий: имена выразительны; комментарии объясняют «почему», не «что»; файлы не чрезмерно большие.
- Вопрос: Есть ли явные антипаттерны (дублирование, большие функции, магические числа)?
Критерий: минимальное дублирование; функции маленькие и с одной ответственностью; магические числа вынесены в константы.
- Вопрос: Как измеряется сложность кода?
Критерий: цикломатическая сложность на функцию/метод приемлема (при желании — порог в CI).
- Вопрос: Есть ли автоматические проверки в CI (lint, static analysis)?
Критерий: линтинг/статический анализ запускаются в CI и блокируют PR при критических ошибках.
Тесты
- Вопрос: Какова структура тестов (unit/integration/e2e)?
Критерий: тесты делятся по типам; unit-тесты — быстрые и изолированные; интеграционные покрывают ключевые сценарии.
- Вопрос: Есть ли автоматический запуск тестов в CI?
Критерий: все тесты запускаются в CI на PR; фэйлы блокируют мердж.
- Вопрос: Тесты детерминированы и независимы?
Критерий: отсутствие зависимостей между тестами; чистые тестовые данные; тесты не зависят от внешних сервисов без мока/стаба.
- Вопрос: Покрывают ли тесты ключевые сценарии и пограничные случаи?
Критерий: присутствуют тесты для основных флоу, ошибок, валидации и крайних значений.
- Вопрос: Какова метрика покрытия?
Критерий: покрытие кода адекватно проекту; рекомендуемое целевое значение — $\ge 80\%$ для критичных модулей (в студенческом проекте гибче).
- Вопрос: Насколько тесты понятны и поддерживаемы?
Критерий: тесты читаемы, используют фикстуры и фабрики, не содержат «магии».
Безопасность
- Вопрос: Как проект обрабатывает аутентификацию и авторизацию?
Критерий: используется проверенная схема (JWT/сессии) корректно; права проверяются на уровне ресурсов, не только UI.
- Вопрос: Проводится ли валидация и санитизация входных данных?
Критерий: все вводимые данные валидируются на сервере; используются библиотечные средства для предотвращения инъекций.
- Вопрос: Защищены ли от SQL-инъекций, XSS, CSRF и др.?
Критерий: параметризованные запросы/ORM, экранирование вывода, CSRF-токены/заголовки реализованы там, где нужно.
- Вопрос: Как обрабатываются секреты и зависимости?
Критерий: ключи/пароли не в коде; используются env-переменные/секрет-менеджеры; зависимости обновлены, уязвимости проверены (snyk/Dependabot).
- Вопрос: Шифруются ли чувствительные данные в покое и при передаче?
Критерий: TLS для передачи; конфиденциальные данные хранятся шифрованными при необходимости; пароли хэшируются безопасным алгоритмом (bcrypt/argon2).
- Вопрос: Логирование и мониторинг — не сливаются ли секреты?
Критерий: логи не содержат паролей/токенов; есть уровни логирования и возможность отключить детальный лог в проде.
- Вопрос: Есть ли механизмы ограничения частоты и защиты от брутфорса?
Критерий: rate limiting, блокировка попыток входа, капча на критичных эндпойнтах (по необходимости).
- Вопрос: Проведён ли анализ уязвимостей (SAST/DAST) или ручной обзор критичных участков?
Критерий: хотя бы базовый SAST/сканирование зависимостей и ручной обзор секурных точек.
Практические проверки (что смотреть прямо в PR/репозитории)
- Наличие README с инструкцией запуска, зависимостями и тестами.
- Настроенный CI (lint, тесты, сборка).
- Файлы конфигурации для линтера, тестов и миграций в репозитории.
- Отсутствие секретов в коммитах (проверить git history).
- Примеры requests/responses для API (Postman/Swagger).
- Список известных ограничений и TODO (прозрачность техзадания).
Короткие критерии «пройти/не пройти»
- Архитектура: модули разделены, зависимости контролируемы, есть документация по запуску.
- Стиль: линтер в CI, код читаем, нет очевидного дублирования/магии.
- Тесты: тесты запускаются в CI, покрывают ключевые сценарии, детерминированы.
- Безопасность: нет паролей в репо, базовые уязвимости закрыты, аутентификация/валидация реализованы.
Если нужно, могу сжать этот список до чек-листа для быстрого прохождения PR или подготовить шаблон вопросов для интервью/оценки.