Как понял что перестал развиваться в текущем проекте

Отличный и очень честный вопрос. Это осознание приходит не внезапно, а складывается из ряда повторяющихся сигналов. У меня был период, когда я столкнулся с этим. Вот по каким ключевым маркерам я понял, что развитие на проекте зашло в тупик.

Основные признаки стагнации

1. Топтание на месте технически

Это самый очевидный индикатор.

• Однотипные задачи: Все задачи сводятся к CRUD (создание, чтение, обновление, удаление), косметическим правкам UI или исправлениям багов из года в год. Исчезают задачи, требующие изучения новых подходов.
• «Технологический пуризм»: В проекте застывший стек (Clean Architecture образца 2018 года, только RxJava 2, запрет на Compose и т.д.). Любое предложение о модернизации натыкается на ответы: «Работает — не трогай», «Нет времени», «Слишком рискованно». По сути, ты становишься смотрителем легаси.
• Отсутствие глубины: Все архитектурные решения уже приняты до тебя, и ты лишь следуешаблонам. Нет возможности влиять на software design, внедрять SOLID или DDD принципы глубже, экспериментировать с MVVM, MVI или UDF.

Вот пример кода, который я перестарался видеть — бесконечное расширение одного ViewModel:

// ViewModel, которая превратилась в монстра
class LegacyViewModel : ViewModel() {
    // ... 1000+ строк кода
    fun loadUser() { /* ... */ }
    fun loadPosts() { /* ... */ }
    fun loadSettings() { /* ... */ }
    fun updateProfile() { /* ... */ }
    fun sendMessage() { /* ... */ }
    // Десятки LiveData полей, запутанная бизнес-логика
    // Никакого разделения ответственности, это антипаттерн God Object.
}

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

2. Интеллектуальный комфорт и рутина

• Автопилот: Ты можешь выполнять 90% задач, почти не задумываясь. Пропала необходимость гуглить, читать документацию (Android Developers, Kotlin Lang) или изучать исходники библиотек.
• Предсказуемость: Каждый спринт/месяц/квартал известен наперед. Нет вызовов, challenges. Пропадает азарт и драйв от решения сложных проблем.
• Внутренний диалог: Появились мысли: «Я это уже делал 100 раз», «Опять эта скучная таска», «Здесь нельзя сделать лучше».

3. Карьерный и экспертный потолок

• Менторство в одну сторону: Ты только учишь новых членов команды устоявшимся, часто устаревшим практикам проекта, но сам не учишься ни у кого внутри команды.
• Отсутствие ролевого роста: Несмотря на опыт (lead, senior), тебе недоступны решения об архитектуре, выборе технологий, процессах разработки (CI/CD, code review). Ты — исполнитель, а не инженер.
• Профессиональная изоляция: На конференциях (Moscow Android Dev, Droidcon) или в статьях ты видишь обсуждение KMP, Jetpack Compose, coroutines flow, modern CI и понимаешь, что твой проект живет в параллельной реальности.

Что я начал делать в этой ситуации?

Осознание проблемы — первый шаг к решению. Я стал действовать по двум фронтам:

1. Внутри проекта:

    *   Инициировал **технические долги** и митапы, чтобы обсудить модернизацию.
    *   Предложил внедрить `DataStore` вместо `SharedPreferences` в одном маленьком модуле как пилот.
    *   Стал писать более подробные `code review` с ссылками на `Android Guidelines` и `Kotlin idioms`, чтобы поднимать общую планку.

1. Вне проекта (самое важное):

    *   Выделил время на **персональный tech radar**. Начал пет-проект на `Kotlin Multiplatform` с `Compose UI` для обеих платформ.
    *   Погрузился в смежные области: настройку `GitLab CI/CD` пайплайнов, написание скриптов на `Kotlin Script`.
    *   Контрибьютил в `open-source`, чтобы увидеть код и процессы других.

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