Как поддерживаешь нормы в проекте?

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

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

1. Автоматизация через инструменты

ESLint — проверка стиля и логических ошибок

// .eslintrc.json
{
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:@typescript-eslint/recommended",
    "prettier" // Отключить конфликты с prettier
  ],
  "rules": {
    "no-console": "warn",
    "no-unused-vars": "error",
    "react/jsx-uses-react": "off", // React 17+
    "@typescript-eslint/explicit-module-boundary-types": "error",
    "@typescript-eslint/no-explicit-any": "error",
    "no-var": "error", // Только const/let
    "prefer-const": "error",
    "eqeqeq": ["error", "always"] // === вместо ==
  }
}

# package.json скрипты
npm run lint         # Проверка
npm run lint:fix     # Автоматическое исправление

Prettier — форматирование кода

// .prettierrc
{
  "semi": true,
  "singleQuote": true,
  "trailingComma": "es5",
  "tabWidth": 2,
  "printWidth": 100,
  "arrowParens": "always"
}

TypeScript — проверка типов

// tsconfig.json
{
  "compilerOptions": {
    "strict": true, // Все проверки включены
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true
  }
}

2. Pre-commit хуки

husky + lint-staged для проверки перед коммитом

# Установка
npm install husky lint-staged --save-dev
npx husky install

// package.json
{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.{css,scss}": [
      "stylelint --fix",
      "prettier --write"
    ]
  }
}

# .husky/pre-commit
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged

Это предотвращает коммит код с ошибками.

Дополнительная проверка перед пушем

# .husky/pre-push
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

echo "Running tests..."
npm test:run -- --coverage

if [ $? -ne 0 ]; then
  echo "Tests failed. Cannot push."
  exit 1
fi

3. CI/CD Pipeline

GitHub Actions для автоматизации проверок

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main, develop]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: '18'
      - run: npm ci
      - run: npm run lint
      - run: npm run type-check
  
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
      - run: npm ci
      - run: npm run test:run -- --coverage
      - uses: codecov/codecov-action@v2
        with:
          files: ./coverage/lcov.info
  
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
      - run: npm ci
      - run: npm run build

Это гарантирует, что все PR проходят проверки перед слиянием.

4. Code Review процесс

Правила для PR

# PULL REQUEST TEMPLATE

## Description
Опишите изменения

## Type of change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change

## Checklist
- [ ] Lint passed (`npm run lint`)
- [ ] Tests pass (`npm test`)
- [ ] Coverage >= 90%
- [ ] No console.logs
- [ ] TypeScript strict mode (no any)
- [ ] Responsive design tested
- [ ] Accessibility tested

Требования к слиянию

# .github/settings.yml
repos:
  - name: prepbro
    branch_protection_rules:
      - pattern: main
        required_approvals: 2
        required_checks:
          - lint
          - test
          - build
        dismiss_stale_reviews: true
        require_code_owner_reviews: true

5. Документирование и стандарты

Code Style Guide

# frontend/STYLE_GUIDE.md

## Именование
- Компоненты: PascalCase (UserProfile)
- Функции: camelCase (getUserData)
- Константы: UPPER_SNAKE_CASE (MAX_RETRIES)
- Файлы компонентов: PascalCase (UserProfile.tsx)

## Структура проекта

frontend/ ├── components/ │ ├── ui/ (Button, Input) │ ├── layout/ (Header, Footer) │ └── features/ (UserProfile, Questions) ├── hooks/ ├── contexts/ ├── lib/ ├── types/ └── tests/

## Props и типы
- Всегда типизируй props интерфейсом
- Избегай any
- Используй type guards для union types

6. Регулярный аудит

Проверка зависимостей

# npm audit для уязвимостей
npm audit

# npm outdated для устаревших пакетов
npm outdated

# Обновление зависимостей
npm update

Анализ метрик кода

# Количество строк кода
cloc frontend/src

# Сложность циклома
eslint-plugin-complexity

7. Культура команды

Обучение и стандартизация

1. Регулярные code review сессии — обсуждение best practices
2. Раздача задач по паттернам — учиться у опытных разработчиков
3. Wiki с примерами — хранилище решений и паттернов
4. Pair programming — совместная разработка сложных фич
5. Retrospectives — анализ ошибок и улучшений

Пример конкретного стандарта

// ✅ Хороший компонент
interface ButtonProps {
  variant?: 'primary' | 'secondary';
  size?: 'small' | 'medium' | 'large';
  disabled?: boolean;
  onClick: (e: React.MouseEvent<HTMLButtonElement>) => void;
  children: React.ReactNode;
}

export function Button({
  variant = 'primary',
  size = 'medium',
  disabled = false,
  onClick,
  children,
}: ButtonProps) {
  return (
    <button
      className={cn('btn', `btn-${variant}`, `btn-${size}`)}
      disabled={disabled}
      onClick={onClick}
    >
      {children}
    </button>
  );
}

// ❌ Плохой компонент
function Button(props: any) {
  return <button {...props}>{props.children}</button>;
}

8. Мониторинг в production

Error tracking (Sentry)

import * as Sentry from '@sentry/react';

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  environment: process.env.NODE_ENV,
  tracesSampleRate: 1.0,
});

// Автоматически ловит ошибки

Analytics для метрик

// Отслеживание Core Web Vitals
import { getCLS, getFID, getFCP, getLCP } from 'web-vitals';

getLCP(metric => analytics.track('LCP', metric));
getCLS(metric => analytics.track('CLS', metric));

Реальный пример процесса

1. Разработчик пишет код
   ↓
2. git commit → husky запускает lint-staged
   ↓
3. git push → husky запускает тесты
   ↓
4. GitHub PR → CI запускает lint, test, build
   ↓
5. Code review (минимум 2 одобрения)
   ↓
6. Merge → деплой на staging
   ↓
7. Production deployment с мониторингом (Sentry)

Чеклист поддержания норм

1. ESLint + Prettier настроены
2. TypeScript strict mode включен
3. Pre-commit hooks установлены
4. CI/CD pipeline настроен
5. Code review процесс документирован
6. Test coverage >= 90%
7. Стиль гайд написан и доступен
8. Регулярный аудит зависимостей
9. Мониторинг ошибок в production
10. Культура качества в команде

Вывод

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