На мобиусе мы участвуем в трех докладах!

- Я расскажу про наш опыт с дополненной реальностью,
- Максим Качинкин про внедрение Compose в Дринкит,
- Екатерина Батеева будет экспертом на докладе про локализацию.

При этом два из трех докладов доступны для всех зарегистрировавшихся на Comunity Day, успевайте подать заявку!

Совсем скоро пройдёт Mobius — крутейшая техническая конференция для мобильных разработчиков. Идёте на неё или планируете подключиться онлайн? Приходите послушать участников нашей команды! 🤩

23 мая с 12:15 до 13:00 Макс Качинкин, наш Android Tech Lead, расскажет о тех кейсах-вызовах, с которыми его команда столкнулась при переносе проекта с Compose на View, и о том, как они справлялись с этими вызовами.

В тот же день, с 14:00 до 15:00, Миша Рубанов, Head of Mobile & People Lead, поделится опытом приготовления 3D-пиццы. Покажет, как решить все интерфейсные проблемы, с которыми он столкнулся. В общем вы узнаете всё о том, как прикрутить AR к вашему приложению буквально за один вечер. 😮

Екатерина Батеева, iOS Developer, в этот день будет экспертом на докладе о локализации iOS-приложений в 2024 году, который можно будет послушать с 12:55 до 13:35. Кстати, если вам интересно, чем занимаются эксперты на конференциях, пишите — расскажем в одном из следующих постов.

В оффлайн-дни конференции, 31 мая и 1 июня, Катю можно будет встретить очно в кластере «Ломоносов», находящемся по адресу Раменский бульвар, 1. Приходите пообщаться! 👀

Какой сейчас год?

Уже смотрели WWDC20? Apple показали новую технологию — App Clips. Готов поспорить, мини-приложения станут очень популярными! Мы поспешили разработать свой App Clip и написали статью, в которой рассказываем, как мы придумывали фичу, с какими проблемами столкнулись при разработке, и делимся аналитикой после запуска.

https://habr.com/ru/companies/dododev/articles/821009

Доступность в 2ГИС

Не могу не поделиться статьей про доступность в 2ГИС.
- Есть пример кода как работать с adjustable-каруселью.
- Как писать юнит-тесты для скринридера. Я бы через снепшоты текста сделал, но самое главное — подход.
- В целом про интерфейс навигационного приложения, когда визуал расходится с описанием для скринридера

https://habr.com/ru/companies/2gis/articles/826360/

Как продать доступность бизнесу

Вопрос из чата: как продать эту вашу доступность бизнесу? Вопрос частый, делюсь ссылками.

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

Если конкретно про скринридер и разные такие технологии, то работа с деревом доступности в интерфейсе дает покрытие нескольким технологиям: VoiceOver, Switch Control, Voice Control, «чтение экрана» и «чтение выбранного». В сумме это около 4% пользователей. Про это скоро выйдет статья, но близко к этому в докладе https://youtu.be/72tAiNzrHxM?si=yPdVRwQw1wPOKNsO

Начать можно собрав аналитику со старта приложения и целевого действия: увидите количество и конверсию. Посмотреть что собирать и как можно в этой библиотеке. https://github.com/chrs1885/Capable

Уговаривать бизнес обычно нужно для масштабирования практик, сделать нормально можно и только на уровне разработчиков. Тут как с юнит-тестами: для начала нужно просто научиться работать с этим разработчикам, потом может оказаться, что у бизнеса ничего спрашивать и не нужно. Одних навыков разработчиков попрой достаточно, чтобы сильно повысить качество. Книжка нацелена именно на это https://rubanov.dev/a11y-book/

Скорость Compose

Дринкит на Android всю карточку продуктал сделал на Compose, это был большой и смелый эксперимент. По большей части он был успешным, но в конце оказалось, что первый раз экран открывается с ощутимой задержкой, потому что библиотека только в этот момент загружается и это видно визуально.

В деталях Максим Качинкин рассказал на Мобиусе, видео уже доступно!

Платим за написание удаление кода

Мы, разработчики, сидим и код какой-то пишем. Пишем, пишем, его всё больше и больше, а старое почти не удаляем. А когда удаляем то не ясно «а всё ли удалили» — Xcode никак не подсказывает, что где-то какие-то хвостики остались.

В итоге целая пачка проблем:
- Иногда при написании нового кода приходится что-то актуализировать в старом, а он может быть вообще нигде не используется и просто мертвым грузом лежит. Это мы время теряем.
- Иногда при подготовке кода к новым фичам что-то рефачим и случайно удаляем вызов важного метода. Это мы баги заносим.
- Постоянно билдим проект локально и на CI, и в том числе билдится и вот такой мертвый код. Это мы время теряем.

8 июня 2023, то есть год назад, я затащил в проект Додо Пиццы тулзу Periphery — она анализирует весь наш код и говорит «вот тут чет лишнее осталось и вот там кусок бесхозный стал». Её одобрение — одна из обязательных проверок на CI при влитии ПРов.

Я не знаю сколько нового мертвого кода она запретила вливать (хз как посчитать) и сколько багов предотвратила. Но у нас тут с мертвой точки сдвинулась война с брошенными фичатоглами и тулза сильно помогла при их выпиле. И продолжает помогать.

Сначала я скормил ей весь наш проект и она выдала мне около 3000 варнигов. Я понял, что устранить их за раз не вариант. Тогда я загнал все наши модули под карантин, а потом аккуратно раскарантинивал и устранял варнинги. Где-то месяца 2-3 назад я передал задачу другой разработчице, Маше, и где-то полтора месяца назад она закончила выносить все модули из карантина. Но это только первый этап был.

Вторым этапом стал тюнинг настроек Периферии: мы попросили ругаться ещё и на публичные проперти, если они не юзаются или если им нет необходимости быть публичными, так как никто снаружи их не юзает. Это дало нам ещё 3000 варнингов. Маша их устраняла последние полтора месяца.

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

Что это нам дало:
- Перестали тратить время на поддержание кода, который никогда не выполняется на проде.
- Сократили количество легаси. Вот прям сегодня после рефактора очередной кусок удалил по наводке периферии, потому что он перестал использоваться.
- Проект стал билдиться быстрее. Пруфов не будет.
- Ускорили и удешевили билды на CI.

Итог
С самого начала проекта мы считали количество строк кода по мере раскарантинивания проекта. Цифры такие:
Удалили: 27к
Добавили: 5к

Это много или мало? Давайте посмотрим на аналитику сонара:
Lines: 400к
Lines of Code: 250к

Получается мы удалили где-то 5-10% нашего приложения.

Что дальше
Можно подключить к периферии ещё и тесты — там много моков валяется бесполезных и хелперов лишних, на которые мы тож тратим время и силы.

Додо идет в 3д

Внимательный читатель давно мог понять вектор, но сегодня будет 3 новости про 3д.

Для начала – иконка! Объемненькая, с нашивочкой и все это не просто так.

Управление ожиданием

Самым интересным в интерфейсе было спрятать загрузку модельки. Она весит 3 мб, что достаточно мало, но качается все равно не моментально. При этом в феврале мы уже делали эксперимент с пиццей-сердце, из которой узнали, что в человек тратит от 3 до 8 секунд на размещение пиццы на столе, а значит, что у нас есть время скачать пиццу незаметно.

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

UX, который никто не заметит и в Фигме не нарисуешь, но вы теперь знаете как там хитро!

50% покрытие тестами

Хотел написать пост, что мы покрыли тестами больше 50% проекта за 4 года и какие выводы накопились, но там опять на статью вышло, а значит быстро не получится.

Поэтому можем наоборот — поспрашивайте в комментах что интересно про любые автотесты, я поотвечаю, а потом в статью заберу ответы, чтобы самое волнующее разобрать.

Как можно получать ускорение от тестов? Какие писать или не писать? Какая либа для автомоков лучшая?

Вопросов много, спасибо, буду отвечать в течении дня

Если бы начинал всё заново, что сделал бы по другому?

План такой:
- Как можно раньше втащить скриншот и снепшот-тесты, как можно чаще снепшотить данные, например, сеть и аналитику. Golden-master тестирование стало паттерном, который я часто применяю и к которому везде стремлюсь, но в начале про него не знал.

- Мокать сеть только через URLProtocol

- Сравнивать объекты только через XCTAssertNoDifference

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

- Понять, что тестировать надо через зависимости, эта статья перевернулся представление https://www.pointfree.co/collections/dependencies

- Тесты должны быть как можно более sociable, а не в изоляции. Хорошо тут перепридумано словао «интеграционные» тут https://matklad.github.io/2022/07/04/unit-and-integration-tests.html

- Отделять модули с самого старта проекта, выносить управление модулем через зависимости. Чем меньше вам билдить для прогона тестов, тем удобнее писать тесты. Увы, все проекты создаются как монолит от недостатка скила, а потом просто некогда переделывать и у нас распил занял 2 года фоновой работы.

- Не использовать Quick, потому что он упрощает написание, но усложняет поддержку. Я орал, когда тесты не смогли скомпилиться от большой глубины вложенности клож или когда скриншот-тест не смог прочитать картинку, потому что мы превысили максимальный размер названия файла!

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

- Писать UI-тесты разработчиками, но только для того, чтобы они сами могли выбирать на каком уровне тестировать фичу. В итоге чаще бы писали интеграционные тесты, которые стабильней и быстрее, чем UI-тесты.

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

- Всю архитектуру проекта планироть относительно того, как потом тестировать. При этом важны границы модуля и зависимости, а не экранная архитектура. Прости, VIPER, ты не помогаешь писать тесты, а лишь скрываешь сложность.

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

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

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