Ну... Если это помогает клиентам разобраться в проблеме, то почему бы и да. Но видимо Ваш API не используется для массовых внешних интеграций К ВАШЕЙ системе.
Нужно пояснение в API-документации и обоснование, почему так делаете. Без обоснования решения заплюют :)
409 Conflict — запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT. Появился в HTTP/1.1.
Если мы делаем через PUT, то допустимо. Если делаем через POST - в целом тоже. Ошибка про одно и то же :)
409 The request conflicts with another request (perhaps due to using the same idempotent key) = Запрос конфликтует с другим запросом (возможно, из-за использования того же идемпотентного ключа).
Всегда стараюсь искать подтверждение. Почему задала вопрос и не стала оставлять свое мнение: я делала и делаю HTTP 400/500 со специальными кодами ответов, чтобы не разводить зоопарк разных HTTP. Так научили разработчики и архитекторы, с которыми был опыт работы. Хотя правильно делать скорее HTTP -409 или -422.
422 Unprocessable Entity — сервер успешно принял запрос, может работать с указанным видом данных (например, в теле запроса находится XML-документ, имеющий верный синтаксис), однако имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом. Введено в WebDAV.
Пока у них не очень выходит. Сценарии работы системы приводим в порядок после работы ChatGPT. С проектированием БД, API и архитектуры ситуация такая же. Без опыта и понимания контекста реального проекта пока нельзя - нужна работа системного аналитика
Сертификаты - очень нужные штуки в зарубежных компаниях. Это для галочки много где требуется. Но не везде. Считаю, что собеседование и умение применять знания решают больше, чем наличие бумажки. А так - сертификация полезна: можно разложить знания по полочкам и достать из дальних углов мозга то, что давно не использовалось.
Хотелось донести, что любой участник команды разработки может помочь.
В одном из ответов выше писала — нет желания замыкать задачу на аналитике и блокировать разработку из-за него, если он не успевает.
Причины появления аналитика
Это действительно одни из ряда причин, когда в компании задумываются о найме отдельного специалиста. Но это не значит, что к аналитику относятся как «мы скинем на аналитика то, что не хотим делать сами».
Не хотят анализировать: вероятно, уже наступили на ошибки анализа, т.к. не хватало скилов (о чем Вы упомянули выше — высокая цена ошибки)
Не хотят документировать: «Код — это и есть документация», а затем через 5 лет по нему не могут вспомнить как алгоритм должен работать.
Не хотят общаться с заказчиком: анализ требований заказчика одна из задач аналитика, но обычно бизнес-аналитика, а не системного.
роль аналитика самая несчастная в плане набора задач
Зависит от компании. Я не считаю роль аналитика самой несчастной.
Если аналитик довел себя до состояния супер-героя на проекте, значит что-то идет не так. Очень рекомендую на эту тему посмотреть доклад analystdays.ru/ru/talk/78352
всем, помимо непосредственно требований.
Есть полезный опыт. Если аналитик меньше 60% рабочего времени занимается анализом, значит что-то пошло не так. Ссылка на интересный доклад выше.
О полезном опыте
Опыт тестирования для аналитика полезен.
Когда ты приходишь на большой развивающийся проект и нужно раскопать как работает какая-то функциональность, то полезно самостоятельно дернуть запрос через Postman, проверить как UI и БД между собой связаны и т.п.
Сделать ревью тест-плана тоже хорошо.
Менеджмент — у кого-то бывает. Не самое приятное и полезное, но частенько скидывают это на аналитика (у нас не так, чему я очень рада). Из полезного — умение оценивать масштаб задачи.
Тех. писатель — аналитик должен уметь писать тех. документацию по ГОСТУ, но не 100% времени. Основная задача — проработка решения и его документирование (не оставлять же решение задачи в голове и на словах).
Как считаете, что делать дальше в таком случае? Переучиваться или продолжать работать в таких нишах дальше?
Доучиваться, развиваться и искать место, где можно будет применить себя как специалиста системного анализа, а не позицию «многорукого шивы».
На собеседовании рекомендую задавать вопросы работодателю:
А кто еще есть в команде?
А как устроен процесс от момента получения требований до момента релиза, где подключается аналитик?
А кто отвечает за планирование спринта?
Надеюсь, что ответ будет полезен.
Спасибо за ответ и хороший вопрос!
Хочется отметить самое вопиющее: системным анализом может заниматься не любой член команды, а сотрудник, обладающий соответствующими компетенциями
Если говорим о проработке тех. реализации — нужны соответствующие скилы.
Если говорим о написании сценариев работы с системой, то могут помочь тестировщики (пример: поиск альтернативных кейсов) — тоже нужны соответствующие скилы. И разработчик, и тестировщик — участники команды, которые могут помочь в проработке решения.
Системный аналитик нужен там, где цена ошибки высока
1) Вигерс писал: «Не существует выверенного способа написания идеальных требований, а лучший учитель это опыт, который нарабатывается со временем».
Всё зависит от продукта и команды. Делюсь тем, к чему пришли и как это помогает.
2) Проектировать вместо разработчика можно, но не нужно. Иначе получится ровно то, что Вы написали: кодеры и аналитики.
В процессе проектирования участвует команда, что позволяет не замыкать разработку и знания о продукте на одном человеке и проявлять творческие начала всем. Аналитик не блокирует разработку.
Системный аналитик — участник процесса проектирования. Он больше погружается в анализ и описание процессов, сценариев работы с системой, меньше в проектирование технической реализации, но умеет грамотно изложить ее и зафиксировать решение, анализирует взаимосвязи в продукте.
По итогам разработки аналитик у нас отвечает за сбор знаний — документирование продукта. Т.о. если результат работы разработчика — код и рабочее ПО, то результат работы аналитика — документация.
Здравствуйте! Спасибо за комментарий, правку внесла :)
Спасибо! Обязательно повторите и вы эту работу на практике, это полезный тренажер, максимально приближенный к реальной работе :)
Благодарю за обратную связь! :)
Нужны шаблоны, как для miro. По отзывам коллег-аналитиков его тоже используют, поэтому включила. Уточнила в статье, благодарю за комментарий!
Поддерживаю:
Оба варианта хорошие.
Я бы назвала это проблемой новичков, когда мы с вами точно знаем, что надо три эндпоинта:
города
регионы (пропустили)
страны
И в этом случае, на примере получения данных по списку городов в регионе:
GET /country/{countryId}/region/{regionId}/city - перебор
GET /region/{regionId}/city - странно, куда потеряли страны?
GET /city/?countryId={countryId} и GET /city/?countryId={countryId} - работают одновременно и хорошо для городов и регионов, гибкость, независимость.
Тут новички реально могут что-то терять и упускать, сложная иерархия, а 6-уровневый АПИ не лучшее решение.
Важно думать о разных вариантах и выбирать лучший, задумываясь на пару шагов вперед, при возможности.
Круто, когда в команде идеи могут незавимимо накидать и разработчики, и системные аналитики, а затем выбрать лучшее, с обоснованиями.
Ну... Если это помогает клиентам разобраться в проблеме, то почему бы и да. Но видимо Ваш API не используется для массовых внешних интеграций К ВАШЕЙ системе.
Нужно пояснение в API-документации и обоснование, почему так делаете. Без обоснования решения заплюют :)
Согласно описанию 409:
Если мы делаем через PUT, то допустимо. Если делаем через POST - в целом тоже. Ошибка про одно и то же :)
В подтверждение Вашего ответа:
https://stripe.com/docs/api/errors - международная платежная система.
409 The request conflicts with another request (perhaps due to using the same idempotent key) = Запрос конфликтует с другим запросом (возможно, из-за использования того же идемпотентного ключа).
Всегда стараюсь искать подтверждение. Почему задала вопрос и не стала оставлять свое мнение: я делала и делаю HTTP 400/500 со специальными кодами ответов, чтобы не разводить зоопарк разных HTTP. Так научили разработчики и архитекторы, с которыми был опыт работы. Хотя правильно делать скорее HTTP -409 или -422.
Благодарю за рекомендацию!
Здравствуйте!
Можете привести чуть более конкретный пример, пожалуйста?
Идею поняла, но не сталкивалась много с подобными ошибками у новичков.
Здравствуйте!
Можно заменить пример на "Создать задачу, при условии, что запрещено создавать задачи с одинаковыми названиями".
Интересно, как обрабатываются ошибки логики сервера. У кого 400-я, а у кого 500-я на такой тип ошибок идёт. Не обязательно 1 в 1, а похожие.
Здравствуйте! Спасибо, что сообщили! Было исправлено!
Пока у них не очень выходит. Сценарии работы системы приводим в порядок после работы ChatGPT. С проектированием БД, API и архитектуры ситуация такая же. Без опыта и понимания контекста реального проекта пока нельзя - нужна работа системного аналитика
Исправлено! :)
Благодарю за внимательность! Исправлено
Благодарю! Исправлено
Сертификаты - очень нужные штуки в зарубежных компаниях. Это для галочки много где требуется. Но не везде. Считаю, что собеседование и умение применять знания решают больше, чем наличие бумажки.
А так - сертификация полезна: можно разложить знания по полочкам и достать из дальних углов мозга то, что давно не использовалось.
В одном из ответов выше писала — нет желания замыкать задачу на аналитике и блокировать разработку из-за него, если он не успевает.
Это действительно одни из ряда причин, когда в компании задумываются о найме отдельного специалиста. Но это не значит, что к аналитику относятся как «мы скинем на аналитика то, что не хотим делать сами».
Если аналитик довел себя до состояния супер-героя на проекте, значит что-то идет не так. Очень рекомендую на эту тему посмотреть доклад analystdays.ru/ru/talk/78352
Есть полезный опыт. Если аналитик меньше 60% рабочего времени занимается анализом, значит что-то пошло не так. Ссылка на интересный доклад выше.
Когда ты приходишь на большой развивающийся проект и нужно раскопать как работает какая-то функциональность, то полезно самостоятельно дернуть запрос через Postman, проверить как UI и БД между собой связаны и т.п.
Сделать ревью тест-плана тоже хорошо.
Менеджмент — у кого-то бывает. Не самое приятное и полезное, но частенько скидывают это на аналитика (у нас не так, чему я очень рада). Из полезного — умение оценивать масштаб задачи.
Тех. писатель — аналитик должен уметь писать тех. документацию по ГОСТУ, но не 100% времени. Основная задача — проработка решения и его документирование (не оставлять же решение задачи в голове и на словах).
Доучиваться, развиваться и искать место, где можно будет применить себя как специалиста системного анализа, а не позицию «многорукого шивы».
На собеседовании рекомендую задавать вопросы работодателю:
Надеюсь, что ответ будет полезен.
Спасибо за ответ и хороший вопрос!
Если говорим о написании сценариев работы с системой, то могут помочь тестировщики (пример: поиск альтернативных кейсов) — тоже нужны соответствующие скилы. И разработчик, и тестировщик — участники команды, которые могут помочь в проработке решения.
Всё так
Всё зависит от продукта и команды. Делюсь тем, к чему пришли и как это помогает.
2) Проектировать вместо разработчика можно, но не нужно. Иначе получится ровно то, что Вы написали: кодеры и аналитики.
В процессе проектирования участвует команда, что позволяет не замыкать разработку и знания о продукте на одном человеке и проявлять творческие начала всем. Аналитик не блокирует разработку.
Системный аналитик — участник процесса проектирования. Он больше погружается в анализ и описание процессов, сценариев работы с системой, меньше в проектирование технической реализации, но умеет грамотно изложить ее и зафиксировать решение, анализирует взаимосвязи в продукте.
По итогам разработки аналитик у нас отвечает за сбор знаний — документирование продукта. Т.о. если результат работы разработчика — код и рабочее ПО, то результат работы аналитика — документация.