Любопытной Варваре на ревью нос оторвали

В одном из проектов, над которым я работаю, я нашёл баг во внешней библиотеке. Я выяснил, что баг появился в конкретном релизе библиотеки.

Что нужно сделать? Правильно, залезть в их мердж-коммит с этим релизом и попытаться понять, а чо они там сломали =)

Параллельно я, разумеется, общался с самими разрабами по поводу бага, и они выкатили фикс в следующем релизе.

И знаете что? Когда я смотрел их код, который я видел впервые в жизни, я за 5 минут предположил возможный источник проблемы и путь её решения.

И их мердж-коммит с новым релизом мою гипотезу подтвердил =)

Лишнее подтверждение тому, что если ты шаришь в computer science и сеньоришь в одном из нормальных ООПшных языков, тебе в целом уже пофиг, на каком языке и что писать – онбординг 5 мин и погнали =)

Ну 5 мин на любой язык это я конечно загнул, но суть вы думаю уловили :)

А у вас было такое, что бэкендеры или айосеры что-то наворотили, а потом ушли в отпуск / уволились, и вам пришлось за ними баги фиксить?)

Кого куда зачем делить, нормально же общались((

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

Если у вас 2 разработчика, то увеличение скорости сборки на 5 минут будет выигрывать компании пару часов в день, а если у вас 50 разработчиков – то у компании дневной КПД вырастет в несколько раз. Stonks! 📈

С этим и помогает многомодульность (если правильно организована🌚). Задумка такая: делим приложение на несколько мелких независимых частей, и тогда изменения в одной части не потребуют пересборки всего проекта для запуска – потребуется пересобрать только изменённую часть и её зависимости. Так мы и время сэкономим, и сможем отдать какую-нибудь новую часть новому джуну, не боясь, что он в процессе разработки пол-проекта нам поменяет. Пусть сидит там чудит себе на здоровье, на код-ревью посмотрим 😎

Есть два способа деления:
– по слоям Clean-архитектуры (модули app, domain, data и presentation)
– core-feature деление.

С первым всё понятно: тут главное удобство в том, что ты учишься жить по клину, и прям на уровне модулей можешь прописать, что в domain нельзя тащить android-классы, и что domain не зависит от остальных модулей-слоёв. Удобно для начинающих и для тренировки, но в плане масштабирования не очень удобная история: в какой-то момент вам захочется делить на более мелкие части, чем 4 модуля, захочется выносить отдельные фичи в отдельные модули, и приложение начнёт постепенно превращаться в кавардак.

Core-feature деление – более удобная история: в core пихаем всё общее и используемое всеми модулями, а в feature... Тут опять 2 варианта:
– либо один экран – одна feature, либо один флоу – одна feature. Флоу – группа экранов, объединённых общим смыслом – например флоу авторизации или флоу покупки. Чаще всего делят по флоу.

И внутри каждая feature живёт своей жизнью: если там нет работы с данными, а только презентейшн-логика, то там из клин-слоёв только presentation, а если есть и работа с данными, и своя бизнес-логика – то в feature будут все 3 своих clean-слоя. Под каждый слой своя папка внутри фичи.

Во "взрослом" core-feature делении к feature-модулю, в котором лежит вся логика фичи, делают ещё feature-api модуль – это модуль-прослойка, состоящий только из интерфейса модуля, отражающего то, что от этого модуля нужно всем остальным. Если модуль состоит из одной активити и всей сопутствующей логики – значит, скорее всего, апи фичи будет состоять из старта этой активити. И все остальные модули не будут ничего знать о том, что происходит в самой фиче – а будут только использовать апи этой фичи.

Звучит всё это заманчиво, но на деле и в реальной компании вас все равно ждёт кавардак, это я вам обещаю. У вас точно часть общего будет в core, часть в каком-нибудь "временном" common, а часть вообще "временно" рассована по отдельным фичам с задачей по рефакторингу в бэклоге, которую однажды вечером пятницы наконец закэнселят и примут неизбежную бренность бытия.

Готов поспорить, что ни у кого не найдётся идеального мультимодульного проекта в проде, и чтоб у него было хотя бы тыщ 50 активных юзеров 😏

☁️Офлайн-встречи мобильных разработчиков уже в эти выходные!

😉Привет! На связи Coffee&Code — международное сообщество мобильных разработчиков.

😎Приглашаем вас на бесплатные встречи мобильных разработчиков в формате дружеской беседы. Будем обсуждать разработку, делиться опытом, задавать вопросы и просто приятно проводить время в кругу единомышленников.

🤪Пообщаемся на технические темы, обсудим интересные события из мобильной разработки, разберем вопросы с собеседований и поделимся опытом!

🤖 Android | 📱 Mobile | 🍏 iOS

📍СПИСОК ГОРОДОВ

💃Также мы выкладываем интересные технические/полезные видосики в наш YouTube канал и записываем Подкаст! Ждем тебя на встречах!

Вы ж помните, я был самоучкой, а на первой серьёзной работе через 3 месяца уволился лид и оставил меня одного. На 4 года =) Ну как, команда у меня была, но из бэкендеров-фронтендеров-дизайнеров-тестировщиков. Ни одного мобильщика больше не было всё это время.

И хотя я не то, чтобы дофига социально активный, мне все равно сильно не хватало общения "со своими". У меня были какие-то потуги это общение найти, но кроме каких-то англоязычных форумов я ничего не увидел, в итоге взгрустнул, да и забил.

И одним из главных пунктов, которые я называл при собеседовании в Белку, было "чтоб была команда разрабов, с которыми можно перетереть за андроид, походить на конференции и вот это вот всё".

И эти слова шли реально от души, как сейчас помню =)

Так вот – однажды, когда мы сплавлялись с друзьями по Тверце, один знакомый айосер мне сказал, что есть такое сообщество – КофеКод, на котором мобильные разрабы встречаются попить кофейку и потереть за жизу.

Крутой проект, как по мне. 10 лет назад мне бы это сильно помогло, хотя бы психологически. А если вы прямо сейчас ищете работу – вы, думаю, в курсе, что "по знакомству" устроиться куда проще, особенно если вы джун.

Так что советую сходить к кофекотовцам на встречи: заведёте полезные знакомства, ну или просто поболтаете в кругу своих =) 👇

Мои трудовыебудни:

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

Реализован старый список был на RecyclerView, так что я решил его и переделать. Решил, что надо найти решения двух разных задач: динамическая ширина элемента и динамическое количество элементов в строке, а потом смёрджить два решения в новый SuperAdapter и дело в шляпе.

Сказано – сделано.
Да хрен там, в итоге я понял, что если делать это вручную, то я в рамки этой таски точно не умещусь, и пошёл искать другое решение.

В итоге я наткнулся на гугловский FlexboxLayoutManager, казалось бы, предназначенный как раз для этой задачи. Довольный, затащил его в проект и реализовал.

А потом на ревью мне коллега покрутил пальцем у виска и сказал, что для этой задачи куда проще и удобнее сделать через ChipGroup, который как раз для этой цели и создан.

Но этот чёртов ChipGroup мне на мой запрос в гугле ни разу не вылез =)
Век живи, век учись. Оказалось, реально удобная штука, возьмите на заметку.

Особенно радует, что в ChipGroup можно с помощью addView добавлять не только наследников Chip, а любые вьюхи, и они все равно будут норм выстраиваться. Но часть методов / атрибутов правда перестанет работать, например singleSelection – потому что он работает только на Chip.

А вот к FlexboxLayoutManager есть вопросики: странновато он настраивается, странноватые дефолтные отступы между элементами, и сходу тоже непонятно, как их настраивать.

А вы бы как пошли эту задачу решать?) Я один такой тугой?)

🤔 Однажды мы с коллегами плотно зарубились на вопросе: "А как нам назвать юзкейс?"

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

📌 С одной стороны, один и тот же юзкейс может понадобиться ретраить по-разному в разных случаях. Где-то надо бесконечно запрос повторять no matter what, где-то надо в какой-то момент ошибку показать, где-то вообще не надо ретраить. И если во всех юзкейсах будет разная логика ретраев, то по обычному названию юзкейса GetUserUseCase будет совершенно непонятно, ретраится ли он внутри – тогда мы теряем атомарность юзкейса, а это его важная часть. Получается, логичнее выносить ретрай из юзкейса в presentation-слой, из которого он вызывается.

📌 С другой стороны, ретрай может быть частью бизнес-логики, и тогда где ж ему ещё быть, как не в юзкейсе.

В итоге пришли к тому, что если уж помещаем ретрай в юзкейс – надо точно указать это в его названии.

И вот как назвать юзкейс, в котором делается бесконечный перезапрос? GetUserWithInfiniteRetryUseCase как-то долго, сложно и не метко.

😏 В итоге пришли к названию GetUserOrDieTryingUseCase и, довольные, разошлись. С тех пор нейминг так и живёт уже 3 года =)

Как правильно страдать хернёй

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

Жена, после почти месяца полного расслабления и отключения головы, со свежими силами принялась за дела, и начала делать всякое полезное, как пчёлка.

А я приехал и практически слёг в кровать под тяжестью невидимого груза. С удивлением взирая на порхающую вокруг жену.

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

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

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

А вы себе верите?

Даёте себе часами и днями "страдать хернёй" (так это видят окружающие, на самом деле вы делаете огромную работу, просто не осознаёте. Но устаёте вы от этого как и от физического труда) ?