Есть какая-нибудь книжка с описанием и примерами стоимости фронта и бэка. Т.е. фронт мы делаем для клиента и он должен быть качественным, бэк делаем как правило для внутреннего использования и он должен быть скорее дешевым и с минимальными затратами по времени. Нужно только это все более доказуемой форме с жизненными примерами. Может есть какие-то известные статьи книги по этому поводу ?
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Есть какая-нибудь книжка с описанием и примерами стоимости фронта и бэка. Т.е. фронт мы делаем для клиента и он должен быть качественным, бэк делаем как правило для внутреннего использования и он должен быть скорее дешевым и с минимальными затратами по времени. Нужно только это все более доказуемой форме с жизненными примерами. Может есть какие-то известные статьи книги по этому поводу ?
Мне кажется, что это настолько спорные утверждения и странное деление, что никаких книжки по этим тезисам быть просто не может
Здравствуйте, sushko, Вы писали:
S>Здравствуйте, okon, Вы писали:
O>>Есть какая-нибудь книжка с описанием и примерами стоимости фронта и бэка. Т.е. фронт мы делаем для клиента и он должен быть качественным, бэк делаем как правило для внутреннего использования и он должен быть скорее дешевым и с минимальными затратами по времени. Нужно только это все более доказуемой форме с жизненными примерами. Может есть какие-то известные статьи книги по этому поводу ?
S>Мне кажется, что это настолько спорные утверждения и странное деление, что никаких книжки по этим тезисам быть просто не может
Мне просто это кажется достаточно очевидным, например, для простоты, если говоря я продаю услугу сложения 2х чисел.
Т.е. мне клиент называет A и Б , я даю ему сумму.
Если это делать в виде фронта, то там должен быть приятный интерфейс, красивые кнопочки, дизайн с привычным узнаваемым представляением в виде калькулятора.
Если делать в виде бэка, т.е. нет фронта, но услуга предоставляется как сложение чисел по телефону или в офисе. То я могу написать простую консольку куда оператор будет вводить данные. То что клиент не будет видеть, а будет только получать результат. Затраты на такую программу существенно меньше чем на фронтовую часть и она достаточна для работы.
А какие есть спорные случаи ? Когда наоборот ?
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Есть какая-нибудь книжка с описанием и примерами стоимости фронта и бэка. Т.е. фронт мы делаем для клиента и он должен быть качественным, бэк делаем как правило для внутреннего использования и он должен быть скорее дешевым и с минимальными затратами по времени. Нужно только это все более доказуемой форме с жизненными примерами. Может есть какие-то известные статьи книги по этому поводу ?
Если выйти за рамки только Web-приложений, то фронт-енд может быть:
— Web UI
— GUI
— CLI
— Голосовой какой-нибудь и т.д.
Фронт-енд, если говорить не про веб, можно называть также engine, LL (low level).
Это все может объединяться в:
Web UI + бэк-енд
GUI + бэк-енд
CLI + бэк-енд
Помимо прочего, ПО может распространяться и вовсе без как-такового фронт-енда. Например, SDK, в виде REST API и прочих API. Не говоря уже о программных и программно-аппаратных комплексах.
Говорить о том, что фронт — самая важная и дорогая часть — чушь. Это не так. Бэк-енд должен быть дешевый — тоже еще та глупость.
Есть продукты, где GUI выглядит непрезентабельно с точки зрения условной "домохозяйки", отсталый на 5 лет и без рюшечек. Но самое главное там — бэк-енд. И стоить такой продукт может десятки тысяч долларов.
Есть Web UI — где фронт-енд не главное. Бэк-енд — самая дорогая и важная часть. И все это в коплексе, опять-таки, может стоить до сотен тысяч долларов.
Есть продукты, распространяемые в виде SDK. Тут ценник можзет быть примерно тех же порядков.
Это все я привел примеры, о которые знаю лично. Причем, это все не на заказ продукты для одного заказчика. Впосне допускаю также, что есть продукты стоимостью сотни тысяч долларов.
Забыл про CLI. Вы, по всей видимости, назвали это "бэком".
Если делать в виде бэка, т.е. нет фронта, но услуга предоставляется как сложение чисел по телефону или в офисе. То я могу написать простую консольку куда оператор будет вводить данные. То что клиент не будет видеть, а будет только получать результат. Затраты на такую программу существенно меньше чем на фронтовую часть и она достаточна для работы.
В ряде областей CLI интерфейс как раз подходит больше. И его стоимость может быть также очень высокой. Например, когда мы встраиваем ПО в свой workflow. Можно встраивать CLI в свой Web бэк-енд. Примеров полно.
В таких случаях это не "просто консолька" и разрабатывать ее быстро, дешево и на скорую руку не получится.
DP>В таких случаях это не "просто консолька" и разрабатывать ее быстро, дешево и на скорую руку не получится.
не обязательно консолька это может быть любая морда для внутреннего использования. Я тут похоже ошибся с терминологией, под фронтом имелось ввиду например сайт компании или то с чем работает клиент компании, а под бэком все что внутри компании и не видно клиенту. Например софт операционистки может быть вполне с кривыми кнопками и недружественным интерфейсом и даже падать каждый час , а подобное для софта предоставляемого клиенту не допустимо.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
O>Например софт операционистки может быть вполне с кривыми кнопками и недружественным интерфейсом и даже падать каждый час , а подобное для софта предоставляемого клиенту не допустимо.
Тут все индивидуально. В примеденном вами примере, я бы как раз не экономил на интерфейсе для операционистки. С точки зрения бизнеса, тут как раз можно либо тратить впустую деньги, либо экономить. Ведь операционистки весь день пользуются интерфейсом. Он должен быть максимально продуманным, удобным и эргономичным. Это ускорит время работы операционисток, снизит вероятность ошибки, а вы сможете обслуживать не 100 условных клиентов, а 150, что увеличит прибыль.
Я бы даже сказал, что на таком интерфейсе не следует экономить в смысле эргономики. Да, можно не тратить кучу денег на рюшечки, но интерфейс, повторюсь, должен быть удобным, продуманным и эргономичным.
Здравствуйте, okon, Вы писали:
O>Если это делать в виде фронта, то там должен быть приятный интерфейс, красивые кнопочки, дизайн с привычным узнаваемым представляением в виде калькулятора.
O>Если делать в виде бэка, т.е. нет фронта, но услуга предоставляется как сложение чисел по телефону или в офисе. То я могу написать простую консольку куда оператор будет вводить данные. То что клиент не будет видеть, а будет только получать результат. Затраты на такую программу существенно меньше чем на фронтовую часть и она достаточна для работы.
Ваша мысль ясна. Но также фронт может состоять из окошка ввода и одной кнопочки, а бэк — из сотен серверов, работающих во взаимодействии друг с другом (пример — гугль). А может быть и так, как Вы предложили. А может быть и еще надцать разных комбинаций сравнительной сложности/трудоемкости фронтенда и бэкенда.
То есть могут быть самые различные комбинации фронта и енда, и надеяться, что где-то существует "исследование" (любого качества — от школьного реферата до серьезного труда), доказывающее, что затраты на фронт должны быть больше (или меньше, или равны) затратам на бэк — бессмысленно.
Здравствуйте, DiPaolo, Вы писали:
O>>Например софт операционистки может быть вполне с кривыми кнопками и недружественным интерфейсом и даже падать каждый час , а подобное для софта предоставляемого клиенту не допустимо.
DP>Тут все индивидуально. В примеденном вами примере, я бы как раз не экономил на интерфейсе для операционистки. С точки зрения бизнеса, тут как раз можно либо тратить впустую деньги, либо экономить. Ведь операционистки весь день пользуются интерфейсом. Он должен быть максимально продуманным, удобным и эргономичным. Это ускорит время работы операционисток, снизит вероятность ошибки, а вы сможете обслуживать не 100 условных клиентов, а 150, что увеличит прибыль.
Да это если только есть те 150 клиентов которых можно обслужить, но не успеваем из-за того что плохой софт у операциониста.
Если клиентов 100 и операционистка справляется, то можно конечно из гуманных соображений эргономизировать, но экономического выхлопа это не даст.
Лучше на сэкономленные деньги создать еще один продукт который привлечет еще 100 клиентов. И там если операционистке станет тяжело, то оптимизировать, предварительно поняв на чем у нее пробуксовка случается. Все подряд мне кажется эргономизировать не стоит.
DP>Я бы даже сказал, что на таком интерфейсе не следует экономить в смысле эргономики. Да, можно не тратить кучу денег на рюшечки, но интерфейс, повторюсь, должен быть удобным, продуманным и эргономичным.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Есть какая-нибудь книжка с описанием и примерами стоимости фронта и бэка. Т.е. фронт мы делаем для клиента и он должен быть качественным, бэк делаем как правило для внутреннего использования и он должен быть скорее дешевым и с минимальными затратами по времени. Нужно только это все более доказуемой форме с жизненными примерами. Может есть какие-то известные статьи книги по этому поводу ?
Качество продукта это характеристика совокупности всех компонентов. Если у вас бэкэнд глючит, фронтэнд чуда не сделает. Качественным должно быть всё и это напрямую противоречит "дешёвым и с минимальными затратами по времени".
S>То есть могут быть самые различные комбинации фронта и енда, и надеяться, что где-то существует "исследование" (любого качества — от школьного реферата до серьезного труда), доказывающее, что затраты на фронт должны быть больше (или меньше, или равны) затратам на бэк — бессмысленно.
Абсолютно согласен, фронты и енды или как поправили меня правильнее internal и external продукты могут быть разного масштаба и в общем случае их сравнивать бессмысленно. Но мне интересно только в ограниченной плоскости когда функционал один и тот же и нужно оценить рамки стоимости как internal и тот же функционал как external, какие соотношения трудозатрат на практике получаются. Понятно что в самом экономном варианте external вырождается в internal и равен ему. Но обычно для внешнего пользователя требуется пилить софт более качественно, вот и интересно какие максимумы, среднее для оценки можно взять.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Но мне интересно только в ограниченной плоскости когда функционал один и тот же и нужно оценить рамки стоимости как internal и тот же функционал как external, какие соотношения трудозатрат на практике получаются.
Если вам нужно оценить конкретную разработу, то для этого мало входных данных. Какая нагрузка, сколько человек (операционисток) будет пользоваться, специфика, желательно область и другие детали. Пока идет обсуждение сферического коня в вакууме.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, okon, Вы писали:
O>>Есть какая-нибудь книжка с описанием и примерами стоимости фронта и бэка. Т.е. фронт мы делаем для клиента и он должен быть качественным, бэк делаем как правило для внутреннего использования и он должен быть скорее дешевым и с минимальными затратами по времени. Нужно только это все более доказуемой форме с жизненными примерами. Может есть какие-то известные статьи книги по этому поводу ?
vsb>Качество продукта это характеристика совокупности всех компонентов. Если у вас бэкэнд глючит, фронтэнд чуда не сделает. Качественным должно быть всё и это напрямую противоречит "дешёвым и с минимальными затратами по времени".
Согласен но частично, в части если "бэк" напрямую затрагивает "фронт", т.е. например если клиент добавляет продукт в корзину а он из-за кривого "бэка" вдруг случайно не добавляется. Но если "бэк" не сказывается напрямую на пользователе, а только внутренняя проблема которая решается внутри компании то ничего критичного с т.з. бизнеса нет, пока поток клиентов успевают обслуживать. Понятно что хорошо бы поправить, но с другой стороны еще лучше открыть новую услуг например бонусы , чем улучшать "бэк" без особой надобности.
Лучше открыть интернет-магазин на месяц раньше конкурентов имеющий бэк с некритичными недостатками, чем позже на месяц. Это и есть когда лучше дешевле и с минимальными затратами.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Мысли изложу, на чём можно сэкономить, может будет интересно.
1. Безопасность. Для внутреннего продукта на безопасность можно забить в какой-то мере. На самом деле это может быть опасно, т.к. сегодня он внутренний для вашей компании из трёх человек, а завтра внезапно может стать внутренним для компании из 10 000 человек с 50-ю филиалами по 5 странам. И безопасность может внезапно стать актуальной. Но это уже проблемы роста.
2. Дизайн. Внутренний продукт не должен "продаваться", поэтому на визуальный дизайн можно забить. Очень забавно было на сервисе namecheap (продажа доменов). Внешний сайт у них для покупателей был сделан очень красиво и модно. Всё как положено. А после того, как ты купил домен и попал в админку — ну видно, что программист сел и наклепал это всё и плевать ему было на дизайн
3. Баги. Какие-то баги можно не исправлять, т.к. проще сказать нужным людям, как их обходить.
А вообще я бы разделял не на фронт и бэк, а более обобщённо. Во-первых это число пользователей, во-вторых это то, насколько пользователи вынуждены пользоваться этим продуктом. Абсолютно так же можно экономить на коробочном софте или сервисе для конечного пользователя, но при этом по каким-либо не имеющего конкурентов и необходимом для работы.
Здравствуйте, okon, Вы писали:
O>Есть какая-нибудь книжка с описанием и примерами стоимости фронта и бэка. Т.е. фронт мы делаем для клиента и он должен быть качественным, бэк делаем как правило для внутреннего использования и он должен быть скорее дешевым и с минимальными затратами по времени. Нужно только это все более доказуемой форме с жизненными примерами. Может есть какие-то известные статьи книги по этому поводу ?
Вы пишете проект для себя или своей команды, не собираясь его никому показывать. В этом случае вам позволено очень много вольностей. Никто, конечно, не заставляет вас отклоняться от идеалов к подходам разработки ПО, но если очень хочется, то можно — ничего предосудительного в этом нет. Нет нужды разрабатывать грамотную документацию, комментарии можно писать на родном языке (если его понимают все вовлечённые в разработку лица), а какие-то нетривиальные архитектурные решения (совсем не очевидные из кода) можно на словах объяснить товарищам по команде. Я не говорю, что обязательно нужно так делать. Но если, скажем, вы куда-то очень торопитесь, то некоторыми хорошими практиками можно пренебречь.
§Публичные проекты
Тут у нас уже совсем другая ситуация. Лучше бы вам нормально документировать ваш проект, чтобы по нему не возникало каждый день по сотне вопросов от ваших любимых пользователей. И лучше бы писать документацию на английском (как, впрочем, и комментарии). Да и код лучше бы писать почище, чтобы человеку со стороны было легко в нём разобраться. Если же у вас есть API, то хорошо бы его продумать, а не просто налепить какой-то интерфейс, из которого при большом желании как-то можно вытащить все нужные данные. Помните, что проект принадлежит уже не только вам, но и сторонним программистам — уважайте тех, кто будет работать с вашим кодом. Пишите программу так, чтобы вас потом не хотели поймать в тёмной подворотне и сделать с вами плохие вещи.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
