🧙 Садовник: уточнил шаги, добавил проверки и обоснования. Примите, если полезно.
#1Сверить реализованные сценарии, ограничения и результаты с согласованными критериями приёмки; для каждого обязательного требования должно существовать подтверждение в тесте или демонстрации.
- –Обязательные сценарии подтверждены
- –Ограничения и исключения учтены
- –Лишнее поведение не изменяет требования
- –Каждый кейс приёмки имеет соответствующий тест
Проверить на ревью, что основной путь выполнения легко прослеживается, уровни абстракции оправданы, а более простая реализация не обеспечивает те же требования.
- –Основной поток читается без лишних переходов
- –Абстракции решают существующую проблему
- –Нет неоправданных фреймворков и шаблонов
- –Количество зависимостей минимально
Найти бизнес-правила, формулы, схемы и конфигурацию, представленные в нескольких местах, и убедиться, что у каждого знания есть единый источник истины.
- –Бизнес-правило определено в одном месте
- –Производные данные генерируются из источника истины
- –Копии конфигурации не расходятся
- –Нет дублирования логики в разных модулях
Проверить, что объединённый код действительно меняется по одной причине; допустимое структурное повторение оставлено раздельным, если предметные правила независимы.
- –Объединённые случаи имеют общую семантику
- –Абстракция не переполнена флагами и исключениями
- –Независимые правила могут изменяться отдельно
- –Абстракции не усложняют понимание кода
Убедиться, что расширения, точки конфигурации и обобщения связаны с текущим требованием или подтверждённым ближайшим сценарием, а не с гипотетическим будущим.
- –У каждой возможности есть текущий потребитель
- –Неиспользуемые параметры и ветви отсутствуют
- –Будущие идеи не встроены без требования
- –Нет избыточных интерфейсов и методов
Проверить, что модуль объединяет поведение вокруг одной причины изменения, а бизнес-логика не смешана с вводом-выводом, хранением, интерфейсом или инфраструктурой.
- –У модуля сформулирована одна основная роль
- –Бизнес-правила отделены от инфраструктуры
- –Изменение требования затрагивает ограниченную область
- –Модули не зависят от деталей реализации друг друга
Проверить, что существенная бизнес-логика не зависит напрямую от нестабильных деталей, внешние интеграции изолированы, а интерфейсы вводятся в местах реальной заменяемости или тестового шва.
- –Внешние системы изолированы адаптерами
- –Контракты минимальны и ориентированы на потребителя
- –Тривиальные детали не обёрнуты без причины
- –Используются интерфейсы, а не конкретные реализации
Проверить, что входные условия, возвращаемые значения, состояния ошибок и побочные эффекты понятны из типов, интерфейсов, тестов или документации, а ошибки не подавляются молча.
- –Недопустимые входы отклоняются предсказуемо
- –Ошибки сохраняют полезный контекст
- –Побочные эффекты видимы вызывающему коду
- –Типы данных чётко определяют допустимые значения
Сопоставить тесты с критериями приёмки и проверить наличие успешных, граничных и ошибочных сценариев; тесты должны проверять наблюдаемое поведение, а не внутреннее устройство.
- –Основные сценарии покрыты
- –Граничные значения проверены
- –Ожидаемые отказы проверены
- –Тесты устойчивы к внутреннему рефакторингу
- –Есть тесты для критических путей
Убедиться, что обязательный конвейер CI на актуальном коммите успешно выполняет тесты, статический анализ, форматирование, сборку и применимые проверки безопасности в чистом окружении.
- –Обязательный конвейер завершён успешно
- –Проверки запускаются в чистом окружении
- –Случайно нестабильные тесты отсутствуют
- –Защита ветки требует успешных проверок
- –Все зависимости загружаются автоматически
Сверить названия, форматирование, организацию файлов и публичные интерфейсы с зафиксированным стандартом проекта; отклонения должны быть обоснованы.
- –Имена отражают предметный смысл
- –Форматирование единообразно
- –Структура файлов предсказуема
- –Неочевидные сокращения отсутствуют
- –Используются общепринятые названия для стандартных компонентов
Сопоставить документацию с текущими интерфейсами и поведением; комментарии должны объяснять причины, ограничения и компромиссы, а не пересказывать очевидный код.
- –Инструкции запуска актуальны
- –Публичные контракты описаны
- –Архитектурные компромиссы зафиксированы
- –Устаревшие комментарии отсутствуют
- –Документация синхронизирована с изменениями кода
Проверить валидацию недоверенных данных, авторизацию операций, хранение секретов, безопасные значения по умолчанию и минимально необходимые права компонентов.
- –Недоверенные данные валидируются
- –Авторизация проверяется на серверной стороне
- –Секреты не находятся в коде и логах
- –Компоненты имеют минимальные права
- –Используются механизмы защиты от инъекций
Проверить, что отступления от KISS, DRY, YAGNI или SOLID объясняются измеримыми требованиями, а применение одного принципа не создаёт больший риск для понятности, корректности или изменений.
- –Компромиссы сформулированы явно
- –Сложность оправдана требованием
- –Решение можно пересмотреть при изменении условий
- –Есть обоснование для отклонений от принципов
Проверить, что в логах нет чувствительных данных, таких как пароли, токены, персональные данные пользователей.
- –Конфиденциальные данные не записываются в логи
- –Используются механизмы маскировки чувствительных данных
- –Логи не содержат информации, которая может быть использована для атаки на систему
Проверить, что при обработке исключений программа не теряет критически важные данные и не переходит в некорректное состояние.
- –Исключения не подавляются без обработки
- –При обработке исключений сохраняется целостность данных
- –Программа корректно восстанавливается после обработки исключения