Что мы видим на рынке: в одной компании требуют 20 пунктов из этого списка, в другой 12. И пересекаются у них 7 пунктов - ядро профессии, а остальное отличается.
То, что хотели и хотят от системного аналитика диктует работодатель. И увы, если работодатель не хочет нанимать дизайнера и считает, что аналитик+разработчики норм справятся, то это грустно. Но это до сих пор есть. На аналитика и менеджерскую работу порой делигируют... Иногда аналитика просят лезть в код и разбираться.... Это есть. И если вы с таким не встретились, то это ооочень хорошо!
“Исследование предметной области” не значит, что аналитику нужно пройти мединститут. Это про умение быстро погружаться в тему, задавать правильные вопросы и проверять понимание у экспертов, чтобы корректно описывать требования.
Есть сложные домены, где особенно ценятся аналитики с сильным бэкграундом (например, в финтехе, биотехе,торговле). Но опять же, в таких командах часто работают в связке: системный аналитик + профильные эксперты
Спасибо за обратную связь! LLM-ка для причёсывания и лёгкости чтения материала конечно же использовалась :) Но много часов было потрачено на проработку материала, сбор собственных мыслей в кучу и создание схем
Добрый день! Если вы про эту часть схемы, то тут никакого преобразования нет - это обычная интеграция систем :)
Микросервис платежей работает на gRPC, т.е. чтобы его вызывать, надо использовать это вид API. Система платежей - внешняя платежная система как ЮКасса, Сбер Пэй, и другие. В микросервисе платежей часть gRPC методов интеграционные. И при обработке gRPC запроса на создание платежа, который приходит от API Gateway, микросервис платежей "под капотом" вызывает внешнюю платежную систему по её REST API. Тут преобразования со стороны API Gateway нет. Тут обычный маппинг данных для интеграции будет в логике кода микросервиса платежей.
Ну... Если это помогает клиентам разобраться в проблеме, то почему бы и да. Но видимо Ваш 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 и архитектуры ситуация такая же. Без опыта и понимания контекста реального проекта пока нельзя - нужна работа системного аналитика
Сертификаты - очень нужные штуки в зарубежных компаниях. Это для галочки много где требуется. Но не везде. Считаю, что собеседование и умение применять знания решают больше, чем наличие бумажки. А так - сертификация полезна: можно разложить знания по полочкам и достать из дальних углов мозга то, что давно не использовалось.
Комментарий на 100% в точку.
Навыки, которые в статье, собраны из:
личного опыта работы
анализа более 100 вакансий
интервью с аналитиками
Что мы видим на рынке: в одной компании требуют 20 пунктов из этого списка, в другой 12. И пересекаются у них 7 пунктов - ядро профессии, а остальное отличается.
То, что хотели и хотят от системного аналитика диктует работодатель.
И увы, если работодатель не хочет нанимать дизайнера и считает, что аналитик+разработчики норм справятся, то это грустно. Но это до сих пор есть.
На аналитика и менеджерскую работу порой делигируют... Иногда аналитика просят лезть в код и разбираться....
Это есть.
И если вы с таким не встретились, то это ооочень хорошо!
“Исследование предметной области” не значит, что аналитику нужно пройти мединститут. Это про умение быстро погружаться в тему, задавать правильные вопросы и проверять понимание у экспертов, чтобы корректно описывать требования.
Есть сложные домены, где особенно ценятся аналитики с сильным бэкграундом (например, в финтехе, биотехе,торговле). Но опять же, в таких командах часто работают в связке: системный аналитик + профильные эксперты
Спасибо за обратную связь! LLM-ка для причёсывания и лёгкости чтения материала конечно же использовалась :) Но много часов было потрачено на проработку материала, сбор собственных мыслей в кучу и создание схем
Добрый день! Если вы про эту часть схемы, то тут никакого преобразования нет - это обычная интеграция систем :)
Микросервис платежей работает на gRPC, т.е. чтобы его вызывать, надо использовать это вид API.
Система платежей - внешняя платежная система как ЮКасса, Сбер Пэй, и другие.
В микросервисе платежей часть gRPC методов интеграционные.
И при обработке gRPC запроса на создание платежа, который приходит от API Gateway, микросервис платежей "под капотом" вызывает внешнюю платежную систему по её REST API. Тут преобразования со стороны API Gateway нет. Тут обычный маппинг данных для интеграции будет в логике кода микросервиса платежей.
Надеюсь удалось объяснить.
Больше про интеграции рассказывала тут - подкаст про интеграции: https://getanalyst.ru/podcast/problemy-v-rabote-s-zadachami-na-integracii (https://t.me/kateit/25)
Здравствуйте! Спасибо за комментарий, правку внесла :)
Спасибо! Обязательно повторите и вы эту работу на практике, это полезный тренажер, максимально приближенный к реальной работе :)
Благодарю за обратную связь! :)
Нужны шаблоны, как для 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 и архитектуры ситуация такая же. Без опыта и понимания контекста реального проекта пока нельзя - нужна работа системного аналитика
Исправлено! :)
Благодарю за внимательность! Исправлено
Благодарю! Исправлено
Сертификаты - очень нужные штуки в зарубежных компаниях. Это для галочки много где требуется. Но не везде. Считаю, что собеседование и умение применять знания решают больше, чем наличие бумажки.
А так - сертификация полезна: можно разложить знания по полочкам и достать из дальних углов мозга то, что давно не использовалось.