Мысль понятна. Не понятно, как автор к ней пришел, точнее к ситуации, когда появилась потребность анализировать подход настолько поверхностно. Тема не развернута, лично я до конца не понял, что именно автора так задело, т.к. проектирование "от ui" является наиболее логичным, когда создаёшь продукт, т.е. отправной точкой для mvp должно быть удовлетворение конкретных потребностей продукта (сервиса), а все навороты и фичи - уже потом?
При этом сам не раз сталкивался, и, можно сказать, специализируюсь даже, на случаях когда "под капотом все не очевидно", но и тут всегда все отталкивается изначально от покрытия потребностей, а код - всего лишь способ реализовать это покрытие, теми или иными путями.
Всегда пожалуйста. С ростом нагрузок, SKU, вариативности продаж, внедрения маркировки, открытия филиалов и точек продаж, РЦ и т.д., вы также узнаете, что битрикс не тянет от слова "совсем", и нужно будет отдельное решение, скорее всего двухкомпонентное. В общем, впереди много нового, если что пишите, подскажу что знаю из практики.
Надеюсь, что вы вскоре с этим столкнетесь, т.к. это будет означать бурный рост ;)
Не знаю, насколько у вас большая и нагруженная база 1С, у нас более 1Тб постоянно в оперативке приходится крутить, так что всегда приходится отталкиваться от постулата "лучше отдать сырые данные и обработать их вовне".
Копию логики создать и поддерживать в актуальном состоянии не так сложно (с учетом собственной команды разработки), и именно из-за необходимости учета не-линейных показателей - это наиболее актуально, т.к. веб-сервер математику исполняет не хуже самой 1С, а вот с выгрузками масштабных данных у 1С проблемы, и, как следствие, возможны проблемы:
в процессе выгрузки гигантского массива происходит сбой:
1.1. со стороны 1С - отрубился интернет
1.2. со стороны веб-сервиса - недоступность
1.3. со стороны веб-сервиса - в процессе приема и разбора данных появились ошибки и некоторые блоки не были записаны / обновлены
1.4. и так далее, вариантов масса
пока на стороне 1С формируются данные на отдачу - могут возникать конфликты блокировок.
пока на стороне 1С формируются данные на отдачу - могут быть произведены изменения в записях самой 1С. И это не будет исправлено до следующего обмена.
любые попытки снизить риски предыдущих трех пунктов без изменения глобального подхода - это временные костыли, которые сломаются в самый неподходящий момент (дело пошло в гору, много пользователей, много заказов - и привет)
По акциям, спецценам, индивидуальным скидкам и т.д. - обычная работа с матрицами, ничего особенного. Работает математика на веб-сервере не хуже чем в 1С, с той разницей, что горизонтально масштабировать его кудааааааа как проще, чем 1С (на случай наплыва пользователей).
Складывается впечатление, что, либо у вас не такая нагруженная система как вы описываете в статье, которая чувствует себя вальяжно, либо вам еще предстоит узнать все "прелести" проблем, о которых я пишу :)
3500 клиентов * 10000 един ц sku = большие таблицы, с которыми, мало того что Битрикс работает с трудом, так ещё и 1с грузить такими масштабными выгрузками... Ну нецелесообразно точно =)
Берём матрицу исчисления цен (тупо математика, та же что и в 1с), и считаем на лету при формировании страницы. Не нужно конструировать статического монстра, одновременно нагружая 1с.
Мне кажется, это все же вопрос системы управления: либо нацеленность на результат и свободное время как поощрение эффективности, либо классическое "высиживание" времени (что, к счастью, отмирает).
Кажется, это вопрос лидеров команд, ведь при любом раскладе - низкая эффективность - это проблема построения мотивации программистов к достижению цели. Либо не корректное (в парадигме рабочего процесса конкретной компании) планирование. И в том и в другом случае - рыба гниёт с головы =)
Весной делал несколько интернет-заказов. Каждый раз единственным вариантом, чтобы получить заказ, было - докопаться до усталых и злых ребят на стойке информации/кассе, получить порцию молчаливой ненависти, и ждать 15-30 минут, пока они найдут хоть кого-то способного найти и выдать заказ. Дело было в трёх разных городах, из которых два - мегаполисы.
Для своей компании, в т.ч. для розничной сети, внедрял телеграм-бота для уведомлений, много всего для информационного обмена и постановки задач на протяжении последних четырех лет.
И главный вывод, к которому пришел - это работа с персоналом, и только потом технологии, потому что если конечный пользователь-сотрудник не будет замотивирован в использовании сервиса, если он будет неудобен и не нужен ему - все пойдет прахом.
Потерпевшей стороны нет, значит, не попадает
Мысль понятна. Не понятно, как автор к ней пришел, точнее к ситуации, когда появилась потребность анализировать подход настолько поверхностно. Тема не развернута, лично я до конца не понял, что именно автора так задело, т.к. проектирование "от ui" является наиболее логичным, когда создаёшь продукт, т.е. отправной точкой для mvp должно быть удовлетворение конкретных потребностей продукта (сервиса), а все навороты и фичи - уже потом?
При этом сам не раз сталкивался, и, можно сказать, специализируюсь даже, на случаях когда "под капотом все не очевидно", но и тут всегда все отталкивается изначально от покрытия потребностей, а код - всего лишь способ реализовать это покрытие, теми или иными путями.
Всегда пожалуйста. С ростом нагрузок, SKU, вариативности продаж, внедрения маркировки, открытия филиалов и точек продаж, РЦ и т.д., вы также узнаете, что битрикс не тянет от слова "совсем", и нужно будет отдельное решение, скорее всего двухкомпонентное. В общем, впереди много нового, если что пишите, подскажу что знаю из практики.
Надеюсь, что вы вскоре с этим столкнетесь, т.к. это будет означать бурный рост ;)
Не знаю, насколько у вас большая и нагруженная база 1С, у нас более 1Тб постоянно в оперативке приходится крутить, так что всегда приходится отталкиваться от постулата "лучше отдать сырые данные и обработать их вовне".
Копию логики создать и поддерживать в актуальном состоянии не так сложно (с учетом собственной команды разработки), и именно из-за необходимости учета не-линейных показателей - это наиболее актуально, т.к. веб-сервер математику исполняет не хуже самой 1С, а вот с выгрузками масштабных данных у 1С проблемы, и, как следствие, возможны проблемы:
в процессе выгрузки гигантского массива происходит сбой:
1.1. со стороны 1С - отрубился интернет
1.2. со стороны веб-сервиса - недоступность
1.3. со стороны веб-сервиса - в процессе приема и разбора данных появились ошибки и некоторые блоки не были записаны / обновлены
1.4. и так далее, вариантов масса
пока на стороне 1С формируются данные на отдачу - могут возникать конфликты блокировок.
пока на стороне 1С формируются данные на отдачу - могут быть произведены изменения в записях самой 1С. И это не будет исправлено до следующего обмена.
любые попытки снизить риски предыдущих трех пунктов без изменения глобального подхода - это временные костыли, которые сломаются в самый неподходящий момент (дело пошло в гору, много пользователей, много заказов - и привет)
По акциям, спецценам, индивидуальным скидкам и т.д. - обычная работа с матрицами, ничего особенного. Работает математика на веб-сервере не хуже чем в 1С, с той разницей, что горизонтально масштабировать его кудааааааа как проще, чем 1С (на случай наплыва пользователей).
Складывается впечатление, что, либо у вас не такая нагруженная система как вы описываете в статье, которая чувствует себя вальяжно, либо вам еще предстоит узнать все "прелести" проблем, о которых я пишу :)
Выгружать индивидуальные цены, серьезно?
3500 клиентов * 10000 един ц sku = большие таблицы, с которыми, мало того что Битрикс работает с трудом, так ещё и 1с грузить такими масштабными выгрузками... Ну нецелесообразно точно =)
Берём матрицу исчисления цен (тупо математика, та же что и в 1с), и считаем на лету при формировании страницы. Не нужно конструировать статического монстра, одновременно нагружая 1с.
Мне кажется, это все же вопрос системы управления: либо нацеленность на результат и свободное время как поощрение эффективности, либо классическое "высиживание" времени (что, к счастью, отмирает).
Кажется, это вопрос лидеров команд, ведь при любом раскладе - низкая эффективность - это проблема построения мотивации программистов к достижению цели. Либо не корректное (в парадигме рабочего процесса конкретной компании) планирование. И в том и в другом случае - рыба гниёт с головы =)
Весной делал несколько интернет-заказов. Каждый раз единственным вариантом, чтобы получить заказ, было - докопаться до усталых и злых ребят на стойке информации/кассе, получить порцию молчаливой ненависти, и ждать 15-30 минут, пока они найдут хоть кого-то способного найти и выдать заказ. Дело было в трёх разных городах, из которых два - мегаполисы.
Для своей компании, в т.ч. для розничной сети, внедрял телеграм-бота для уведомлений, много всего для информационного обмена и постановки задач на протяжении последних четырех лет.
И главный вывод, к которому пришел - это работа с персоналом, и только потом технологии, потому что если конечный пользователь-сотрудник не будет замотивирован в использовании сервиса, если он будет неудобен и не нужен ему - все пойдет прахом.
А вы, ребята, похоже об этом совсем забыли)