Ну... Если это помогает клиентам разобраться в проблеме, то почему бы и да. Но видимо Ваш 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) Проектировать вместо разработчика можно, но не нужно. Иначе получится ровно то, что Вы написали: кодеры и аналитики.
В процессе проектирования участвует команда, что позволяет не замыкать разработку и знания о продукте на одном человеке и проявлять творческие начала всем. Аналитик не блокирует разработку.
Системный аналитик — участник процесса проектирования. Он больше погружается в анализ и описание процессов, сценариев работы с системой, меньше в проектирование технической реализации, но умеет грамотно изложить ее и зафиксировать решение, анализирует взаимосвязи в продукте.
По итогам разработки аналитик у нас отвечает за сбор знаний — документирование продукта. Т.о. если результат работы разработчика — код и рабочее ПО, то результат работы аналитика — документация.
Все так. В нашей компании есть роль заказчика, и он не один. Это владельцы продуктов — подсистем МоегоСклада.
В точку! Это можно добавить как один из положительных результатов по итогам внедрения документирования: требований, результатов проектирования и реализации.
Тут еще можно добавить про уровни детализации. На этапе ТЗ с заказчиком, важно сделать проработку того, что видит пользователь, какие есть бизнес-правила и ограничения, и так далее. Все это — бизнес-требования. Они идут в основу ТЗ и это обычно то самое, что Заказчик осознанно читает и подписывает.
Но на бизнес-требованиях документирование не должно кончаться. Нужно проработать архитектурное решение, его гибкость, масштабируемость, описать его. Проработать поведение системы. Много деталей, которые влияют на результат.
Убедить заказчика в том, что проектирование и документирование нужны — не сложно. Достаточно хотя бы задать вопрос: «Вы же потом планируете развиваться?». Но по неизвестным причинам я часто слышу: «У нас нет документации», «У нас нет времени на это». Почему за обеспечение качества не хотят браться? Подозрение, что экономят (конечно, ошибочно думают, что экономят!).
Зачем жертвовать качеством, строить странные процессы разработки, жить без группы тестирования и т.д., если это приводит к печальным последствиям — огромнейшая тема для обсуждения! Ей нужно посвящать отдельную статью. Но такое сегодня все еще есть!
Я безмерно восхищаюсь, что в нашем продукте обеспечивают качество, следят за этим и стремятся к постоянному совершенствованию процесса разработки.
Но есть рынок труда. Есть другие компании и их сотрудники, с которыми общаешься на конференциях, собеседованиях, в тематических чатах, и видишь, что в их компаниях такой задачи как «документирование» нет, но им этого явно не хватает. Людям не хватает уверенности и аргументов для убеждения своего заказчика, что надо строить процессы правильно!
До последней строки поддерживаю Ваш комментарий. Надеюсь, что много читателей доберутся до него и извлекут для себя убедительных аргументов: «Документация нужна»!
Поддерживаю!
Но пока это упорно игнорируется, особенно бизнес-заказчиками. Только опыт «наступить на грабли» заставляет немного задуматься.
Если продукт свой, заказчика нет и нужно запустить быстро, без выделения времени на описание, то, например, встроенные комментарии в код спасают. Это нельзя назвать проектной документацией, потому что к ней не все имеют доступ, а только разработчики.
Главная мысль статьи — смотреть на масштаб проекта. Не всегда экономически целесообразно сразу выделять ресурс на документирование и заказчика не убедить.
Рассмотрим документирование требований — договор между заказчиком и разработчиком. Требования, конечно, тоже документация, но не всегда в том объеме, чтобы помочь разобраться — как работает система. К тому же, в ходе разработки, требования имеют свойство меняться и уточняться, не всегда эти изменения и уточнения фиксируются в том самом оригинале договора и знания теряются. Такая вот грустная практика до сих пор существует.