С чем не хотел бы сталкиваться на новой работе

Мой взгляд на нежелательные аспекты работы в frontend-разработке

Как опытный фронтенд-разработчик, за годы работы я сформировал чёткое представление о профессиональной среде, которая позволяет мне быть максимально продуктивным и создавать качественные продукты. Есть несколько аспектов, с которыми я принципиально не хотел бы сталкиваться на новой позиции.

1. Устаревшие технологические стеки и процессы

• Легаси-код без стратегии модернизации: Работа с устаревшими библиотеками (например, jQuery без плана перехода) или фреймворками (AngularJS 1.x, Backbone) без чёткой дорожной карты по обновлению. Это тормозит развитие продукта и навыков команды.

  // Пример условного "легаси", который трудно поддерживать
  $(document).ready(function() {
      // 1000+ строк jQuery, перемешанных с логикой и вёрсткой
      $('#btn').click(function() {
          $.ajax({
              url: '/data',
              success: function(data) {
                  // Манипуляции с DOM напрямую
                  $('#list').append('<li>' + data.name + '</li>');
              }
          });
      });
  });
  

• Отсутствие современного инструментария: Работа без систем контроля версий (Git — must have), CI/CD, линтеров (ESLint), форматтеров (Prettier), модульных тестов (Jest, Vitest). Это напрямую влияет на качество кода и скорость разработки.

2. Токсичная культура и неэффективная коммуникация

• Культура обвинений (Blame Culture): Среда, где ошибки скрывают, а не разбирают для извлечения уроков. Это убивает психологическую безопасность и инновации.
• Микроменеджмент: Отсутствие доверия к экспертизе разработчика, постоянный детальный контроль каждого шага. Я ценю автономию в рамках поставленных задач и clear expectations.
• "Hero Culture": Ситуации, где поощряется работа по ночам и выходным для "спасения проекта". Это признак плохого планирования и ведёт к выгоранию.

3. Неструктурированные или хаотичные процессы

• Отсутствие понятного workflow: Нет чётких процессов для code review, дизайн-ревью, тестирования, деплоя. Всё решается "по ситуации", что приводит к хаосу.
• Постоянные срочные правки в обход процессов: Практика, когда менеджмент или продакт-менеджер напрямую просит "быстро сделать фикс" в обход тикета, тестирования и code review. Это ломает процесс и качество.
• Неясные требования и вечно меняющийся scope: Отсутствие этапа проработки требований (grooming), когда задачи приходят в виде "сделайте как в TikTok", а детали выясняются в процессе. Это главный источник неэффективности.

4. Неадекватное отношение к frontend как к дисциплине

• Восприятие фронтенда как "вёрстки": Когда бизнес или бэкенд-лид считают, что фронтенд — это просто "нарисовать по макету", недооценивая сложность state management, производительности, accessibility (a11y), работы с API, безопасности (XSS, CSRF) и архитектуры.

  // Плохой пример: бизнес-логика, размазанная по компонентам, вместо вынесения в сервисы/сторе
  // Компонент A
  const discount = price * 0.9; // Магическое число, дублирование логики
  
  // Компонент B (где-то в другом файле)
  const finalPrice = itemCost * 0.9; // Та же логика, но уже с другой переменной
  

• Отсутствие дизайн-системы и консистентности: Когда каждый новый экран или компонент рисуется "с нуля" без единых правил, что приводит к фрагментированному интерфейсу и бесконечной работе над мелкими правками.

5. Бизнес-подход, игнорирующий техническое качество

• Фокус только на скорости, а не на качестве (Move fast and break things): Постоянное давление "сделать вчера" в ущерб рефакторингу, тестированию и архитектурным решениям. В долгосрочной перспективе это приводит к техническому долгу, который парализует разработку.
• Нежелание инвестировать в инфраструктуру: Отказ от выделения времени на обновление зависимостей, настройку инструментов, улучшение pipeline, обучение команды. Это как экономить на обслуживании станков на заводе.

Резюмируя, я стремлюсь к работе в зрелой продуктовой или аутсорс-компании, где ценятся:

• Современный стек (React/Vue/Svelte/Next/Nuxt, TypeScript, современный tooling).
• Здоровые процессы (Agile/Scrum с акцентом на смысл, а не ритуалы; чёткие code review и CI/CD).
• Баланс между скоростью и качеством с пониманием ценности технического excellence.
• Культура уважения, доверия и открытой обратной связи.

Среда, лишённая этих принципов, не позволяет создавать надёжные, масштабируемые продукты и расти как профессионалу, что является для меня ключевым мотиватором.