Как часто инициируешь изменения в проект?

Инициирование изменений в проект

Это баланс между инновацией и стабильностью. Расскажу о моём подходе:

1. Типы инициатив

Категория 1: Улучшение качества (часто)

• Рефакторинг легаси кода
• Добавление unit тестов
• Оптимизация slow queries
• Обновление dependencies

Категория 2: Bug fixes (всегда)

• Баги = это не инициатива, это обязательство

Категория 3: Новый функционал (редко, но стратегично)

• Новые features
• Архитектурные изменения
• Миграция на новый фреймворк

2. Частота инициатив

Реалистичный подход:

• Ежедневно: 1-2 small improvements (лучше назвать это ". Я замечаю проблему → быстро исправляю
• Еженедельно: 1-2 larger refactorings (обсуждаю с командой)
• Ежемесячно: 1 архитектурное решение (обсуждаю на team meeting)

3. Правило 80/20

Трачу время так:

• 80% времени: выполняю planned tasks (tickets)
• 20% времени: инициирую улучшения

Это правило работает, потому что:

• В 20% времени я фокусирую на самых болезненных проблемах
• В 80% я выполняю обязательства перед командой
• Баланс оптимален для долгосрочного здоровья проекта

4. Как я инициирую изменения (процесс)

Шаг 1: Выявление проблемы

Замечу:
  - Code smell (повторяющийся код)
  - Performance issue (slow endpoint)
  - Security risk (hardcoded credentials)
  - Technical debt (old dependency с critical bug)

Шаг 2: Анализ impact

Вопросы которые я задаю:
  - Сколько это ломает tests? (если много — priority high)
  - Сколько time потеряем на это? (30 мин vs 3 дня)
  - Сколько других блокируется? (это блокирует других?)
  - Какой risk? (это может сломать production?)

Шаг 3: Предложение

Не просто говорю: "Надо переписать Users Service"
Говорю: 
  "Users Service медленно отвечает (p99 = 1.5s), потому что N+1 query.
   Я хочу потратить 4 часа на оптимизацию (добавить eager loading).
   Это даст нам p99 = 200ms (7x улучшение).
   Можно ли это сделать на следующей неделе?"

Шаг 4: Code review идеи (перед реализацией)

Для крупных изменений:
  - Пишу RFC (Request For Comments) в конфе
  - Предлагаю решение, но открыт к альтернативам
  - Слушаю feedback от senior engineers
  - Итерирую на идее перед написанием кода

5. Примеры из практики

Инициатива 1: Добавить validation layer (успешно)

Замечу: в нескольких endpoints люди пропускают валидацию
Анализирую: это привело к 3 bugs в production
Предлагаю: создать shared validation middleware
Результат: +200 строк, -5 bugs, +15% code coverage

Оценка: small effort, high reward → делаю

Инициатива 2: Мигрировать на TypeScript (долго обсуждается)

Проблема: много JavaScript errors не поймались в CI
Вариант 1: Жёстче code review
Вариант 2: Мигрировать на TypeScript (2-3 недели работы)

Обсуждение с командой:
  - Pros: type safety, better IDE, more confidence
  - Cons: learning curve, slower initial development, tooling complexity
  
Веолутив с commandаром + team lead:
  - Может ли 1 человек мигрировать? Нет → нужна вся команда
  - Есть ли other priorities? Да → откладываем на следующий квартал
  
Решение: начинаем с новых файлов на TypeScript, постепенно мигрируем

Инициатива 3: Обновить Express на Fastify (отклонили)

Идея: Fastify быстрее Express
Анализ: +20% throughput, но breaking changes в 40+ endpoints
Оценка: risk high, reward small (у нас не bottleneck на Express)

Решение: не делаем. Правило: "Don't fix what's not broken"

6. Типичные mistake'ы, которых избегаю

Mistake 1: Overengineering

❌ "Давайте переделаем всю архитектуру на DDD + CQRS"
✅ "Давайте сначала измерим, что медленно, потом оптимизируем"

Mistake 2: Feature creep

❌ Во время рефакторинга добавляю new functionality
✅ Одна инициатива = одна цель (рефакторинг ИЛИ feature, не оба)

Mistake 3: Не слушаю feedback

❌ "Я знаю лучше, сейчас переделаю всё"
✅ "Я заметил проблему. Как вы обычно это решаете?"

Mistake 4: Инициирую слишком много

❌ Каждый день новый PR с refactoring
✅ 1-2 инициативы в неделю максимум

7. Метрики успеха

Я считаю инициативу успешной, если:

• Quantitative:

  • Тесты не упали (или покрытие выросло)
  • Performance улучшился или остался прежним
  • Code quality метрики улучшились

• Qualitative:

  • Команде проще работать с этой частью кода
  • Новый разработчик быстрее разбирается
  • Меньше bugs в этом модуле

8. Когда я НЕ инициирую изменения

• Если есть критичные bugs (focus на них)
• Если team на дедлайне (стабильность первичнее)
• Если я не 100% уверен, что это улучшение (нужны данные)
• Если это требует 3+ дней на один человека (обсуждаем с командой)
• Если есть dependency на других (даём им time to review)

9. Связь с product и team lead

Для инициатив я всегда:

• Информирую tech lead ("я хочу сделать...")
• Показываю данные ("это добавит X% к performance")
• Обещаю timeline ("4 часа, готово завтра")
• Включаю в приоритеты (не делаю parasite work)

10. Итоговый баланс

Я инициирую изменения:

• Часто, когда это small improvements (рефакторинг)
• Умеренно, когда это medium changes (new features)
• Редко, когда это large architectural changes (требует consensus)

Ключ: инициатива должна создавать value для проекта И быть acceptable для команды. Это не про "я знаю лучше", это про "давайте сделаем это вместе лучше".