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

Правила разработки

Порядок для каркаса​

  1. Сначала зафиксируйте границу сервиса и его ответственность.
  2. Напишите тест на техническое поведение.
  3. Добавьте минимальный код для прохождения теста.
  4. Упростите код без изменения поведения.
  5. Обновите README, AGENTS.md и docs/.

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

Простые имена​

Имена классов и функций пишутся на английском, но из знакомых слов. Примеры:

  • ActionController, а не ActionCommandIngressAdapter;
  • ActionService, а не ActionExecutionOrchestrationFacade;
  • ActionRepository, а не ActionPersistencePort;
  • createAction(), findAction(), saveAction().

Если имя становится длинным, сначала проверьте, не делает ли класс слишком много.

Структура Java MVC​

controller -> service -> repository -> jOOQ -> PostgreSQL

DTO остаются в dto, обычные модели — в model, конфигурация — в config. JPA и Hibernate не используются.

Структура Python​

controller -> service -> repository -> внешний API

HTTP-схемы остаются в schemas, обычные модели — в models, настройки — в config.

Ревью​

CODEOWNERS назначает нужные команды. CI проверяет тесты, стиль, типы, документацию и сборку. AI-агент может помочь с ревью, но решение о принятии изменения остаётся за человеком-владельцем.