Разработка UI для банкоматов

Дима Королев, Tinkoff.ru

Зачем?

Снятие и пополнение без ограничений
Самоинкассация для SME
Экономия на комиссиях
Новые каналы связи с клиентами

Имиджевая тема

Требования

Лучший в мире
Быстрая разработка
Быстрые релизы

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

Почему не стандартный банкомат?

Что использовать для GUI?

WPF?
MFC?

Qt?
Web?

Разные устройства

Пять моделей банкоматов и терминалов с разным поведением и устройствами.

Разные устройства

Пять моделей банкоматов и терминалов с разным поведением и устройствами.

Web application

Гибкое и универсальное решение
Уже есть экспертиза

Какой выбрать фреймворк?

React?
Angular?

Устаревший Chromium

Затрудненный дебаг
Странные баги из-за кастомизации

По идее, выбирая фреймворк, нам нужно было отталкиваться от особенностей окружения, в котором пришлось бы работать приложению. Например, учитывать, что в качестве браузера использовался Chromium 23-й версии. Это не так страшно, как 9 IE, но быть ограниченным браузером на тот момент пятилетней выдержки - тоже такое себе удовольствие. В частности, были большие сложности с дебагом. Кроме того, это изрядно кастомизированный chromium, что тоже иногда вызывало странные баги. Часто мы часами искали ошибку только для того, чтобы понять, что проблема была в каких-то несовместимых друг с другом библиотеках, а вовсе не в UI-приложении.

Утечки

Приложение работает постоянно — высокий риск появления утечек памяти.

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

API

Построенный на событиях API для взаимодействия с ATM

Одинаковые клиенты

Ограниченный набор разрешений экрана и одинаковые интерфейсы взаимодействия с клиентом

Да, у нас несколько моделей банкоматов, но с точки зрения верстки ограниченное количество разрешений экрана значительно облегчает работу. Не нужно думать о резиновой верстке, адаптивности. У всех банкоматов — одинаковые, заранее известные методы взаимодействия с пользователем. Никаких скринридеров, мобильных устройств, никакого accessibility, по сути всё взаимодействие с интерфейсом ограничивается тачскрином и пинпадом.

Универсальное и одинаковое ПО

Современная аппаратная основа

Клиентский рендер

React

Как работаем с CSS?

Static CSS?
Sass/less?

CSS-модули?
CSS-in-JS?

Emotion

Плюсы

Компонентный подход
Изоляция стилей
Динамика

Минусы

Отсутствие статики
Раздувание JS
Медленней, чем CSS

Минусы тоже есть, разумеется. Какие-то - специфические для конкретных библиотек, какие-то общие для всех. У каких-то библиотек есть проблемы с сервер-сайдом и выделением CSS в отдельный статический файл. Общая для всех (за редким исключением) CSS-in-JS библиотек проблема - необходимость тащить какой-то js в рантайм. Следствие предыдущих двух пунктов — разумеется, любой подход предполагающий динамическую генерацию стилей в JS будет рабоать по определению медленней, чем статический CSS. Все эти минусы, как я уже говорил, для нас роли не играли, и в общем-то мы не жалеем о своем выборе.

Как управлять состоянием?

Redux?
Mobx?

Redux

Как общаться с API?

redux-thunk?
redux-saga?
redux-observable?

Redux-thunk

API

Построенный на событиях API для взаимодействия с ATM

(простите за повтор)

Сценарий "Платеж наличными":

8 событий сценария
11 асинхронных запросов
События ввода
События ошибок

Например, сценарий "платеж наличными", один из самых простых сценариев, включает в себя помимо событий ошибок и пользовательского ввода, например, нажатия на пинпад или кнопку отмены, присутствующих в каждом сценарии, еще 8 собственных событий и необходимость делать до 11 асинхронных запросов. И мы честно пытались управлять этой какофонией через асинхронные экшены redux-thunk, при этом непосредственно подписки на события приходилось хранить в страничных компонентах, потому что больше было негде.

Сильное зацепление

Сломали переиспользование
Сломали тестирование

Redux-saga vs.
redux-observable

RxJS

redux-observable

Понятность и управляемость

Минусы

Сложнее дебаггинг и тестирование
Потоки сложны для понимания

Свои минусы у RxJS тоже есть. Во-первых, потоки довольно-таки сложно дебажить и тестировать, и если последнее можно решить за счет грамотного dependency injection, то с дебагом приходилось мучиться, и эту проблему мы до конца не решили. Во-вторых, в потоки нужно вкатываться. Само по себе реактивное программирование может быть не сразу понятно. Но, как показывает практика, это не становится проблемой. Кроме того, как опять же показывает практика, реактивное программирование весьма универсально, и находит широкое применение в вебе, поэтому знания RxJS пригодятся всегда.

Typescript

Попутно мы переехали на typescript. С его помощью мы хотели, во-первых, облегчить общение с API банкомата — оказалось очень удобным один раз описать интерфейсы всех событий и асинхронных методов и перестать постоянно лазать по документации. Еще одна надежда — уменьшить количество ошибок и багов, не была оправдана, потому как большая часть проблем вызывалась сложной бизнес-логикой, а не отсутствием строгой типизации. Тем не менее, работать стало удобнее, и отказываться от TS мы не спешим.

Как будем тестировать?

Юнит-тесты?
Модульные тесты?
E2E-тесты?

Ручное тестирование

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

Юнит-тесты

jest

Автотесты

Эмулятор

Закон Мёрфи

Всё, что может пойти не так, пойдет не так

Если говорить об историях, более приближенных к реальности, вот вам целых две, связанных со вносом наличности, причем регулярно повторяющиеся. На фотографии вы видите купюроприемник. Как вы думаете, что нужно сделать, чтобы положить туда деньги? Правильно, дождаться, когда он откроется. Но зачем? Мы постоянно сталкиваемся с ситуацией, когда клиент пытается запихнуть купюру прямо в щель между корпусом и крышкой купюроприемника. Еще один вариант — дождаться, когда шаттер откроется, исходя из каких-то внутренних убеждений нажать на кнопку возврата на экране или отмены на пинпаде, и успеть закинуть деньги в купюроприёмник до того, как он закроется. Как эти ситуации обходить? Как автоматизировать?

Selenium

autoit

Пытаемся тестировать, если кому интересно, на Selenium с использованием AutoIt для взаимодействия с интерфейсом. Но бизнесу это тоже не очень интересно, потому что текущая скорость доставки новых версий на прод вполне его устраивает. Я уже говорил ранее, что регресс занимает буквально несколько часов. Учитывая, что у нас нет необходимости релизиться чаще, чем раз в две недели, это вполне всех устраивает. Если интересно, в случае необходимости процесс выкладки новой версии на все банкоматы включая регресс и доставку может уложиться в 1 день. Если прям с утреца начать, конечно.

Итоги

Контроль над поведением ATM

Стабильная и быстрая разработка

Удобство для пользователей

Возможность экспериментировать с форматами

Мораль

Думай

Нисколько не сомневаюсь, что никого из здесь присутствующих нельзя обвинить в том, что они не думают перед тем как делать задачу. Но, к сожалению, очень часто бывает так, что разработчик, вольно или невольно, ограничивает себя каким-то инструментарием. Я хочу сказать, что крайне важно думать не только КАК сделать задачу, но и ЧЕМ её делать, и чем больше задача - тем больше внимания нужно уделить именно аспекту выбора инструментов. Нужно помнить, что неправильный выбор инструментария можно повлечь за собой бессмысленную трату сотен и тысяч часов работы. Затраты, которых можно было бы избежать, сделав правильный выбор.

Изучай

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

Спрашивай

Конец

email: dima@korolev.dk
github: /dmitry-korolev
telegram: @dimakorolev

Разработка UI для банкоматов

Дима Королев, Tinkoff.ru

Зачем?

Имиджевая тема

Требования

Почему не стандартный банкомат?

Что использовать для GUI?

Разные устройства

Разные устройства

Web application

Какой выбрать фреймворк?

Устаревший Chromium

Утечки

API

Одинаковые клиенты

Универсальное и одинаковое ПО

Современная аппаратная основа

Клиентский рендер

React

Как работаем с CSS?

Emotion

Плюсы

Минусы

Как управлять состоянием?

Redux

Как общаться с API?

Redux-thunk

API

Сценарий "Платеж наличными":

Сильное зацепление

Redux-saga vs.redux-observable

RxJS

redux-observable

Понятность и управляемость

Минусы

Typescript

Как будем тестировать?

Ручное тестирование

Юнит-тесты

jest

Автотесты

Эмулятор

Закон Мёрфи

Selenium

autoit

Итоги

Контроль над поведением ATM

Стабильная и быстрая разработка

Удобство для пользователей

Возможность экспериментировать с форматами

Мораль

Думай

Изучай

Спрашивай

Конец

Redux-saga vs.
redux-observable