В какой момент разработки проверяется, что код соответствует паттернам проектирования

Проверка соответствия паттернам проектирования

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

Этап 1: Планирование и дизайн

Задолго до написания кода нужно определить архитектуру:

• Обсуждение в команде — обсуждение выбранных паттернов, архитектурных решений
• Создание дизайн-документов — описание структуры, взаимодействия компонентов
• Выделение ответственностей — SOLID принципы

Этап 2: Разработка (во время написания кода)

Самопроверка разработчика:

• Следование архитектуре, которая согласована в команде
• Использование утвержденных паттернов (MVC, Repository, Observer и т.д.)
• Соответствие SOLID принципам
• Адекватная абстракция

// Проверяю: Single Responsibility?
// Контроллер только принимает запрос и возвращает ответ
class UserController {
  async getUser(req, res) {
    const user = await userService.findById(req.params.id);
    res.json(user);
  }
}

// Логика в сервисе, не в контроллере
class UserService {
  async findById(id) {
    return await userRepository.findById(id);
  }
}

Этап 3: Code Review (перед мержем)

Проверка другого разработчика на соответствие паттернам:

• Следует ли код выбранной архитектуре?
• Соответствует ли конвенциям проекта?
• Нет ли нарушений слоёв (например, presentation слой обращается прямо к БД)?
• Используются ли утвержденные паттерны?

// Code review замечание:
// Минус: контроллер прямо обращается к БД
class UserController {
  async getUser(req, res) {
    const user = await db.users.findOne({ id: req.params.id });
    res.json(user);
  }
}

// Плюс: использование repository pattern
class UserController {
  constructor(private userRepository) {}
  
  async getUser(req, res) {
    const user = await this.userRepository.findById(req.params.id);
    res.json(user);
  }
}

Этап 4: Статический анализ и линтинг

Автоматизированные инструменты помогают выявить проблемы:

npm run lint

Правила могут проверять:

• Структуру файлов
• Именование (camelCase, PascalCase)
• Импорты (нет циклических зависимостей)
• Неиспользуемые переменные
• Сложность функций

Этап 5: Архитектурные тесты

Есть инструменты для проверки архитектурных правил:

// Пример: проверка слоёв
// Контроллеры не должны зависеть от infrastructure
Test('Architecture rules')
  .layer('presentation')
  .not.dependsOn('infrastructure')
  .check();

Этап 6: Интеграционные и E2E тесты

Тесты проверяют, что паттерны работают правильно:

// Тест: проверяем, что сервис кэширует результат
test('UserService caches results', async () => {
  const mockDb = jest.spyOn(repository, 'query');
  
  const user1 = await userService.getUser(1);
  const user2 = await userService.getUser(1);
  
  expect(mockDb).toHaveBeenCalledTimes(1);
});

Практический процесс в команде

1. Pre-commit hook — локальная проверка (ESLint, типы)
2. Pull Request — review код на паттерны + запуск тестов
3. CI/CD — автоматические проверки (lint, тесты, анализ)
4. Ретроспективы — обсуждение архитектурных проблем
5. Документация — обновление Architecture Decision Records (ADR)

Вывод

Проверка соответствия паттернам — это непрерывный процесс, а не один момент:

• Начинается с планирования архитектуры
• Проверяется во время code review
• Поддерживается статическим анализом и тестами
• Обсуждается в ретроспективах и архитектурных встречах

Это ответственность всей команды, а не одного человека.