⭐ Лучшие Практики

Мудрость мастеров индустрии для ежедневной работы

"Мастерство — это не пункт назначения, а путь. Практикуй каждый день." — Древняя мудрость джедаев

SOLID Принципы

S Single Responsibility Principle

Принцип Единственной Ответственности

У класса должна быть только одна причина для изменения. Один класс — одна ответственность.

// ❌ Плохо
class User {
    saveToDatabase() { }
    sendEmail() { }
    generateReport() { }
}

// ✅ Хорошо
class User { }
class UserRepository { saveToDatabase() { } }
class EmailService { sendEmail() { } }
class ReportGenerator { generate() { } }

O Open/Closed Principle

Принцип Открытости/Закрытости

Классы должны быть открыты для расширения, но закрыты для модификации.

// ✅ Хорошо - используем полиморфизм
class Shape {
    area() { throw new Error('Must implement') }
}

class Circle extends Shape {
    constructor(radius) {
        super();
        this.radius = radius;
    }
    area() { return Math.PI * this.radius ** 2; }
}

class Rectangle extends Shape {
    constructor(width, height) {
        super();
        this.width = width;
        this.height = height;
    }
    area() { return this.width * this.height; }
}

L Liskov Substitution Principle

Принцип Подстановки Барбары Лисков

Объекты подклассов должны быть взаимозаменяемы с объектами базового класса.

// ✅ Правильное наследование
class Bird {
    move() { console.log('Движение'); }
}

class FlyingBird extends Bird {
    move() { console.log('Полёт'); }
}

class Penguin extends Bird {
    move() { console.log('Ходьба'); }
}

I Interface Segregation Principle

Принцип Разделения Интерфейса

Клиенты не должны зависеть от интерфейсов, которые они не используют.

// ✅ Разделённые интерфейсы
class Printer {
    print(document) { }
}

class Scanner {
    scan(document) { }
}

class SimplePrinter extends Printer { }

class MultiFunctionDevice extends Printer {
    constructor() {
        super();
        this.scanner = new Scanner();
    }
}

D Dependency Inversion Principle

Принцип Инверсии Зависимостей

Зависимости должны строиться на абстракциях, а не на конкретных реализациях.

// ✅ Зависимость от абстракции
class JediService {
    constructor(database) {
        this.database = database; // Любая БД
    }
    
    save(jedi) {
        this.database.save(jedi);
    }
}

// Можем использовать любую реализацию
const service1 = new JediService(new MongoDB());
const service2 = new JediService(new PostgreSQL());

Принципы Разработки

🎯 KISS - Keep It Simple, Stupid

Простота — высшая форма изощрённости. Не усложняй без необходимости.

  • Пиши простой и понятный код
  • Избегай преждевременной оптимизации
  • Выбирай простейшее решение, которое работает

🔄 DRY - Don't Repeat Yourself

Каждая часть знания должна иметь единственное представление в системе.

  • Избегай дублирования кода
  • Выноси повторяющуюся логику в функции
  • Используй константы для повторяющихся значений

⚖️ YAGNI - You Aren't Gonna Need It

Не добавляй функциональность, пока она действительно не понадобится.

  • Реши сегодняшнюю проблему, а не завтрашнюю
  • Не пиши код "на будущее"
  • Добавляй функции по мере необходимости

🚀 Principle of Least Surprise

Код должен вести себя ожидаемым образом.

  • Называй функции согласно их действиям
  • Следуй общепринятым соглашениям
  • Избегай неочевидного поведения

🔐 Fail Fast

Обнаруживай ошибки как можно раньше.

  • Валидируй входные данные сразу
  • Выбрасывай исключения при некорректных состояниях
  • Не скрывай ошибки

📦 Encapsulation

Скрывай внутреннее устройство, предоставляй интерфейс.

  • Делай поля приватными
  • Предоставляй публичные методы для доступа
  • Защищай инварианты класса

🎨 Composition Over Inheritance

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

  • Наследование создаёт жёсткую связь
  • Композиция более гибкая
  • Используй наследование только для "is-a" отношений

⚡ Premature Optimization is the Root of All Evil

Сначала сделай работающий код, потом оптимизируй узкие места.

  • Оптимизируй только после измерения
  • Читаемость важнее скорости
  • Профилируй перед оптимизацией

Git Best Practices

📝 Осмысленные Коммиты

# ❌ Плохо
git commit -m "fix"
git commit -m "updates"
git commit -m "asdfsdf"

# ✅ Хорошо
git commit -m "feat: add user authentication"
git commit -m "fix: resolve null pointer in JediService"
git commit -m "refactor: extract method calculatePower"

Используй конвенцию: type: description

Типы: feat, fix, docs, style, refactor, test, chore

🌿 Работа с Ветками

  • main/master - стабильная ветка, только рабочий код
  • develop - ветка разработки
  • feature/название-фичи - новая функциональность
  • bugfix/описание-бага - исправление бага
  • hotfix/критичный-баг - срочное исправление

🔄 Pull Request Guidelines

  • Пиши понятное описание изменений
  • Добавляй скриншоты для UI изменений
  • Ссылайся на issue/ticket
  • Держи PR небольшим (до 300-400 строк)
  • Проверяй свой код перед созданием PR
  • Отвечай на комментарии ревьюеров

🚫 Что НЕ коммитить

  • Пароли и секретные ключи
  • node_modules, vendor, build папки
  • Личные настройки IDE
  • Логи и временные файлы
  • Большие бинарные файлы
  • Закомментированный код

Code Review Практики

👨‍💻 Для Автора Кода

  • Проверь код сам перед отправкой на ревью
  • Пиши самодокументируемый код
  • Добавляй комментарии к сложным участкам
  • Убедись, что тесты проходят
  • Держи PR фокусированным на одной задаче
  • Не принимай критику на личный счёт
  • Отвечай на комментарии быстро

👁️ Для Ревьюера

  • Будь вежливым и конструктивным
  • Хвали хороший код, не только критикуй
  • Объясняй "почему", а не только "что"
  • Предлагай решения, а не только проблемы
  • Проверяй логику, а не только стиль
  • Отделяй критичные замечания от предложений
  • Проводи ревью в разумные сроки

✅ Чеклист Код Ревью

Код решает поставленную задачу?
Код легко читается и понимается?
Нет дублирования кода?
Имена переменных и функций понятны?
Есть обработка ошибок?
Добавлены тесты?
Нет хардкода (магических чисел)?
Код следует стандартам проекта?
Нет потенциальных уязвимостей?
Производительность приемлема?

Ежедневные Практики Джедая-Разработчика

🌅 Утро

  • Проверь новые PR и комментарии
  • Распланируй задачи на день
  • Прочитай документацию или статью (15 мин)
  • Синхронизируйся с командой

☀️ День

  • Пиши тесты до или сразу после кода
  • Коммить маленькими порциями
  • Делай код ревью коллегам
  • Рефактори код по правилу бойскаута
  • Делай перерывы каждый час

🌙 Вечер

  • Запуши весь рабочий код
  • Обнови задачи в трекере
  • Подготовь задачи на завтра
  • Изучи что-то новое (30 мин)
  • Отдохни от кода

🎓 Путь к Мастерству

📚 Учись Постоянно

  • Читай книги по программированию
  • Изучай код опенсорс проектов
  • Смотри доклады с конференций
  • Решай задачи на LeetCode, Codewars
  • Пробуй новые технологии

🤝 Делись Знаниями

  • Веди технический блог
  • Выступай на митапах
  • Помогай джуниорам
  • Участвуй в опенсорсе
  • Проводи внутренние митапы

💪 Практикуйся

  • Пиши пет-проекты
  • Рефактори старый код
  • Изучай новые паттерны
  • Экспериментируй с алгоритмами
  • Пиши чистый код каждый день

🧘 Баланс

  • Не выгорай — отдыхай
  • Занимайся спортом
  • Общайся вне IT
  • Имей хобби
  • Высыпайся

⭐ Кодекс Джедая-Программиста

Эмоций нет — есть спокойствие

Не паникуй при багах, методично ищи решение

Невежества нет — есть знание

Постоянно учись новому, читай документацию

Страстей нет — есть безмятежность

Пиши сбалансированный код, не увлекайся оверинжинирингом

Хаоса нет — есть гармония

Следуй стандартам, пиши чистый и понятный код

Смерти нет — есть Сила

Твой код переживёт тебя, делай его достойным