На самом деле очень редкий кейс, сейчас уже не помню когда мы что-то с ней делали
Ну и по сути, если вы делаете много всяких "запросов", "фиксов" и так далее, то становится немного страшно: а все ли ок у озона? Ибо в компании в которой я работаю, если ребята из тех поддержки приходят с подобными запросами, то значит у нас где-то баг и нужно его фиксить, ну или это запрос новой функциональности.
С озоном все хорошо, если ты внимательно читал, я в итогах описывал почему это так и зачем) Глобально - все верно, ИТ-поддержка как раз и занимается тем, что приходит к разработке с найденными ошибками и они их исправляют, но описывать взаимодействие - отдельная тема для другой статьи, очень много разных процессов. Большая разница лишь в том, что разрабы чинят причину, поддержка последствия, тем самым мы экономим их время.
у нас есть несколько типов скриптов, одни которые используются ежедневно в рамках рутинных задач, другие пишутся для определённых целей и используются более редко. Но все они лежат на гите - поэтому там все это можно найти. Самое главное, что если кто-то пишет новый скрипт, обязательный пункт - пройти код-ревью, а также придерживаться описанной в наших доках стилистике написания и оформления скриптов. Ну и чаще всего, скрипт рождается из задач, где нужны, например, массовые изменения - изначально ставится отдельная задача на аналитику, описанию алгоритма и так далее, обычно мной как тимлидом команды, либо более опытным коллегой, знающим более углубленно необходимый продукт.
Зачем проверять связи между JIT-задачей и Jira-тикетами и исправлять их, если можно потратить время на анализ и определить причину проблемы
Все как раз таки очень просто - проверка связи в первую очередь это средство контроля, потому что ошибки при простановке связи чаще всего человеческий фактор, сейчас уже не испытываем этих проблем, но решили о них сказать.
спасибо!
На самом деле очень редкий кейс, сейчас уже не помню когда мы что-то с ней делали
С озоном все хорошо, если ты внимательно читал, я в итогах описывал почему это так и зачем) Глобально - все верно, ИТ-поддержка как раз и занимается тем, что приходит к разработке с найденными ошибками и они их исправляют, но описывать взаимодействие - отдельная тема для другой статьи, очень много разных процессов. Большая разница лишь в том, что разрабы чинят причину, поддержка последствия, тем самым мы экономим их время.
да запрос упадет
а почему нет? нам удобно видеть ответ и обработку, а также используем счетчик количества обработанных id, например.
у нас есть несколько типов скриптов, одни которые используются ежедневно в рамках рутинных задач, другие пишутся для определённых целей и используются более редко. Но все они лежат на гите - поэтому там все это можно найти. Самое главное, что если кто-то пишет новый скрипт, обязательный пункт - пройти код-ревью, а также придерживаться описанной в наших доках стилистике написания и оформления скриптов. Ну и чаще всего, скрипт рождается из задач, где нужны, например, массовые изменения - изначально ставится отдельная задача на аналитику, описанию алгоритма и так далее, обычно мной как тимлидом команды, либо более опытным коллегой, знающим более углубленно необходимый продукт.
Спасибо за отзыв, ознакомимся)
объявляется в отдельной функции, которую мы не описали (были на то причины)
в общем примере да, можно без него) ретернов много не бывает)))
Валидно) спасибо
Все как раз таки очень просто - проверка связи в первую очередь это средство контроля, потому что ошибки при простановке связи чаще всего человеческий фактор, сейчас уже не испытываем этих проблем, но решили о них сказать.