Работа в банке. Часть 4. Код.

Вот мы и подобрались к финишу. Теперь самое интересное - код. И самое неоднозначное.

Архитектура.

У нас многомодульный проект. Модулей порядка 30-40 (список не помещается на экране iMac 5к).

Модули связаны между собой через некие медиаторы (по сути аналог того, что рассказывал Саша Блинов про многомодульную архитектуру на своем докладе). Внутри каждый модуль разбит по Clean Architecture. Здесь ничего особенного. В качестве DI-контейнера тоже классика - Dagger 2. 

Собственно код.

Процентов на 95 у нас в проекте Kotlin, но увы, есть старые куски и на Java, что довольно странно в 2022-ом.

Да, проект большой, ну хотя, скорее средний, но все же. Основная проблема кода - это один огромный базовый модуль, который все никак не растянут на кусочки (другие модули) и как раз в этом модуле весь Java-код. Раньше проект был разбит на обычные пакеты, что и осталось в этом огромном куске Г. Вторая проблема в том, что если вы внимательно читали прошлые посты, то помните, что в приоритете у банков обычно новые фичи, поэтому иногда приходится лезть в этот базовый модуль и добавлять новый код. Иногда даже на Java, но это редко и обычно благо мы такой код конвертируем в Kotlin. И последняя проблема этого модуля - высокая связность. Главный экран, который содержит кучу зависимостей также лежит в этом модуле. Вынести его довольно непросто, но скоро попробуем. И как раз много новых изменений приходится на этот экран, ибо в нем отображаются все продукты и прочие основные вещи, которые вы видите в типичном банковском продукте.

Тесты.

Мы пишем тесты. Круто, подумали вы. Но не все так радужно. У нас есть Unit-тесты, в основном написанные на фреймворке Spek, но приоритет почему-то именно на UI-тесты. То есть тестировать и гонять дизайнеров не выходит? Самое грустное, это то что тестов пишется мало и их не ревьювят. Плюс политика партии не совсем понята. iOS-команда решила не писать UI-тесты, ибо у нас еще есть команда пишущая тесты для Lego (тест-система). То есть какого-то консенсуса нет, что странно. В теории тестами тогда можно было б обмениваться. И еще один момент: на Spek написаны не все Unit-тесты, часть написана по-старинке на jUnit или еще чем-либо (уже не помню, но суммарно 2-3 фреймворка задействовано).

В чем проблема медиаторов?

То что это огромные простыни кода. God-object в чистом виде в котором не всегда быстро получается разобраться и найти нужный кусок. Не говоря уже о том, что часто он копируется и содержит много лишней писанины. Второй нюанс - это базовый огроменнейший медиатор, который всегда хранится в памяти, в независимости от модуля и который содержит 2400 строк! 

Presentation-слой.

Здесь у нас все по классике. MVP, но только на своей атмосфере в виде реализации обычных интерфейсов View и Presenter. Скоро начнут появляться кусочки MVI, так как постепенно появляются куски на Compose. И это уже гораздо интереснее. Правда, MVI у нас пока будет тоже свой немного рукописный, что впрочем нормально. Как-нибудь отдельно расскажу чем он отличается от популярных библиотек. В остальном, ничего интересного: ViewBinding, фрагменты, местами все еще есть мусор (например, kotlin.synthetic, кое-где даже Butterknife и Mosby - либа такая была для MVP, олды помнят). 

RxJava.

Да, у нас именно она. Так было всегда и так продолжает быть и дальше. Этим фактом я весьма расстроен, потому что не вижу причин не использовать любимые корутины в 2022-ом, но как наш лид говорит. Профита особого переход не даст, значит и смысла нет. Но постойте, а как же чтение кода и простота исправления багов? Чем не довольно весомый профит? На корутинах код значительно проще, понятнее и его проще отлаживать. Я ненавижу эти простыни цепочек Rx или сидеть искать какой-то злоебучий баг, в котором потом выяснится, что поток у вас горячий, а не холодный или еще какая-либо ебанина из этой серии. Rx по-прежнему хорош, только зачем он, когда теперь есть корутины? Я согласен с тем, что переходить довольно болезненно, но опять же MVI будет гораздо симпатичнее смотреться на корутинах и многомодульная архитектура прекрасно позволяет это делать поэтапно. Вообщем, странно. Не вижу никаких проблем перейти постепенно.

Аналитика.

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

Сборка проекта.

Во-первых, нужно хорошее железо, чтобы проект собирался быстро. Dagger 2 здесь проявляет себя не с лучшей стороны. Новая прошка на ARM, кстати, собирает гораздо быстрее, чем мой основной рабочий iMac. Про железо тоже как-нибудь поговорим.

Во-вторых, собирает проект у нас GitLab. Ну точнее делает сборки для задач по пушу в репозиторий. Тут все стандартно. Также умеет и публиковать приложение в Firebase и даже в гугловую консоль подгружать. Кстати, Github тоже уже это все умеет.

Форматирование.

Снова фейл. Почему-то у нас нет какого-либо Code Style. Вроде бы стандартный Kotlin-овский используем, но в тоже время не везде. А именование переменных хромает и это уже к процессу ревью кода. Ну блин, какие еще myPresenter мелькающие в проекте? Ну это и к вопросу выбора кадров. Дефицит говорят!

Кстати, еще про модули.

Я бы выделил некоторые модули в отдельные библиотеки, потому что сейчас все это напоминает помойку. Например, у нас в проекте модули: debuginfo, модуль с примерами на Compose (демка), uikit-ы с компонентами, отдельный модуль полигон для тестов. Зачем это все подключено к проекту и лежит в одном репозитории с самим приложением не очень понятно. 

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

Но каких-то прям очень серьезных проблем все равно не так много, единичные случаи. Поэтому неприятно, но жить можно.

Собственно, так и живем.