Что не хотел бы видеть в новой команде?

Что я не хотел бы видеть в новой команде?

Как опытный разработчик, я считаю, что здоровье команды и качество процессов напрямую влияют на результат. Вот ключевые антипаттерны, которые я стремился бы избегать или помогать исправлять.

1. Токсичная культура и отсутствие психологической безопасности

• Блейм-культура и поиск виноватых. Когда ошибки скрывают из-за страха, вместо того чтобы открыто разбирать их как возможность для роста.
• Неконструктивная критика. Комментарии в духе «это плохой код» без объяснения причин и предложений по улучшению.
• Замкнутость информации и «культ героев». Ситуация, где только один человек понимает критическую часть системы, а знания не документируются и не передаются.

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

2. Хроническое пренебрежение качеством кода

Это не просто о «красивых» именах переменных. Речь о фундаментальных практиках:

• Отсутствие код-ревью как формальности. Когда пулл-реквесты мержится без вдумчивого анализа, лишь бы «поставить галочку».
• Технический долг как норма. Постоянное «сделаем пока так, потом перепишем» (это «потом» никогда не наступает).
• Полное отсутствие или нефункциональные тесты. Любые изменения тогда становятся игрой в русскую рулетку.

// Пример "плохого кода", который часто пропускают в спешке:
// Непонятные имена, хардкод, смесь логики и представления.
function update(a, b) {
  let d = a * 1.2; // Что такое 1.2? Налог? Наценка?
  let x = b.filter(i => i.s === 'Y'); // Что такое 'Y'?
  document.getElementById('res').innerHTML = `<div>${d}</div>`; // Прямой манипуляции DOM в бизнес-логике
  return x;
}

3. Неэффективные и демотивирующие процессы

• Микроменеджмент. Ежедневные часовые стендапы с подробным отчетом по каждой задаче, лишающие разработчика автономности.
• Бесконечные и прерывающие встречи. Невозможность выделить 2-3 часа на глубокую сфокусированную работу.
• Жесткая привязанность к инструментам и методологиям. Когда Scrum или Jira становятся самоцелью, а не средством помощи команде. Отсутствие ретроспектив и гибкости в адаптации процессов.

4. Стихийное или отсутствующее планирование архитектуры

• Принятие ключевых решений «на лету» в чате. Без обсуждения альтернатив, записи решений (ADR — Architecture Decision Record) и оценки долгосрочных последствий.
• Отсутствие единого видения. Когда каждый разработчик пишет в своем стиле, использует разные подходы к состоянию (Redux, Context, MobX) или структуре проекта, что превращает кодбазу в «лоскутное одеяло».

5. Изоляция фронтенда от бизнеса и других команд

• «Бросок требований через забор». Когда бэкенд- и UX-команды работают без ранней синхронизации с фронтендом, что приводит к нереализуемым дизайнам или неоптимальным API.
• Фронтенд как «верстальщики». Отсутствие вовлечения фронтенд-разработчиков в обсуждение логики продукта, проектирование API и пользовательских сценариев.

6. Стагнация и отсутствие развития

• Страх перед новыми технологиями. Установка «у нас всегда так делали» как главный аргумент против обновления стека, внедрения TypeScript или современных инструментов сборки.
• Невозможность экспериментировать. Отсутствие времени или бюджета на изучение, proof of concept, участие в конференциях или внутренние воркшопы.

Вместо заключения: Я стремлюсь в команду, где ценят прозрачность, взаимное уважение и совместную ответственность за продукт. Где качество — это не просто слово, а набор конкретных практик (автоматизированные тесты, CI/CD, код-ревью). Где процессы созданы, чтобы помогать, а не мешать. Где есть здоровый баланс между решением текущих задач и инвестициями в будущее — будь то борьба с техдолгом или обучение. Такой подход не только делает работу продуктивнее, но и приносит настоящее профессиональное удовлетворение.