Смотрите на Кинопоиске с подпиской 
Условия: clck.ru/FMQND Условия: clck.ru/FMQND. 18+

Разработка приложения на базе сайта

Денис Гордиенко, генеральный директор Bright Mobile, о разработке приложения на базе сайта

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

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

Пример из собственного опыта: не так давно ко мне обратились ребята, у которых есть собственная сеть специализированных сервисов по замене масла. Они работают со всеми моделями и специализируются именно на жидкостях (в основном это масло, но и другие жидкости они меняют тоже). Представлены они в нескольких городах, рабочую схему их сервиса можно изобразить следующим образом:

  • Имеется сайт, на который приходят посетители;
  • После регистрации им доступны личный кабинет, карточка клиента, заказ каких-либо услуг;
  • во внутреннем контуре есть 1С, в которую от клиентов улетают заявки, где они затем успешно обрабатываются;
  • часть данных возвращается от 1С в виде просмотра записей, данных о следующей замене и тд.

В общем, ничего необычного: всё плюс-минус как в тривиальном интернет-магазине, только вместо товаров – услуги, и на станцию нужно записываться. А теперь перед ними встал вопрос разработки мобильного приложения.

Типовой подход

Классический подход программистов к разработке выглядит так:

  • Сначала делается некая серверная часть,
  • К ней прикручивается админка,
  • С сервера идёт интеграция с внутренней ERP (в данном случае – с 1С);
  • Только потом к этому бекенду делается сайт и мобильное приложение

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

Однако не всегда всё так гладко: в примере выше сайт и серверная часть совмещены. Они работают на 1С-Битрикс: раньше у них был просто корпоративный сайт, а потом он был развит до сервиса с личным кабинетом. Получается, чтоб сделать всё по хорошему, нужно снести то что наделали за несколько лет предыдущие программисты и с нуля сделать так, как правильно.

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

Нюансы бизнес-подхода

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

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

Добавление «на живую»

Мы выбрали ситуацию, когда со стороны сайта дописывается блок необходимых модулей, и вся эта штука общается с приложением через REST API. С 1С приложение мы не цепляем, используя то, что уже сделали штатные разработчики клиента: мы изменяем текущую систему по минимуму, чтобы они и дальше могли адекватно поддерживать собственную инфраструктуру. Что-то для работы приложения всё равно нужно будет переписать, но не больше 5% от всего объёма инфраструктуры.

Серверная часть будет заключаться только в том, что мы дописываем отдельным модулем REST API к их текущей инфраструктуре и необходимые дополнения, которых на сафте нет. Таким образом мы убиваем сразу двух зайцев:

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

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

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

Частная история выше – типичный пример того, как из классического корпоративного сайта бизнес вырастает сначала в подобие автоматического сервиса, а затем из него вылупляется мобильное приложение с набором нужных клиенту функций. Очень часто допускается ошибка, когда всё прежнее рушится и отстраивается заново. От новых ошибок это не уберегает, зато увеличивает сроки и расходы.

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

0
54 комментария
Написать комментарий...
Айгиз Мухамедьянов

А чем вам PWA не подходит? Тем более ios и андройд принимают такие приложения в сторы.

Ответить
Развернуть ветку
Дмитрий Скрябин

За PWA они не получат столько же денег

Ответить
Развернуть ветку
Роман Г.

AppStore pwa не пропускает

Ответить
Развернуть ветку
5 комментариев
Илья Чирков

Ну да, только они не будут работать так же плавно и удобно для пользователя, как нативные приложения.

Ответить
Развернуть ветку
1 комментарий
Andrey Gordeev

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

Ответить
Развернуть ветку
Стерлядка Вяленая

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

Ответить
Развернуть ветку
Ilya Krylov

В описанном кейсе лучше адаптировать сайт, чем пилить приложение. Чтобы клиент поставил приложение на телефон в 2к22, это должно очевидную выгоду для него принести. Ради "раз в год" купить/поменять масло ставить целое приложение, вы серьёзно? 🙂

Ответить
Развернуть ветку
Ilya Krylov

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

Ответить
Развернуть ветку
1 комментарий
Константин Калинин

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

Ответить
Развернуть ветку
Legion Comander

Если бы люди не брали помойку на битрикс таких проблем в принципе бы не возникало.
Вот в Wordpress из коробки уже идет встроенное REST API, и WP бесплатен, но люди почему то предпочитают платить бабло за убожество под названием Битрикс, наивно полагая, что в ней есть интеграция с системой товаро-учета от 1с.
Полагают они наверное потому что Битрикс имеет префикс 1с, то есть 1С-Битрикс, а соответственно интеграция там должна быть, только вот на практике такое реализовать практически невозможно, нужен программист в штат который будет заниматься обновлением как конфигурации 1с так и сайта.
Причем даже в таком случае обмен будет типовым, читай никаким, потому что типовой обмен сколько я не работал с битриксом ни одному бизнесу не подходит.
А следовательно CMS битрикс это самый большой развод людей который я видел)
Платить, деньги за то, что можно взять бесплатно и получить при этом больше.

Ответить
Развернуть ветку
Михаил Золотов

Дико плюсую, у меня первые заказчики на интеграцию сайта с 1С как раз и объясняли что выбрали битрикс из-за интеграции с 1С "в коробке". Затем пошла волна: у Васьки такой же ИМ и у него Битрикс, сделаю так же!

Ответить
Развернуть ветку
Водный спрей

Всё так. И плагины с темами можно подкупить на 50-100 баксов и слепить из Вордпресса вообще что-угодно

Ответить
Развернуть ветку
Олег

100% согласен. Битрекс стал таким популярный за хороший откат веб-мастерам в 40 или 50% , который они назвали партнерская программ. Когда с конской цены 70К+ за лицензию тебе отстегивают почти половину, то сиюминутная жадность часто перевешивает здравый смысл, что тебе потом придется с этим любиться без смазки.

Ответить
Развернуть ветку
Dmitriy

А нужны ли такие приложения? Чтобы раз в пол года зайти в него.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

да

Ответить
Развернуть ветку
3 комментария
Валентин Потапов

Что есть в мобильном приложении, что нельзя сделать на сайте ? На примере сервиса замены масла, например.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Например, пуши, p2p-доступ к камере, геотрекинг и навигация до ближайшего СТО.

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

Ответить
Развернуть ветку
4 комментария
Олег Пиняев

вот я тоже поддерживаю, не проще ли внедрить в сайт адаптивный дизайн, пуши, датчики и камера и точно не нужны

Ответить
Развернуть ветку
15 комментариев
Стерлядка Вяленая

Зачем им приложение? ОМГ, раскрутили ребят на ненужную фигню. Их приложение кроме дирика толком никто качать не будет. Большинство не забивает телефон бесполезной фигней, а скачивают только те приложения, которыми каждую неделю пользуются. И нафига вообще нужно приложение для сайта с услугой, когда можно зайти на сайт?! Дирик думает, что люди ленивы - сайт в закладки не добавят, зато приложуху скачают 100500% ?

Ответить
Развернуть ветку
Ivan Matveev

Какая польза в статье с бизнесовой / технической стороны вопроса, серьезно? Попиарить свою контору?

К тому же автор очень токсичный и не может адекватно воспринимать не только критику, но и вопросы читателей.

Ответить
Развернуть ветку
insighter
В среднем по рынку это обходится в полтора-два миллиона, а по времени занимает около года с учётом тестирования и отладки

Поделил 1,5 млн на 12 получилось 125тыс в месяц. Не маловато ли?

Ответить
Развернуть ветку
Денис Гордиенко
Автор

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

Ответить
Развернуть ветку
Константин Калинин

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

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

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

Ответить
Развернуть ветку
О Де Колоныч

"Чаще всего программисты настаивают на том, что прежнюю схему нужно забыть и отстраивать всё заново, обосновывая предыдущими костылями и необходимостью рефакторинга, с учётом новых задач. В среднем по рынку это обходится в полтора-два миллиона, а по времени занимает около года с учётом тестирования и отладки."
Имеется ввиду именно полная перестройка фронтенда?
Это реальные деньги? Выше говорилось, что 125 в месяц. Но я о совокупной цене.

Ответить
Развернуть ветку
Константин Калинин

В статье написано примерно следующее.

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

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

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

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

Ответить
Развернуть ветку
Читать все 54 комментария
null