Через тернии к ATM

Дима Королев, разработчик Tinkoff.ru
email: dima@korolev.dk
github: /dmitry-korolev
telegram: @dimakorolev

SPA

Особенности

Один клиент

Одно разрешение

Один интерфейс

Один браузер

Одна версия

Power over 9000

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

Минусы

v23

Кастом

ES5

Шрифты

Debug

Утечки

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

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

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

API

События

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

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

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

React + redux + react-router

Проблемы

Связанность

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

Казалось бы, очевидная вещь, разжеванная уже миллион раз: нельзя держать бизнес-логику на уровне view.

Так код проще тестировать, его проще делить на отдельные модули, впоследствии будет проще мигрировать ну другие технологии.

Но... это было не про проект UI.

Подписчики

Во-вторых, обилие подписок на события.

Как я уже сказал, практически всё общение с API происходит через события.

И в итоге подписки сидели на подписках и подписками погоняли. Подписки на события делались в конструкторе, в componentDidMount, в других подписках, в рендере.

Говорить о том, когда оно всё отписывалось, вообще страшно.

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

WTF/min

Рефакторинг

Таким образом, я подвожу к главной проблеме.

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

И главная проблема состояла в том, что приложение УЖЕ было, УЖЕ хоть как-то работало и УЖЕ, хоть и постоянно падая, вываливая тонны ошибок, могло проводить какие-то операции. Это означало, что возможности начать с нуля нет, нужно работать с тем, что есть, править баги, переписывать отдельные сценарии и так далее.

Оставалось только постепенно проводить рефакторинг, приводя приложение в приличный вид.

К чему пришли

4R

RxJS

Контроль над событиями

Абстракция

Бизнес-логика

Redux-observable

Понятность

Упрощение

Минусы

Сложнее дебаггинг

Сложнее для понимания

Typescript

Проект был полностью переписан на typescript.

Помимо решения тех проблем, которые обычно решаются переходом на типизированные языки (уменьшение количества ошибок, вызванных опечатками или незнанием API, статический анализ кода, повышающий удобство работы в IDE и редакторах), здесь ставилась еще одна цель - облегчить общение с API терминала.

Не могу сказать, что переход был на 100% оправдан, но значительное количество ошибок было выловлено и исправлено именно благодаря типизации.

Верстка

Emotion

Компоненты

Изоляция

Общий код

Минусы?

Проблемы со статикой

Раздувание JS

Медленней, чем CSS

ННЖН

Выбор

Контроль

Стабильность

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

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

Сейчас в случае с проблемами с банкоматами в 99% случаев команда UI может с уверенностью сказать "это не мы".

Мораль

Думай

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

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

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

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

Изучай

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

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

Но крайне важно знать, иметь представление о том, что происходит.

Какие подходы набирают популярность, и почему. Какие подходы теряют популярность - и почему.

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

Спрашивай

Веб-версия доклада: https://clck.ru/DJ5CY
email: dima@korolev.dk
github: /dmitry-korolev
telegram: @dimakorolev