Расскажи о неудачном опыте

Анализ неудачного опыте в разработке Android

Говоря о неудачном опыте, я считаю важным не просто описать негативный кейс, но и проанализировать его причины, извлечённые уроки и последующие улучшения процессов. Я расскажу о проекте, который мы условно называли "Мгновенный мессенджер для корпоративного сектора".

Контекст и амбициозные цели

Проект стартовал в 2017-2018 годах. Цель была масштабной: создать кроссплатформенный (Android, iOS, Web) мессенджер с end-to-end шифрованием, голосовыми/видеозвонками (WebRTC), синхронизацией истории между устройствами и глубокой интеграцией с внутренними CRM/ERP системами заказчика. Команда состояла из 8 человек: 2 Android-разработчика (я был техническим лидом направления), 2 iOS-разработчика, 2 бэкенд-разработчика, 1 веб-разработчик и тимлид.

Ключевые ошибки и "красные флаги"

Неудача не была мгновенной, она стала результатом накопления системных проблем:

1. Отсутствие Proof of Concept (PoC) для ключевых технологий. Мы сразу приняли решение писать нативные клиенты на Kotlin и Swift, но для логики общего ядра (шифрование, парсинг протокола) решили использовать C++ и CMake, интегрируя его через JNI на Android и нативные биндинги на iOS. Никто в команде не имел глубокого опыта сборки сложных C++ проектов для мобильных платформ. Проблемы начались сразу: бесконечная настройка тулчейнов, конфликты стандартных библиотек, падения на этапе линковки.

   // Пример "хрупкого" JNI-кода, который часто ломался
   external fun nativeDecryptMessage(encryptedData: ByteArray): ByteArray?
   
   // В нативном слое (C++)...
   JNIEXPORT jbyteArray JNICALL
   Java_com_company_messenger_CryptoModule_nativeDecryptMessage(
       JNIEnv *env, jobject thiz, jbyteArray encryptedData) {
       // Логика, которая по-разному вела себя на x86 эмуляторе и ARM устройстве
   }
   

2. Архитектурный максимализм и игнорирование MVP. Вместо того чтобы выпустить простой чат с текстом и постепенно добавлять функции, мы сразу заложили многомодульную архитектуру с чистыми UseCase, Repository и отдельным модулем для нативного кода. На диаграммах всё выглядело идеально, но на реализацию базового обмена текстом ушло 4 месяца. Клиент начинал нервничать.

3. Провал в оценке сложности WebRTC. Интеграция звонков была отдана на аутсорс "специалисту", который настроил демо на основе публичного сервера. Когда встал вопрос об развёртывании своего TURN/STUN сервера и адаптации под специфичный NAT заказчика, выяснилось, что знания команды поверхностны. Звонки работали только в идеальных условиях Wi-Fi.

4. Синдром "текущей крыши". Мы тратили непропорционально много времени на "гибкость" и "масштабируемость" будущего кода, в то время как текущие базовые функции (например, стабильная доставка сообщений при переключении сети) были реализованы с багами. Мы использовали Socket.IO с кастомными расширениями, что создавало проблемы с бэкпрессуром и восстановлением соединения.

Кульминация и итог

Через 9 месяцев и почти исчерпанный бюджет мы представили альфа-версию. Она была нестабильна:

• На Android потребление памяти росло из-за утечек в JNI-слое.
• Синхронизация между телефоном и веб-клиентом теряла сообщения.
• Звонки падали в 70% случаев.
• Приложение весило под 50 МБ из-за нативных библиотек.

Заказчик отказался принимать продукт. Проект был свёрнут с значительными финансовыми потерями для компании и репутационным ущербом.

Извлечённые уроки и трансформация подходов

Этот болезненный опыт стал мощнейшим катализатором профессионального роста. Вот принципы, которые я теперь применяю неукоснительно:

• Поэтапная реализация и ранняя поставка ценности: Сначала запускаем минимально жизнеспособный продукт (MVP) даже на ограниченном стеке (например, сокеты + REST, без нативного кода). Любую сложную технологию (WebRTC, собственный протокол) предваряем изолированным PoC.
• Принцип "Сделай это работающим, затем сделай это правильным": Нельзя в ущерб стабильности базового сценария закладывать архитектуру для гипотетических требований. Сначала стабильный текстовый чат, потом — шифрование, потом — звонки.
• Ответственность за технологический стек: Если команда берет новую технологию, необходимо иметь внутри хотя бы одного эксперта или выделить время на её глубокое изучение до старта продакшн-разработки.
• Прозрачность и регулярная демонстрация: Чаще показывать прогресс заказчику, даже сырой, чтобы корректировать курс. Не прятать проблемы "до последнего".
• Критический взгляд на нативный код (C++/Rust): Его использование в Android должно быть строго обосновано (вычисления, существующие кодовые базы). Во многих случаях Kotlin Multiplatform Mobile (KMM) или тщательно оптимизированный чистый Kotlin — более безопасный выбор.

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