Thread by @mobileunderhood

Итак, знакомство)

Про себя - в Android разработке чуть больше 3 лет. Про весь путь подробнее расскажу в треде про "из ВУЗа в настоящего разработчика", поэтому сразу перейду к рассказу про компанию

Не стесняйтесь по ходу рассказа задавать вопросы)

Если вы вдруг почему-то не знаете чем мы занимаемся - мы аутсорсим мобильные приложения, поэтому ядро команды это iOs и Android разработчики. Нас в среднем по 12 человек на каждую платформу. В данный момент в команде Android над несколькими проектами трудятся 11 человек

На каждом проекте есть лид, который отвечает за проект, и один или несколько разработчиков в зависимости от сложности проекта: в среднем по 2 человека на проект, но есть и жадные проекты, которые могут съедать до 4-5 человек в свои самые активные стадии развития

Я в данный момент лидствую над Android приложением Альфастрахования - если вы им пользуетесь и у вас от чего-нибудь горит жопа, пишите мне в телеграмм (тоже xd720p), поставим вашу боль на карандашик

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

Помимо лидов на проектах, есть один тимлид, чтобы править всеми. Он занимается 1-to-1, организует внутренние митапы, следит за командой и проектами, чтобы люди не выгорали и развивались. При этом никого не тащат силком развиваться в сеньоры, лиды, качать T-shape и так далее

Если человек хорошо справляется со своими текущими задачами и в ближайшее время хочет заниматься именно разработкой на проекте, на него не будут косо смотреть или увольнять за то, что за последние полгода ты не стал пост-сеньором 80 уровня

При этом качество кода сохраняется за счёт одного из главного правил найма в Питерский офис RMR - разработчик должен быть не ниже middle. Это позволяет быть уверенным, что спустя несколько недель, человек будет справляться с разработкой на проекте без посторонней помощи

Также при необходимости или по желанию разработчика, он может стать лидом на проекте или вообще начать новый. Если разработчик чувствует, что начинает выгорать на текущем проекте - он сообщает об этом тимлиду и его могут перевести на другой проект

Как я писал выше - мы аутсорсеры, но я считаю наш аутсорс очень близким к продуктовой разработке потому что мы ведём проекты по несколько лет. Например, моему проекту стукнуло уже 5 лет. И это позволяет избавиться от главной проблемы аутсорса - Huyak&VProductionDrivenDevelopment

Могу дальше рассказать как раз про технологии и архитектуру, которые используем на проекте или уже перейти к рассказу про выступления на конференциях

Поехали про используемые у нас технологии. Подход к архитектуре - стремимся в Clean Architecture, но используем архитектуру для решения проблем, а не просто следуем заповедям. Архитектура ради архитектуры - это непозволительная роскошь в продовской разработке

Например, использование RxJava в разных слоях Clean Architecture - это неправильно, а данные при передаче между слоями нужно маппить. Но из-за этого возникает огромное дублирование кода и другие проблемы. Подробнее про такие штуки тут - habr.com/ru/company/mob…

На уровне с UI используем MVP, а именно Moxy причём которая от Arello-Mobile, а не новую moxy-community. В планах попробовать новую moxy, а вообще хочется потрогать MVVM и понять стоит ли тащить это сейчас в продовские проекты или рановато

@pro2on - отвечаю на твой вопрос)

Для запросов, обработки различных событий и тп используем RxJava 2. Буквально пару недель назад в отдельной ветке мигрировал проект на RxJava 3 и решил откатиться обратно по многим причинам, которые опишу далее

Как обновление в вакууме новая версия RxJava выглядит вполне логичной: всевозможные старые операторы добавили для всевозможных классов - если раньше вы хотели в Maybe использовать какой-нибудь оператор, применимый к Single, которого не было в Maybe, то RxJava 3 вас обрадует

Также глобальный ErrorHandler научился отлавливать ошибки из цепочек, где происходит race condition, и из цепочек с внутренними потоками данных, когда внешний поток, например, откладывает ошибки до завершения как в данном примере:

Дальше начинаются спорные для Android разработчиков моменты. RxJava 3 теперь поддерживает Java 8 API, а именно Stream, Function, Optional и теперь можно работать с Observable как со Stream, а потом снова возвращать Observable, создавать Maybe из Optional, но есть один нюанс:

То есть необходимо поднять minSdk, чтобы на все 100 воспользоваться RxJava3. Если ваше приложение выходит в России, то у нас по версиям Android всё неплохо и обновление не получат только 10% пользователей, если же вы работаете и на азиатский рынок - теряйте все 20% пользователей

Иными словами Android SDK как бы немного отстаёт от Java. При этом сейчас основной язык разработки под Android - Kotlin, где уже реализовано подобие Java Stream с бОльшим количеством операторов, без необходимости конвертации списков в Stream и обратно и зависимости от minSdk

И казалось бы, можно не поддерживать фичи Java 8 API. Но переезды на новую версию RxJava - всегда боль в том случае, если вы используете другие либы, которые завязаны на предыдущую версию RxJava. По этой причине многие до сих пор сидят на первой RxJava

Какие либы до сих пор на RxJava 2 и непонятно когда переедут на RxJava 3:
- RxRelay
- ReactiveLocationProvider
- RxBindings
- Любая другая библиотека, завязанная на RxJava 2

Для решения этой проблемы на помощь спешит - github.com/akarnokd/RxJav…

Но при этом ваш код покроется огромным количеством методов для конвертации одной RxJava в другую. И придётся при написании нового кода постоянно поддерживать между собой старую-новую версию RxJava

Ах да, ещё в RxJava 3 перелопатили структуру пакетов, поэтому у вас уйдёт несколько часов на исправление всех импортов:

И ещё один нюанс, который выстрелит вам в ногу как только вы наконец-таки соберёте проект. Приложение с вероятностью 99.9% упадёт при первом запросе в интернет потому что ретрофитовский адаптер пытается конвертнуть Call в RxJava2 Single, а не RxJava 3

Исправляется либо написанием своего адаптера, либо затаскиванием адаптера от David Karnok - github.com/akarnokd/RxJav…

В итоге Если вы Android разработчик, то сейчас переходить на RxJava 3 не нужно, потому что это принесёт вам кучу проблем при миграции и не добавит каких-то жизненно необходимых фичей. Отсюда возникла мысль, что, может быть, время Rx на Android прошло и пора попробовать Flow

Вообще я рассказывал про используемые у нас технологии, просто про RxJava 3 наболело и меня понесло.

Для навигации между экранами используем Cicerone. Для поддержки различных типов списков юзаем AdapterDelegates. Из того, о чём хотел рассказать про технологии у нас, вроде всё

То что я описал в этом треде - наш core стек технологий для разработки, который был собран методом проб и ошибок, чтобы понять, что именно такие подходы лучше всего подходят для разработки Android приложений в нашей компании

Это не запрещает экспериментировать на проектах. У нас есть проект, где используются корутины, один проект написан на Flutter, ещё в одном пытались написать бизнес-логику на Kotlin MPP. После экспериментов мы обычно собираем внутренний митап, чтобы поделиться опытом с коллегами