Один день в Альфа-Банке: мобильная разработка
Альфа-Банк стал одним из первопроходцев мобильного банкинга: приложения для iOS и Android появились у него ещё в 2010-м, когда возможность «пополнить баланс телефона с самого телефона» была непривычной. А как обстоят дела с мобильной разработкой в банке теперь, спустя все эти годы?
Ранее мы публиковали текст «Один день в Альфа-Банке: Java-разработка», а теперь наконец пришло время продолжения, где мы расспросили про работу над iOS- и Android-приложениями. Ответили нам Илья Царев и Антон Пухонин. Если написать их имена как iLya и Anton, сразу становится ясно, кто за что отвечает в компании!
— Когда в 2010-м хабраюзер сообщил о появлении у Альфа-Банка Android-приложения, он написал «Исследование рынка на предмет необходимости такого приложения заняло более полугода». С тех пор мобильный банкинг стал настолько неотъемлемой частью жизни, что сегодня эти слова звучат забавно. А как это изменение мира сказывается на мобильной разработке? Вы работаете над приложениями Альфа-Банка не с самого начала, но последние годы застали — что за эти годы изменилось?
Антон: Во-первых, скорость: сейчас нужно быстро пилить, быстро выпускать, много функциональности затаскивать именно в мобилку.
А второе — то, что теперь mobile first и даже mobile only. В приложении теперь должно быть всё, даже малоиспользуемое. Года три назад моё личное мнение было таким: в мобильном приложении нужны те функции, которыми ты пользуешься минимум раз в месяц. Если реже — иди на сайт зайди, и всё будет хорошо. Что-то используется раз в несколько лет, например, активация карты. Раньше я бы точно сказал: зачем это нужно в приложении? Откройте сайт.
Илья: В банкомат вставьте.
Антон: В банкомат как-то совсем уж днище! В общем, сейчас это так уже не работает, нужно добавлять в мобильное приложение.
Чтобы как можно быстрее разрабатывать такие редко используемые фичи и меньше времени тратить на их поддержание, всё чаще в приложениях появляется WebView. В разделе «активация карты», куда пользователь заходит раз в пять лет, ему не нужны красивые анимации и безупречно отточенный интерфейс. Он может ткнуть один раз на кнопку и забыть об этом. И если мы разрабатываем эту фичу не в нативе, а в WebView, мы получаем ускорение разработки, потому что это уже реализовано на сайте, и скорость обновления, потому что можем обновить что-то буквально за несколько минут. Это сильно повлияло на нашу работу.
На жизнь JavaScript-разработчиков, конечно, тоже повлияло. Раньше верстаешь экран и не паришься про мобилку, а теперь знаешь, что сайт наверняка будут открывать на смартфоне, нужна адаптивная вёрстка, а ещё есть нативное приложение, изволь быть похожим на него внутри мобайла. Они подстраивали под нас CSS.
— Прозвучали слова «mobile only» — бывает ли, что в Альфа-Мобайл фичу добавляют, а на сайт нет?
Антон: Такого мало, но есть. Например, в случае с affluent (5% самых богатых клиентов банка) есть бонусы при выполнении определённых условий (иметь на счету денег больше суммы X, совершить в месяц операций на сумму больше Y), и определённая связанная с этим функциональность доступна только на мобильных.
— Снова вспомню пост 2010-го о появлении Android-приложения. Я тогда в комментариях неприятно удивился его размеру в 29 мегабайт: в те времена Android-пользователям приходилось считать каждый мегабайт, и типичное приложение весило куда меньше. Сейчас вроде бы другие времена, даже в недорогих смартфонах десятки гигабайт, но всё равно появляются посты «почему приложение Facebook такое большое, это безумие». Поэтому интересно сравнить:, а сколько весят ваши приложения сейчас?
Илья: У нас на iOS 66 мегабайт.
Антон: У нас около 40, плюс-минус пять.
— А является ли сейчас размер для вас сколько-нибудь насущной проблемой? Растёт ли он со временем, приходится ли предпринимать усилия для его уменьшения?
Антон: Размер Android-приложения не особенно увеличивается. Объём кода растёт, добавляются какие-то библиотеки, но за последние два года приложение только уменьшилось. Google представил VectorDrawable, ресурсы стали храниться не в PNG-шках в 4 размерах, а просто векторным рисунком, который весит считанные килобайты. Никакого мыла в приложении не видно в UI. Сейчас из больших картинок в мобильном приложении, по-моему, только пара бэкграундов. Всё остальное тянется с бэкенда по мере необходимости.
Илья: Я сейчас открыл App Store — он пишет, что приложение весит 90 мегабайт, но это распакованная версия, столько места займёт после установки. То, что скачивается, на момент моего прихода в Альфу весило 60 мегабайт, сейчас 66. Из-за чего выросло? Отчасти из-за Swift, которого раньше не было. Кроме того ресурсы, да…
Но, например, у меня на айфоне 12 гигабайт трафика в месяц. Мне кажется, это не очень актуальная проблема.
Антон: Для Москвы.
Илья: У нас распределение пользователей с очень большим уклоном в Москву.
В общем, мы не делаем ничего радикального для уменьшения приложения, да и вряд ли особо что-то сделаешь. Все PNG«шки пожали, и постоянно рефакторим код, убираем лишнее. Но даже если уберёшь 100 файлов кода, уйдёт максимум один мегабайт, и это если повезёт. То есть все простые вещи уже были сделаны. Новые делаем по мере необходимости.
Сейчас в App Store ограничение на 150 мегабайт при загрузке по мобильной сети, мы нормально проходим, проблем нет. Вот Facebook действительно весит около 200 мегабайт, а в распакованном виде 400. У них там очень много библиотек, всяких штук, и при этом они ещё и релизятся очень часто. Я читал один занятный пост про размеры. Там человек писал про апдейты приложений «почему я должен каждую неделю выкачивать 300 мегабайт, вы с ума сошли». Но, кажется, мы все идём в эту историю, все компании стараются чаще релизить, чаще вносить какое-то value, и это круто.
Антон: Я тем временем посмотрел точный размер Android-версии: сейчас весит 42,26 мегабайт. В принципе, мы к уменьшению размера стремимся по мере возможностей. Все ресурсы, которые занимают много места, вычищаем, переводим всё либо в вектор, либо в отрисовку в коде, либо в подгрузку с бэкенда.
Но это как работа над общим качеством кода, приложения. Если бы стояла именно задача «урезать приложение до минимума», мы бы взялись и урезали ещё сильнее. Но зачем искать себе лишнюю работу там, где от неё будет мало результата? В продуктовых метриках кажется, что даже если мы сократим приложение с 40 мегабайт до 10, это принесёт продукту небольшое value. Лучше потратить время на оптимизацию загрузок, скорость работы, красивые анимации — это будет лучше для пользователя. Ну, это моё субъективное мнение.
— Для пользователей очень заметны поддержка банком Apple Pay и Google Pay, но это история не про мобильное приложение банка. Когда внедряется их поддержка, требуются ли при этом вообще мобильные разработчики, и насколько велика их роль?
Антон: Если нужно просто добавить для банка оплату Apple Pay/Google Pay, то привлекать мобильщиков и вообще фронт не требуется. Но если хочешь сделать хорошо, тогда они понадобятся.
Илья: Хорошо — это, например, про то, что у нас из приложения можно приостановить действие любой цифровой карты. Там есть список устройств, где работает Apple Pay и Google Pay, можно поставить на паузу или удалить привязку к ним из приложения.
Антон: Но вообще на фронте работа минимальная. Даже если ставить задачу-максимум и вдумчиво читать документацию, делается за 2–3 недели. Основная работа ложится на процессинг — подружить терминалы, договориться с Mastercard и Visa. Каждая привязка карты — это, по сути, новая виртуальная карточка. Для неё выделяется новый идентификатор, и все проблемы где-то там в кишочках. А нам надо просто подружиться с приложением Apple Pay или Google Pay.
Илья: Ну и Apple или Google должны разрешить это сделать.
— Со словом «банк» ассоциируется «безопасность», а как это сказывается на мобильной разработке? Например, не оказывается ли, что вся работа должна вестись исключительно в пределах офиса?
Илья: Для всех разработчиков есть VPN, который подключается к нашей внутренней сети, так что работать над приложениями возможно из любой точки мира, доступ есть. Есть логины-пароли, сертификаты на ноутбуках, если произойдёт утеря устройства, можно просто заблокировать всё. А вообще, поскольку у мобильных разработчиков нет доступа ни на какие боевые сервера, то и риски ниже.
Антон: Если говорить про безопасность мобильного приложения, то большинство уязвимостей закрываются на уровне API: все операции подтверждаются одноразовыми паролями, приходящими по SMS, настроены фильтры для блокирования подозрительных операций. При минимальных подозрениях на мошенничество операция блокируется, и клиенту звонит оператор call-центра. Взаимодействие с сервером идёт по зашифрованному каналу, реализована проверка сертификатов.
— Ещё банки ассоциируются с консервативностью. Насколько легко в мобильном используете новое (например, как в вашем случае выглядит миграция на Swift) или нестандартное?
Илья: Мы последние полтора года пишем на Swift, начали с 2.3, теперь на четвёртом. На новые и необычные технологии смотрим открыто, запретов нет. Из любопытного, наверное, можно назвать то, что с UI работаем только через код и используем для этого SnapKit.
Антон: Да, запретов нет, а есть общее внутреннее комьюнити разработчиков. Если ты доказываешь, что твоя технология перспективна, нужна и реально полезна, то использовать ее начинают всё.
Но тут надо понимать, что проекту Альфа-Мобайл много лет, там большой хвост функциональности и легаси. Многое переписано, конечно, но остаётся и старое. И когда много человек толкают проект вперёд, то… Когда говоришь «ваше MVP сегодня уже не модно, давайте внедрим стильное-модное-молодёжное MVRx», задают логичный вопрос: «Чувак, вот ты сейчас свою новую архитектуру применишь, что мы будем делать с остальным? Нам придётся поддерживать две архитектуры независимо». И если дальше каждый будет тащить что хочет, то жить с этим будет всё сложнее и сложнее.
Если ты доказываешь, грубо говоря, что переход с AsyncTask на Rx того стоит, то разрабатываем план, как мы это внедряем, как рефакторим старое, чтобы не тянуть за собой 2–3–4 подхода.
Илья: То есть всё работает через комьюнити. Комьюнити принимает — значит, пошли.
— А бывает ли, что комьюнити оказывается раздроблено на два лагеря?
Илья: Бывает. Тогда конечное решение принимает лид.
Антон: У нас тоже такое бывало. Например, с написанием юнит-тестов. У нас два приложения, для физических лиц и для юридических. Когда мы думали, как лучше писать тесты, половина сказала «давайте писать тесты на Kotlin» (это было где-то год назад), а половина сказала «Kotlin — это хорошо, но писать Kotlin на чистом JUnit скучно, слишком много кода, давайте мы притащим Spock и Groovy».
Посмотрели на Spock и Groovy, половина сказала «классно, давайте так писать». А другая половина сказала, что замыкания в Groovy — это что-то за гранью разумного, и давайте писать на Kotlin. А в результате сейчас у нас в одном приложении тесты пишутся на Kotlin, а в другом на Groovy.
— Насколько у вас синхронизирована работа iOS и Android? Новые фичи появляются одновременно на обеих платформах?
Илья: Мы работаем по скраму, поэтому каждая команда — небольшой стартап с участниками на всех слоях, и новую фичу она делает тоже сразу на всех слоях. Соответственно, обычно функциональность бывает готова примерно одинаково. Может быть небольшой рассинхрон по выходу версий: например, релиз на Android раньше, и фича выйдет чуть раньше. Большие изменения типа редизайна мы, конечно, вместе делаем.
— Ваши приложения установлены на миллионы смартфонов, как сказываются такие масштабы? Например, приходится ли возиться с экзотикой вроде странно ведущих себя малоизвестных смартфонов? Оказывается ли, что даже очень редкие проблемы вызывают у кого-то негативную реакцию и требуют исправления?
Илья: Да, всегда, когда ты думаешь «вот такого кейса точно не будет», он будет 100%. Когда я только устроился работать, через месяц возник такой случай, когда мы подумали «никого не будет», и, конечно, на огромной пользовательской базе всё это вылезло, и пришлось править. Да, такие кейсы всегда есть. Поэтому для нас особенно важно тестирование: и юнит-тесты в коде, которые проверяют свою бизнес-логику (включая какие-то граничные случаи), и UI-тесты, которые автоматически проверяют, что бизнес-сценарии отрабатывают, и приёмочное тестирование, где тестировщик проверяет, что вёрстка нигде не вылезла и всё окей, и регрессионное, когда проверяют приложение на неухудшение функциональности руками.
Антон: По поводу экзотических смартфонов: в iOS всё понятно, база девайсов не очень большая, а Android — это зоопарк устройств. Несмотря на то, что основные баги в приложении пофикшены, иногда на китайских no-name девайсах происходит какой-то необъяснимый космос. и приложение падает.
Иногда падает сам Android, с этим мы мало что можем сделать. Иногда подводят модифицированные прошивки производителей устройств. Решаем подобные проблемы тривиально: ищем такой девайс и выясняем, в чём причина дефекта. «Ребята, у кого в Москве есть такой-то девайс, давайте потестируем на нём» — нередкие сообщения в наших корпоративных чатах.
Пару лет назад был случай, когда с одного девайса в Play Store были одинаковые отзывы «не работает», ничего не было понятно, и тогда мы пошли в магазин — «А можно нам посмотреть этот смартфон?» Нам его достали, мы делали вид, что в течение 30 минут решаем, покупать ли этот девайс за условную тысячу рублей, а самом деле поставили специальную сборку приложения, нашли причину падения, пришли в офис, пофиксили, перезалили. Там проблема была связана с разрешением: девайс был большой, а разрешение какое-то прямо очень маленькое.
— К «иногда падает сам Android»:, а ощущаете ли какую-то боль c его стороны? Например, Google может взять и режимом Doze ограничить приложения — по вам это бьёт?
Антон: Скажем так, начать стоит с того, что Google представляет всё заранее: и описывает изменения, и на I/O рассказывает, и заранее выпускает новые версии для разработчиков. И всё критичное мы стараемся закрывать заранее.
Иногда это требует усилий. Когда появились runtime permissions, это доставило много боли, пришлось посидеть недельку или даже больше, отловить в приложении все случаи. Но если ты следишь за новостями, то у тебя не возникнет внезапных проблем в момент релиза.
А проблемы с Android в целом… Ну, например, в прошлом году мы вынужденно отказались от поддержки Android 4.0. Почему? На очень многих девайсах падало WebView. Там тупо не было AsyncTask, система не могла найти такого класса. Мы посмотрели, какие варианты решения есть, и нам ничего не подошло, у нас важная функциональность была реализована с помощью WebView.
Нужно было что-то делать, и мы решили, что лучше оставить пользователей с версией ниже 4.1 (их тогда было 2–2.5%) на текущей версии, и дальше апдейты выходили только для 98%.
— В презентациях новых версий iOS/Android можно увидеть эффектные штуки вроде ARKit, но дополненная реальность — это явно не про вас. Когда выходит новая версия, насколько это на вас сказывается?
Илья: Ну как раз дополненная реальность вообще-то про нас! Вот сейчас запущу у себя на айфоне и покажу, у нас можно банкомат искать в дополненной реальности, водя смартфоном вокруг. Это давно сделано, ещё не на ARKit, конечно.
А вообще про обновления iOS — вот когда с iOS 6 на iOS 7 переходили и полностью переделали интерфейс, тогда сломалось вообще всё, что можно было. Я тогда ещё не в Альфе работал, но в другом проекте мы месяца два переходили, это был ужас. А после этого всё полегче. В iOS 11 кажется, ничего кардинально для нас не поменялось, хотя Apple сделал очень много внутри, например, свою файловую систему — это же вообще классно. Кстати, у меня после обновления все фотографии из телефона стёрлись. Хорошо, что бэкапы остались, потом подгрузились.
Так что из нововведений iOS 11 для нас немногое актуально. Понятно, что мы используем технические штуки: переходим на новые версии Swift, Xcode. Это нормальный процесс, такого, чтобы всё поломалось, там нет. Даже с выходом третьего Swift, когда в индустрии было слышно много стонов.
Антон: Вот последний апдейт Android не очень сильно сказался на пользователях, но реально сильно сказался как раз на разработчиках. Там представили много чего архитектурного, мы сразу стали присматриваться и думать — например, новый функционал решили делать на Room, это база данных, которую представил Google. И Android Architecture Components тоже сразу заинтересовали, хотя изначально и были слишком сырыми, чтобы мы готовы были смело использовать.
А из нового для пользователя — Instant Apps классная штука, на которую мы тоже обратили внимание, но не стали спешить внедрять ее. Хочется, чтобы любой раздел приложения можно было запустить через Instant App, а это требует глубокого рефакторинга всего приложения. В масштабах приложения Альфа-Мобайл это очень сложно и занимает много времени. Надеюсь, в 2018 году нам удастся это реализовать.
— В iOS 11 добавили ещё и CoreML, насколько для вас актуально машинное обучение?
Илья: CoreML в том виде, в каком он сейчас, мне кажется, мало актуален. Он не умеет дообучать модели, только использовать готовые. Было бы круто, если можно было модель дообучать на конкретного пользователя, который пользуется именно этим девайсом. Например, все оплачивают мобильный телефон на 500 рублей, а он оплачивает на 50. А мы сейчас ему suggest даём на 500, потому что все на 500 оплачивают. Было бы лучше на 50.
На бэкенде это для нас актуальнее. Например, предсказывать, какие транзакции будут у пользователя. Если у него есть какие-то регулярные траты, например, каждый месяц оплачивает коммунальные услуги, можно предсказать с определённой вероятностью, что в следующем месяце они тоже будут, предзаполнить данные, и прислать уведомление. Мы сейчас развиваем это направление.
— По нашей конференции Mobius мы видим, что в мобильном мире сейчас очень много говорят об архитектуре. С чем вы это связываете, и что сейчас с этим у вас?
Илья: Мне кажется, что мобильные проекты и стартапы, которые остались живы и стали успешными, сейчас уже выросли. У них есть много легаси и много разработчиков. Поэтому в какой-то момент всем стало понятно, что на MVC мы уже не выживем. Что-то идёт не так. Мы не можем это поддерживать. Надо что-то переделывать. И поэтому всё чаще и чаще это стало мелькать.
У нас похожая история. Конечно, когда у нас стало много легаси и много разработчиков на проекте, мы уже не можем писать на MVC, потому что будем месяц делать элементарную фичу. Конечно, начали думать про тесты, про переиспользуемость, про то, как это всё сделать читаемым и поддерживаемым.
Мы прошли путь, когда у нас сначала был MVC и два человека, потом нас стало трое, и мы пришли к MVVM. И вроде хорошо жили, пока не стало десять. А после этого мы поняли, что MVVM каждый видит по-своему, и начали спорить из-за того, кто как делает его. Поняли, что надо делать что-то другое, а вариантов на рынке, на самом деле, не так много. И когда слушали на Mobius доклады по архитектуре, там везде звучало «не факт, что вам нужно именно то или это, подумайте, что вам нужно, и сделайте что-то конкретно для себя, исходя из этих требований».
Мы так и сделали. Взяли MVVM, взяли VIPER, нашли статью по Clean Swift, подумали: «Тоже интересная тема, давайте попробуем». Сели и за неделю написали один и тот же модуль на разных архитектурах. Потом сели и вместе обсудили: вот смотрите, у нас есть кусок на MVVM. Что нам в нём нравится, а что не нравится? Есть на VIPER кусок, что в нём? Это был один и тот же код, одна и та же функциональность.
Решили, что в нашем случае будет хорошо взять Clean Architecture и адаптировать его под себя, а в итоге сделали то, что назвали «Yet another architecture». И, кажется, он хорошо заходит. Мы, конечно, сразу пошли рассказывать про него на митапе, потому что хайп, ещё одна архитектура, все такие «ооо, а убьёт VIPER или нет». Про «убьёт», конечно, посмотрим, мы не ставили себе такой цели. Просто предложили альтернативу.
Антон: Да, моё мнение похоже. Android был представлен в 2008-м. Начали создаваться маленькие приложения. Резкий рост разработки — наверное, 2010-й. И потихоньку начали расти команды, приложения, mobile-only тенденции. Когда команда разрастается до 5 человек, необходимо вводить стандарты, для того чтобы приложение не развалилось на части, его можно было поддерживать и эффективно дорабатывать.
У Google была, как мне кажется, не промашка, но недоработка: не обращали внимание на отсутствие ярко выраженной архитектуры. Были всякие инструменты, IDE, SDK, а архитектуры не было.
В 2010-м на Google I/O сотрудник Google Вёрджил Добжански описывал три паттерна, три подхода к разработке андроид-приложений. Когда мне впервые в жизни доверили разработку с нуля, я попробовал так, иначе — что-то не заходит, нужно думать, как организовать. Стал гуглить про архитектуры — она тогда была одна, три подхода от Добжанского. Начал применять. Всё было хорошо, но получалась огромная портянка кода, огромное количество классов, которые очень многословно решают какую-то очень маленькую проблему. Видимо, с этой проблемой столкнулся не я один, и умные люди начали пытаться улучшить это, смотреть на аналоги: как это разрабатывается в большой Java в энтерпрайзе, как это делает iOS с VIPER.
Сейчас команды становятся всё больше, поэтому берут стандартные подходы или придумывают что-то своё. И чем больше команда, тем более строгая архитектура нужна. Мне понравилась фраза с последнего митапа Альфа-Банка «Код должен быть обезличенным».
Илья: Ещё важно переиспользование. Это связано с тем, что бизнес говорит «быстрее-быстрее-быстрее», конкуренция растёт и многие компании идут в мобильную разработку. Если у тебя сейчас нет мобильного приложения — это странно. Нужно, чтобы было быстро и поддерживаемо, а это приводит к соответствующим стандартам.
— У нас вопросы закончились, хочется ли вам ещё добавить что-то от себя о мобильной разработке в Альфе?
Илья: Хочу рассказать немного про команду. Мы полностью независимы. Мы сами настраиваем себе CI, сами можем поднять любой сервер, подключить Grafana и многое другое. Нам не нужно ещё пять команд DevOps-инженеров, чтобы что-то настроить. Максимум, что нам надо от других — получать доступы, но это достаточно формализовано: письмо отправил — выдали доступы.
Разработчики учатся очень многому. И архитектуре, и тому, как вообще нужно писать код, если это джуниор-разработчики, и тому, как работать в команде, брать на себя ответственность, пилить какие-то дополнительные штуки. У нас вот пришёл один андроид-разработчик и переделал пол-CI…
Антон: «У нас» или «у вас»?
Илья: Ну… в любом случае, это мобильные разработчики, которые умеют делать CI! Это круто. Не везде так.
Антон: А я немножко в другом ключе расскажу. Когда приходит Android-разработчик на собеседование, я у него всегда спрашиваю: «А тебе вообще интересно будет с нами работать? Какие задачи ты хочешь решать?»
Кто-то говорит: «Хочу продуктовые фичи фигачить, чтобы зашёл в приложение и сразу увидел результат своей работы». Кто-то говорит: «Я хочу что-то корневое пилить, на C, под Андроид, чтобы всё было супероптимально». И тут приходится вторых разочаровать, что таких задач у нас практически нет. Тебе присылают образец JSON, который должен приходить, ты его вставляешь в нужное место, пишешь тесты, делаешь всё остальное. От вёрстки многое зависит, бывает сложная, бывает простая. Но всё это в среднем занимает немного времени, и редко попадается какая-то нетривиальная задача.
Самые интересные и сложные задачи у нас сейчас в другой области — в области масштабирования. У нас растёт число мобильных разработчиков. И вот как заставить 20 человек работать так, чтобы код не деградировал, был поддерживаемый, количество багов не росло, скорость разработки не снижалась? И для этого у нас делается очень многое.
Допустим, по CI. Раньше у нас стоял один Mac Pro, на нём делали сборки. Через некоторое время нам стало его не хватать. В пятницу все заканчивают спринты, стартует огромное количество сборок, и твоя сборка может в очереди час простоять, а то и больше. Поэтому мы решили Android-командой все сборки перевести на сервера в облачные сервисы. А чтобы сделать это, завернуть инфраструктуру в Docker-контейнер. И использовать Jenkins-пайплайны. В мире Android не очень много времени уделяют DevOps. А нам это реально нужно, и туда было брошено много сил.
Также очень много задач по тестированию. У нас действует принцип «каждый сам покрывает свой код тестами». Но есть люди, которые работают с тестами немного глубже. Они занимаются изучением и интеграцией новых фреймворков: Spock, Spek, Espresso. Они автоматизируют запуск тестов и проверку покрытия кода тестами. Одним словом, делают всё, чтобы остальные писали тесты эффективно.
Не меньшее внимание мы уделяем архитектуре, развиваем библиотеку визуальных компонентов. Что нам даёт такая библиотека? Дизайнер нам отдаёт не полностью готовый макет, который отточен до пикселя, а просто mockup экрана — здесь синяя кнопка, здесь большой заголовок, здесь средний заголовок, там жёлтая звёздочка. Отступы описаны в библиотеке компонентов, цвета, шрифты и всё такое. То есть работа дизайнера сокращена, работа разработчика сокращена, время отладки, дизайн-ревью тоже очень сильно сокращён, глупых ошибок в пол-пикселя не может быть в принципе.
— Спасибо вам обоим за ответы!
Мы скоро проводим новый Mobius, и Альфа-Банк стал его спонсором. А это значит, что если у вас остались вопросы по мобильной разработке в этой компании, то на конференции будет кому их задать!
