Имеет ли смысл решать вопрос нагрузки в приложении?

Денис Гордиенко, руководитель Bright Mobile, о нагрузке на примере приложения для оптовых покупателей цветов.

В закладки

Решил рассказать про опыт разработки приложения для оптового дистрибьютора цветов в Краснодаре и вопросе нагрузки на БД. Отличие от большинства «цветочных» приложений в том, что оно сделано не для конечных покупателей, а для розничных продавцов, которые оформляют заказ удалённо, либо приезжая на базу.

Идея приложения

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

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

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

Для рассылок, акций, предложений и новостей предусмотрена новостная лента. Также в приложении имеются история сканирования, где можно посмотреть предыдущие заказы, и меню с прочей информацией о компании: адрес, телефон, ссылки на социальные сети и т.д.

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

Багфикс ленты товаров

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

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

Технологии

Для начала приведу список технологий, на которых делалось приложение:

  • Сборка Ionic.Framework
  • БД FireStore
  • Push — FCM
  • Обмен данных с 1C — Node.JS
  • Авторизация — Firebase Authentication

Кроссплатформенная сборка дала плюсы в скорости и цене разработки. Требования к телефону у бизнес-приложения низкие и переплачивать за натив смысла нет. БД выбрана для работы в режиме реального времени — приложение держит соединение с базой по сокету и моментально получает обновления. Авторизация от Firebase даёт 10 тыс бесплатных СМС, что более чем достаточно для планируемой клиентской базы.

Пропадание списка товаров

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

К слову, у программистов всегда чешутся руки пооптимизировать запросы. Это хорошо, но важно понимать экономическую целесообразность. К примеру, при плановой нагрузке в 200 тыс чтений оплата составит $0,06 за 100 тыс чтений. То есть в сутки $0,09, это $2,7 в месяц.

Выгоднее платить по 167р в мес на платном тарифе, чем дополнительно заложить 40 часов разработчика на кеширование и пакетные запросы. Если ориентироваться на стандартную ставку в 1200р в час, то это добавило бы лишние 48 000р в бюджет.

Когда делать оптимизацию?

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

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

Оставляю за скобками стоимость создания и развёртывания серверной архитектуры. Самый минимальный VDS можно взять примерно за 400р ($6,67) в мес, «нормальный» сервер — в районе 4000р ($66,67) в мес.

Адекватно задумываться об оптимизации было бы на этапе, когда эта самая оптимизация давала значительную выгоду перед арендой собственного сервера. То есть когда количество запросов к БД будет от минимальных 100 000 х $6,67 / $0,06 = 11 111 111 до «нормальных» 100 000 х $66,67 / $0,06 = 111 111 111.

111 миллионов запросов это достаточно абстрактная для бизнеса цифра. Поэтому переведём на заказы. В среднем, на одного пользователя, в этом приложении, чтоб он вдумчиво посидел и оформил корзину нужно 200 запросов к БД. То есть дойдя до платежа в 4000р в мес, клиент получит 10%(средняя конверсия в оплату) х 555 555 = ±55 555 заказов.

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

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Денис Гордиенко", "author_type": "self", "tags": [], "comments": 59, "likes": 13, "favorites": 48, "is_advertisement": false, "subsite_label": "life", "id": 103048, "is_wide": false, "is_ugc": true, "date": "Sat, 25 Jan 2020 18:24:32 +0300", "is_special": false }
Создать объявление на vc.ru
Право
Семь настоящих причин зарегистрировать товарный знак в России
Хорошее название помогает компании защититься от подделок, покорить рынок и выйти за рубеж. Плохое может её обанкротить.
(function(d, ver) { var s = d.createElement('script'); s.src = 'https://specials-f378ef5.gcdn.co/Covid19Quiz/all.min.js?' + ver; s.async = true; var container = d.getElementById('covid-quiz'); if (container) { s.onload = function() { new Covid19Quiz.Special({ css: 'https://specials-f378ef5.gcdn.co/Covid19Quiz/all.min.css?' + ver, container: container, location: 'article', share: { url: '', title: '', } }); }; } d.body.appendChild(s); })(document, '506641c8');
0
59 комментариев
Популярные
По порядку
Написать комментарий...
7

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

Ответить
0

А какой бы стек выбрали Вы для такого проекта?

Ответить
1

Натив. А по бэку, на самом деле 1c и sap умеют в api, но если там все плохо под нагрузкой, то прослойку на любом языке сделать можно.

Ответить
0

Так это надо на 2 платформы делать. Плюс, а что тут плохого то?

Ну будет натив вместо ионика, а Firebase куда девать?

Все равно это приложение лишь тонкий клиент для сервера.

Ответить
3

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

Ответить
4

Сервер от 200 р (Linux). На нем спокойно запускается MongoDB и API на NodeJS.

 
Работы по разработке совсем не намного больше, но в отличие от firebase - ПО полностью под контролем. 

На мой взгляд Firebase только для прототипирования (и то не до конца такое понимаю), особенно в свете возможных санкций, а так же рубильника РКН.

Ответить
3

Мой голословный ответ на заголовок поста.

Для b2b проекта на ранней стадии преждевременные оптимизации естественно не имеют смысла. Тем более, что в адекватном проекте клиент всегда будет иметь встроенную телеметрию, которая не даст проспать момент ухода латенси бэка в красную зону. В этом случае, пожалуйста, хоть десять облаков, saas, paas, faas, maas и любой ass на выбор создателей. Вероятность выжить все равно в районе 5%.

Все становится намного интереснее когда ты изучаешь разбивку костов более-менее популярного проекта,  который уже вроде бы и выжил, но развивал кодовую базу в упоре на облака. Опуская постоянную борьбу ops-стафа с латенси на чужой бесконтрольной территории с узлами имеющими отвратительный интерконнект и неспособными обработать единый стэйт проекта на одном узле, мы увидим шокирующие адекватного CFO счета от ажура, авса и прочих гулов в  30-35% от operational costs.  Упс, технологический и экономический тупик для любителей облаков.

И когда ты считаешь затраты на серверную стойку пусть даже не нового железа, но с сильным интерконнектом на 40 Gbe для изначально правильно выбранной архитектуры с in-memory db и даже пусть отстающей персистенцией на энергонезависимые носители, то понимаешь, что ее срок окупаемости  - 1 месяц начислений от облаков. Полный и быстрый контроль над всей инфраструктурой и правильный Ux для клиентов, как минимум с точки зрения латенси. Как же хорошо жить! В мечтах.

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

Ответить
0

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

Ответить
2

Когда ваше API дергает 1000+ клиентов, повторюсь, любой ass и любой архитектурный франкинштейн.

Когда проект капитализируется по количеству пользователей - нужно сто раз подумать, прежде чем инвестировать в разработку cloud based app.

Ответить
2

Я так на файрбейсе прокололся, когда народ повалил, ну не 1000, а уже на 500+ обращений в минуту посыпались звонки от клиентов... За сутки перенесли БД на старый добрый ВИРТУАЛЬНЫЙ хостинг за 300р в мес и  начался шоколад.
Думаю, тупо огромный пинг к забугорным серверам решает не в пользу облаков...
Не все, что модно - полезно)))

Ответить
0

А на чём посыпались? На скорости загрузки экрана?

Ответить
1

Ответ на запрос стал дольше приходить. Данные в размере от 40 до 100кб на клиента.
 Мизер то бишь... Экран не причем, SPA-приложение.

Зачем разбираться в причине, если можно не разбираться в причине?

Ответить
2

Ну здесь скорее вопрос того во что верит архитектор проекта.

Вон Битрикс24 уже сделал выводы размещения своих ресурсов на собственных серверах в датацентре, переехали на Amazon AWS. Там явно больше 1000 онлайна. 

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

Ответить
0

Не могли бы вы подробнее раскрыть "веру" архитектора? Это зависит от уровня развития- на базовом уровне свое "железо" под столом, на продвинутом уровне облачное решение?

Ответить
0

Нет. Я специально не указал превосходство одного над другим. Это как с религией. 

Хороший проект можно сделать и на облаке и на своём сервере. И так же можно запороть в обоих случаях

Ответить
0

На одном теряешь,на другом выигрываешь.

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

Если вы уже не ИП Пупкин, который может позволить себе упавший на день сайт, но ещё не гигант, который может позволить себе несколько своих датацентров и армию админов, то прямая дорога в iaas, baas, faas и другие *aas.

Ответить
0

есть дешёвые облака, у того же хетцнера они по цене как обычные сервера. а всякие aws стартапы используют за счёт бесплатного tier для стартапов, там 100 тыщ выдаётся. прожираешь их и тогда уже уходишь на свои мощности :)

Ответить
0

Я так на Azure пробовал... Давали довольно большую сумму, которой в итоге впритык хватало... 
Теперь на чистых VDS трачу в 10 раз меньше.

Ответить
0

смотря по какой программе. в bizspark давали $150/mo в azure, которых хватало только на один vds - аналогичный стоит несколько баксов у хетцнеров. а какая-то ещё программа - $100k единовременно, плюс есть аналогичная у aws

Ответить
1

Bizspark, да, около 10 тыс. рублей. А потом какая-то фигня получилась с трафиком и оно закончилось в середине месяца. Тогда и перешел на VDS.
Сейчас например antiriusbeauty работает на одном сервере за 3 евро, плюс один резервный.

Ответить
0

С одной стороны облака дороже сейчас но если смотреть лет на 5-10 вперёд то скорее всего обычного хостинга не останется а хостингом станет облако. Лучше начинать готовится заранее. Например какой то ентерпрайс до сих пор может пользоваться Java 1.6-1.7 и платить Ораклу огромные деньги за поддержку потому что вовремя не перешли на новую версию не видя в этом пользы. Так же точно с меинфреймами которые выбирались потому что когда то были выгодней обычных серверов а сейчас их поддержка обходится миллионы. Универсальное решение найти сложно. 

Ответить
1

откройте для себя хетцнер - там цены будут от 200 р. за vm с 2 GB до 2000р. за сервер с 32 ГБ

Ответить
0

Тут вопрос больше в цене "напилить серверную часть с нуля". В FireStore делать пришлось чуть больше интеграции с 1С, остальное заложено в API

Ответить
–5

А зачем щас кому-то в мире нужна интеграция с 1С?

Ответить
1

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

Ответить
0

Верно, речь об обновлении остатков и актуализации цен. Как и писал в статье, цветы - товар сезонный, цены пляшут постоянно. 

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

Ответить
0

1) Почему использовали firestore? Почему не firebase realtime?

2) По поводу расширения на "платный тариф" ... звучит хорошо, но ограничений по бюджету в сутки на "Blaze Plan" нет. Соответственно, можно легко налететь на деньги проснувшись утром после "хорошего" трафика. Горький опыт использования "Blaze Plan" можно легко нагуглить :)

Ответить
1

 Горький опыт 

 налететь на деньги проснувшись утром после "хорошего" трафика

Интересно, почему многие боятся и не понимают облаков?
Много трафика? Возросшая нагрузка?
Так это же замечательно. Много клиентов, которые несут деньги. И сервисы отработали как надо переварив пиковую нагрузку.

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

Ответить
2

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

По поводу "хорошего трафика", это да, но ситуации бывают разные.
Приведу конкретный пример (см. скриншот), один клиент в прошлом году получил списание в пользу гугла за использование облачных сервисов в размере 14000 долларов США за один календарный месяц. Да, это не опечатка.

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

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

Этот пример конечно не относится конкретно к FireBase, это просто иллюстрация того, как бывает иногда в реальности.

Ответить
1

И в чем проблема?

Вы не пользовались этими сервисами? Или хотели бы их бесплатно?

Тем более, основная претензия к картографическим сервисам? За них бы пришлось платить даже на своем железе.

Я работал в компании, средний счёт которой был на уровне 100 тысяч долларов месяц. И никто не жаловался.

Ответить
2

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

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

Я работал в компании, средний счёт которой был на уровне 100 тысяч долларов месяц. И никто не жаловался.

Так работайте на здоровье, вопрос то в чём?

Ответить
0

Он имеет в виду, что официант (гугл) принес то, что вы заказывали. Счет принесли согласно прайса. И вопрос к вам: хотелось бы уточнить, что вы имели в виду про "неожиданное списание" за облака. Мое предположение, что вы имели в виду, что стоимость заранее не фиксируется и это плохо, да?

Ответить
1

Гендир Автоваза на общем собрании : в общем, работяги, премии в этом году не будет. Наш сайт ее съел.

Ответить
0

Для этого есть специальный раздел. Ну и оповещения можно настроить...

Ответить
0

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

Ответить
1

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

Кстати, за 25$ попользоваться Firebase уже не выйдет. As of January 2020, the Flame billing plan ($25/mo of additional quota) is no longer available for new sign-ups. 

Ответить
1

А как вы предлагаете реализовать лимиты по бюджету?

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

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

Мне как раз не все-равно. Я как раз оптимизирую затраты. Мне важно, что бы клиенты платили как можно меньше.

И клиенту выбирать, какое сочетание надёжность/производительность/цена выбрать. 

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

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

Ответить
0

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

p.s. Упасть от хабра-эффекта нужно постараться. В свое время даже хостинг за 200р спокойно справлялся. :)

Ответить
0

Это хабра-эффект уже не торт)

Ни у кого нет анлима по деньгам. Просто экономика сходится. Больше клиентов - больше денег.
Если бизнес не может отдать цент за посетителя, может нужно о чем-то задуматься?

Ответить
0

для приложения о заказах цветов облака это прям манна небесная- 7-го марта (или когда там) пойдет поток заказов огромный и облака не позволят упасть именно в этот пик.

А уже 9-го марта количество запросов упадет и цена за пользование облаками уменьшится.

Ответить
1

1. Архитектурой предполагалось, что БД в этом приложении больше используется как хранилище, при этом жёстких требований к реалтайму нет. Если не вдаваться в нюансы, то при использовании FireStore проще будет сделать фильтры по товарам, чем в FireBase.

2. Гуглил ещё когда делали RTPlatform, нашёл две типичные проблемы - когда программист не держит соединение, а для каждого запроса добавляет подключение/отключение от БД (болезнь собственного сервера, когда важно думать над тем, чтоб не загрузить ресурсы железа), получается ддос подключениями и солидный чек. Второе - когда идут не оптимизированные запросы. У нас недавно на багфиксе панели администратора одного приложения выяснилось, что программист, чтобы выдать в админке список пользователей, шпарит по каждому отдельный запрос. Соответственно, запрос страницы админки на 100 пользователей съедает 100 запросов. Естественно, переделывали на пакетный запрос. Обычно все такие беды проверяются на тестах и отладке, когда анализируется трафик к БД. 

Ответить
0

. Кроссплатформенная сборка дала плюсы в скорости и цене разработки.

Интересно, сколько по времени эта разработка заняла? Интересно оценить прирост в скорости относительно нейтива.

Ответить
0

С учётом вёрстки кастомного дизайна полтора мес

Ответить
–3

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

Вот реально, судя по видео, полтора месяца на это приложение, это реально много (раз в 5). Из всего того, что сделано не стандартно в айосе, это нижний таббар, он реально кастомный,  но такой кастом делается с нуля часа за 3- 4. Все остальное сделано на стандартных контролах. Я могу по видео прям расписать, сколько каждый экран должен занять времени и из чего он состоит. И это с учетом нормальной архитектуры и с красивыми анимашками. Как итог, такое приложение я напишу в ленивом темпе за неделю максимум. В чем я могу ошибиться, только в интеграции с 1С, она может быть капризной. Так в чем прирост в скорости? По стоимости спорить не буду, 1200 в час это реально меньше базовой ставки сеньора на нейтиве. Но даже если пересчитать 30 баксов/час за 40 часов работы, то не думаю, что дороже выйдет. Это законченный продукт? Не MVP?

Ответить

Комментарий удален

0

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

Ответить

Комментарий удален

0

Давно я так не смеялся 🤣 

А ты веселый! Можешь еще свою экспертизу написать про привычки студентов. 

Ответить
0

Это как бывает- 2-3 кнопки в приложении, а строк кода 10к ))) Под ними)))

Ответить
2

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

Ответить
0

То есть, по сути, у Дениса нормального разработчика нет? Вон сколько провозились

Ответить
1

А вы реально будете сеньора ставить на все задачи проекта? В плоть до вёрстки?.. ну ок, сделаете может за неделю а прикол то в чём?

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

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

В общем, Ваша идеальная схема ломается о реалии ведения операционной деятельности компании. 

Ответить
1

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

Но пожалуй, откажусь от этой затеи. Зайти в эту тему легко, но геморроя может много вылезти.

Ответить
1

Если Вы за неделю сделаете обе ОС, с учётом багфикса сдачи приёмки и прочей бюрократии, то Ваш час должен стоить под 7500 - 10 000р (это так скажем, мои прикидки объёма и сроков). Выходит где-то по 2 дня на операционку и день на сервер.

Измерения срока нейтива я делаю по средней оценке коллег. Мне предлагали в среднем по месяцу каждая ОС и ещё месяц раскурить 1С и сделать сервер с интеграцией. Выходило 3 мес (самые быстрые предлагали 2).

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

Ответить
0

больше болтовни, чем работы

Ну тут значит неправильно процессы построены. Болтовня лечится хабстафом с часовой оплатой работы. Процессы в Jira.

Если Вы за неделю сделаете обе ОС

Не, я оцениваю айос. Но второй разраб на Андроид примерно также займет времени (оцениваю по своему разработчику, что пилит для меня ведроид).

 сделать сервер с интеграцией

FireBase? Что там его делать?

 раскурить 1С 

Вот тут можно споткнуться, не спорю!

Ответить
1

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

Получается, что в человекочасах это 2 недели. В принципе реально, если делает человек уровня сеньора. Тут больше на багфиксе экономию вижу - баги одинаковые для обеих ОС и делается за один присест одним программистом. Если мелочи в стиле "съехала вёрстка", то выгоднее даже пустить в гит джуна, который это подправит.

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

С 1С зря споткнулись. Это же просто забрать и распарсить XML-файл в noSQL базу. Ну максимум несколько колбеков дать 1С-нику, если хочется заказы в 1С сразу писать.

Ответить
0

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

Ответить
0

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

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

Ответить
2

да это для всей индустрии откровение :)

про фулстек я говорил не применительно к этой проге, а индустрии вообще

Ответить
0

Про фулстек неправильно прочел предложнние. Смысл сломался. Прошу прощения.

Про откровение. Для индустрии это не откровение. Другое дело, что культуры написания юнит-тестов нет. Там где умеют писать тесты, баги очень редки. У одного заказчика приложение три года проработало с показателем crashfree 99,9%. Причем там стриминговый сервис по rtsp на всю Башкирию. А тут запрос забаганый и фризы вьюх.

Ответить
0

Вопрос автотестов это интересный момент. К слову, коллеги из kt.team в КП предлагают два варианта - "обычное" тестирование и отладка, в стиле тестировщик прошёл руками, что нашёл - поправили + гарантия 3 мес после сдачи. Второй - покрытие всего проекта автотестами и гарантия год. Второй вариант дороже ±30%. В абсолютных числах это 4 и 5 млн.р. Какая статистика выбора не смог получить инфы, но если это хайлоад екоммерс, как у них в ПФ, думаю, что тут второй вариант более выгоден с точки зрения "не потерять больше".

Ответить

Прямой эфир