Перейти к содержимому

Проверяемые критерии применения KISS, DRY, YAGNI, SOLID, тестирования и других базовых принципов разработки.

v1 0 звёзд 0 форков 0 наблюдателей 1 ветка 0 прогонов Публичный
Черновик — проверьте, доработайте и отметьте звездой, чтобы он стал эталоном.
miki(без описания)v1
1
Поведение соответствует требованиям

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

Зачем: Даже технически качественный код бесполезен, если решает неверную задачу.
Проверьте
  • Обязательные сценарии подтверждены
  • Ограничения и исключения учтены
  • Лишнее поведение не изменяет требования
2
Решение остаётся простым по принципу KISS

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

Зачем: Простое решение легче понимать, проверять, изменять и восстанавливать после сбоев.
Проверьте
  • Основной поток читается без лишних переходов
  • Абстракции решают существующую проблему
  • Нет неоправданных фреймворков и шаблонов
3
Знания не дублируются по принципу DRY

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

Зачем: DRY устраняет не просто похожий текст, а риск несогласованного изменения одного и того же знания.
Проверьте
  • Бизнес-правило определено в одном месте
  • Производные данные генерируются из источника истины
  • Копии конфигурации не расходятся
4
Случайное сходство не превращено в преждевременную абстракциюРекомендуется

Проверить, что объединённый код действительно меняется по одной причине; допустимое структурное повторение оставлено раздельным, если предметные правила независимы.

Зачем: Буквальное применение DRY часто связывает независимые части системы и делает изменения опаснее; иногда небольшое повторение дешевле неверной абстракции.
Проверьте
  • Объединённые случаи имеют общую семантику
  • Абстракция не переполнена флагами и исключениями
  • Независимые правила могут изменяться отдельно
5
Спекулятивная функциональность отсутствует по принципу YAGNI

Убедиться, что расширения, точки конфигурации и обобщения связаны с текущим требованием или подтверждённым ближайшим сценарием, а не с гипотетическим будущим.

Зачем: Неиспользуемая гибкость увеличивает объём кода, тестов и решений, которые придётся сопровождать.
Проверьте
  • У каждой возможности есть текущий потребитель
  • Неиспользуемые параметры и ветви отсутствуют
  • Будущие идеи не встроены без требования
6
Ответственности разделены и связность модулей высока

Проверить, что модуль объединяет поведение вокруг одной причины изменения, а бизнес-логика не смешана с вводом-выводом, хранением, интерфейсом или инфраструктурой.

Зачем: Высокая связность внутри модулей и разделение причин изменения локализуют доработки и ошибки.
Проверьте
  • У модуля сформулирована одна основная роль
  • Бизнес-правила отделены от инфраструктуры
  • Изменение требования затрагивает ограниченную область
7
Зависимости направлены к устойчивым контрактамРекомендуется

Проверить, что существенная бизнес-логика не зависит напрямую от нестабильных деталей, внешние интеграции изолированы, а интерфейсы вводятся в местах реальной заменяемости или тестового шва.

Зачем: Инверсия зависимостей снижает стоимость замены инфраструктуры, но интерфейс для каждого класса лишь создаёт лишнюю сложность.
Проверьте
  • Внешние системы изолированы адаптерами
  • Контракты минимальны и ориентированы на потребителя
  • Тривиальные детали не обёрнуты без причины
8
Контракты и ошибки выражены явно

Проверить, что входные условия, возвращаемые значения, состояния ошибок и побочные эффекты понятны из типов, интерфейсов, тестов или документации, а ошибки не подавляются молча.

Зачем: Явные контракты сокращают число скрытых предположений и позволяют обнаруживать нарушения ближе к источнику.
Проверьте
  • Недопустимые входы отклоняются предсказуемо
  • Ошибки сохраняют полезный контекст
  • Побочные эффекты видимы вызывающему коду
9
Критические сценарии и границы покрыты тестами

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

Зачем: Тесты подтверждают корректность и позволяют безопасно менять реализацию без закрепления её случайных деталей.
Проверьте
  • Основные сценарии покрыты
  • Граничные значения проверены
  • Ожидаемые отказы проверены
  • Тесты устойчивы к внутреннему рефакторингу
10
Автоматические проверки проходят воспроизводимо

Убедиться, что обязательный конвейер CI на актуальном коммите успешно выполняет тесты, статический анализ, форматирование, сборку и применимые проверки безопасности в чистом окружении.

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

Сверить названия, форматирование, организацию файлов и публичные интерфейсы с зафиксированным стандартом проекта; отклонения должны быть обоснованы.

Зачем: Единообразие снижает когнитивную нагрузку и позволяет сосредоточиться на поведении программы.
Проверьте
  • Имена отражают предметный смысл
  • Форматирование единообразно
  • Структура файлов предсказуема
  • Неочевидные сокращения отсутствуют
12
Документация объясняет актуальные решенияРекомендуется

Сопоставить документацию с текущими интерфейсами и поведением; комментарии должны объяснять причины, ограничения и компромиссы, а не пересказывать очевидный код.

Зачем: Документация особенно ценна там, где код не может сохранить контекст принятого решения.
Проверьте
  • Инструкции запуска актуальны
  • Публичные контракты описаны
  • Архитектурные компромиссы зафиксированы
  • Устаревшие комментарии отсутствуют
13
Границы доверия и привилегии ограничены

Проверить валидацию недоверенных данных, авторизацию операций, хранение секретов, безопасные значения по умолчанию и минимально необходимые права компонентов.

Зачем: Корректность программы включает устойчивость к ошибочному и злонамеренному вводу, а не только штатное поведение.
Проверьте
  • Недоверенные данные валидируются
  • Авторизация проверяется на серверной стороне
  • Секреты не находятся в коде и логах
  • Компоненты имеют минимальные права
14
Принципы применены как компромиссы, а не догмыРекомендуется

Проверить, что отступления от KISS, DRY, YAGNI или SOLID объясняются измеримыми требованиями, а применение одного принципа не создаёт больший риск для понятности, корректности или изменений.

Зачем: Принципы могут конфликтовать: хорошее решение учитывает контекст и стоимость изменения, а не максимизирует формальное соответствие лозунгам.
Проверьте
  • Компромиссы сформулированы явно
  • Сложность оправдана требованием
  • Решение можно пересмотреть при изменении условий

Один пункт — один человек, у каждого ссылка на первоисточник. Успехи, провалы и обратные повороты. Собрано для growth-hq 21.09.2026; выводы отдельным списком

обновлён 22 сент. 2026 г.