Какие кодовые конвенции и механизмы контроля архитектурных границ можно использовать в команде: линтеры, кастомные правила, проверки в CI/CD?

Кодовые конвенции — это договорённости команды о том, как писать код: отступы, именование, порядок импортов, запрет на определённые конструкции. Архитектурные границы — более высокий уровень: правила о том, какие слои и модули могут зависеть друг от друга, например, что UI не должен импортировать инфраструктурный код напрямую. Без автоматизации эти правила быстро нарушаются, поэтому их закрепляют инструментами.

Уровни контроля

• Локально: pre-commit хуки (husky, lint-staged) запускают линтер и форматтер перед коммитом.
• В CI/CD: отдельный шаг pipeline выполняет линт, проверку зависимостей и падает при нарушении.
• В IDE: плагины подсвечивают ошибки сразу, ускоряя обратную связь.

Инструменты

Для стиля используют ESLint, Prettier, Black, Ruff, Checkstyle. Для архитектурных границ — eslint-plugin-boundaries, dependency-cruiser, ArchUnit (Java), import-linter (Python), Nx module boundaries. Кастомные правила пишут, когда готовых плагинов не хватает под специфику проекта.

Пример правила границ

// .dependency-cruiser.js
module.exports = {
  forbidden: [
    {
      name: 'no-ui-to-infra',
      from: { path: '^src/ui' },
      to: { path: '^src/infrastructure' },
      severity: 'error'
    }
  ]
};

Пример шага CI

# .github/workflows/ci.yml
- name: Lint
  run: npm run lint
- name: Check boundaries
  run: npx depcruise --validate .dependency-cruiser.js src

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

Итог: такой подход стоит применять в любой команде от 2-3 человек, где важны предсказуемость кода и устойчивость архитектуры — автоматические проверки экономят время на ревью и предотвращают деградацию структуры проекта.