Как переиспользовать код между web и mobile? И зачем мы это сделали?

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

Чтобы такого не происходило, ваш проект должен работать следующим образом:

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

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

Тем не менее, у нас, наконец, получилось исполнить свое желание. Мы попробовали частично переиспользовать код и логику между вебом и мобайлом, так как пишем на React и React Native. При этом внешний вид у каждой платформы остался свой. Если говорить техническим языком, у нас общий Redux Store, поэтому работа с данными ведется из одного места, но на визуальную составляющую это никак не влияет.

Конечно, острые языки вспомнят про React Native Web, который предназначен для написания одного приложения, работающего одинаково хорошо и в браузере, и на мобилках. Мы пытались, но год назад он был еще совсем сырой. Поэтому поступили следующим образом.

На фронте пишется store, который затем юзают на мобайле, или наоборот. Это позволяет сохранить единую логику (для Android, iOs и веба), плюс увеличить скорость разработки.

Со скидками, может, совсем легкий пример. Поэтому расскажу другой. У нас в одном проекте на радость клиентам решили внедрить подарочные сертификаты. Они применяются в корзине. Но, мы должны учесть, что сертификатов может быть несколько, гасить их допустимо частично, нельзя, чтобы появлялись дубли и еще множество других нюансов. Выглядит понятно, на деле — жутковато. Но только не нам. Мы уверены, что, с какого бы устройства клиент не вошел, логика будет одинаковой.

Вносить однотипные изменения в три-четыре разных места в JS-коде — искусство, требующее концентрации внимания и высокого уровня мастерства.

По-моему, уровень качества разработки (и разработчика) демонстрирует его код. И речь не о том, 100к строк он написал и разжевал до мелочей, или решил задачу в 5 строк. Важно, чтобы другой разработчик, пришедший в проект, мог за 15 минут вникнуть и не тратить кучу времени на поиски, что и как тут устроено. Поэтому в крупных проектах желательно писать код так, чтобы его удобно было вынести в отдельные компоненты и переиспользовать.

Основная фишка React Native — это сокращение времени на написание кода за счет его переиспользования между iOs и Android. По словам разработчиков Facebook (создателей языка) это возможно на 87%. А раз сократиться время на написание кода, значит, снизит затраты на проект в целом. Плюсом идет то, что поиск и исправление багов делают в одной версии, а фиксится оно автоматом на двух платформах.

Также React Native экономит клиентский бюджет на поддержке приложения после его релиза, т.к. для обеих платформ нужна всего лишь одна команда. Конечно, далеко не все выбирают кроссплатформенное написание. И очень часто в каких-то крупных корпорациях сидят 2 отдельных команды, которые пилят по сути одну прилагу, но для разных платформ. Серьезный подход. Но нужен ли он вам? Представьте, сколько у ребят планингов, митингов, синков. Представьте, каким управленческим и техническим искусством надо обладать, чтобы протащить одну фичу для релиза через 3 команды (веб, iOs, Android). Тут и вероятность ошибки возрастает в несколько раз. Я как бы не отговариваю, а просто прошу вас задуматься о целесообразности.

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