Что не нравилось на предыдущих работах

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

1. Отсутствие культуры качества кода и долгосрочного видения

Часто в погоне за скорейшим релизом бизнес недооценивает важность технического долга и архитектурной целостности.

• «Быстрые правки» и копипаста: Мне доводилось видеть, как для срочного фикса бага в нескольких местах копировались огромные блоки кода с минимальными изменениями, вместо того чтобы выделить общую логику. Это вело к экспоненциальному росту сложности поддержки.

  // ПЛОХО: Одинаковая логика в двух фрагментах
  class FragmentA : Fragment() {
      private fun loadData() {
          // 50 строк загрузки, обработки ошибок, отображения
      }
  }
  class FragmentB : Fragment() {
      private fun loadData() {
          // Те же 50 строк с изменением одной переменной
      }
  }
  
  // ХОРОШО: Вынесение логики в общий UseCase или Repository
  class DataLoadUseCase(private val apiService: ApiService) {
      suspend fun load(param: String): Result<Data> {
          // Единственная реализация
      }
  }
  

• Игнорирование модульности: Проект превращался в монолит, где изменение одного модуля вызывало неожиданные падения в другом из-за сильных скрытых связей. Отсутствие четких границ между слоями (UI, Domain, Data) затрудняло тестирование и работу в команде.

2. Неэффективные процессы разработки и коммуникации

• Размытые Definition of Done (DoD): Часто задача считалась выполненной, когда написан код, без обязательных code review, тестов, обновления документации или проверки на разных типах устройств. Это приводило к тому, что в мастер попадал сырой функционал.
• Микроменеджмент и отсутствие автономии: Когда каждый технический шаг (выбор библиотеки, подход к реализации) требовал многоуровневых согласований с людьми, не погруженными в код, это убивало мотивацию и сильно замедляло процесс. Я верю в принцип «доверяй, но проверяй» через четкие ТЗ, код-ревью и демо.
• Слабая обратная связь от дизайнеров и Product Owner'а: Получение макетов в формате, не адаптированном для разработки (например, без отступов, состояний, указаний по анимациям), или частые немотивированные изменения ТЗ уже в процессе разработки создавали лишнюю работу и деморализовали команду.

3. Недостаток внимания к нефункциональным требованиям и мониторингу

• Производительность как второстепенная задача: Проблемы с просадкой FPS, потреблением памяти (LeakingCanary постоянно сигнализировал), временем холодного старта приложения решались по остаточному принципу — «когда будет время». Однако именно эти метрики напрямую влияют на пользовательский опыт и рейтинг в магазине приложений.
• Отсутствие инструментов мониторинга: Мы не знали, какие экраны падают у пользователей, какие API-вызовы часто завершаются ошибками. Не было внедрено логирование крашей (например, через Firebase Crashlytics) и аналитики производительности. Это означало, что мы «летали вслепую», а о многих проблемах узнавали из отзывов в Google Play.

4. Застой в профессиональном развитии команды

• Страх перед обновлением стека: Удержание на старых, но «проверенных» версиях библиотек и Android SDK годами, потому что «и так работает». Это приводило к тому, что проект становился все более уязвимым с точки зрения безопасности, терял совместимость с новыми инструментами, а разработчики отставали от современных практик (Coroutines/Flow, Jetpack Compose, Hilt).
• Отсутствие обмена знаниями: Не было регулярных внутренних митапов, обсуждения архитектурных решений или сессий по разбору сложных багов. Это приводило к сильной буссине-зависимости (bus factor) и неравномерному росту членов команды.

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