Как понять, что мы проектируем REST API правильно? Никак. Смотреть на публичную API‑документацию крупных систем, диссертацию Роя Филдинга, или на то, что уже есть в проекте. И исходя из этого принимать решения о том, как будут выглядеть новые REST API методы.

В этой статье я хочу представить результаты исследований REST API сервисов управления задачами Trello и Todoist, чтобы показать, какие решения являются хорошими стандартами проектирования, а какие нет, но всё равно применяются на практике.

Сделаю это с помощью спорных вопросов, которые вам могут задать на собеседовании, и которые могут встретиться в реальной работе.

В этой статье вы найдёте пошаговую инструкцию по тестированию открытого GraphQL API через Postman.

Статья постоена по принципу: сначала практика -> потом теория.

Материал будет полезен системным аналитикам, разработчикам и тестировщикам, которые хотят разобраться в структуре запросов и ответов, понять ключевые принципы работы с GraphQL, подходы к его проектированию, а также научиться интегрироваться с сервисами, предоставляющими GraphQL интерфейс для взаимодействия.

Если возникает вопрос об описании архитектуры системы, то есть несколько основных решений где и как это сделать. Среди популярных нотаций для визуализации схемы архитектуры можно выбрать C4, разработанную Саймоном Брауном.

В этой статье я хочу показать пример применения нотации C4, который вы сможете использовать как ориентир в своей работе, а также инструменты для её создания. В частности, выделяю Structurizr.

Статья полезна для системных аналитиков, архитекторов, разработчиков, менеджеров проектов и тех, кто участвует в создании и принятии решений по организации архитектуры проекта.

Проектирование REST API - это процесс создания дизайна методов обмена данными. Дизайн - это субъективное. У одних "так", у других "сяк". А кто прав? Иногда все, а иногда нет.

Можно ли сделать в проекте все методы POST? Как правильно именовать эндпоинты - ед. число или мн. число (/user или /users)? Можно ли использовать метод POST для получения данных? ...

Холиварные вопросы! Вкусовщина! Давайте разбираться!

Берём в работу новую задачу или проект. Начинаем со сбора бизнес-требований. Потом архитектура системы и влияние требований на нее, БД, API, интеграции. И вот, в процессе разработки выясняется, что в требованиях опять что-то не учли. Что может быть хуже?

Может, коллеги! Когда через пол года вам же приходится возвращаться к задаче и вы понимаете, что требования к развитию системы по словам разработчиков нереализуемы. Как так?! Элементарная же задача! А потом мне показывают БД. И тут я понимаю, что пришло время делать выбор: дорого переделывать или "костыли" подойдут.

Один раз столкнувшись с такой ситуацией, больше не хочется оставлять без внимания базу данных, даже если её проектированием должны были заниматься разработчики.

Лучший способ понять теорию — получить больше опыта в разных проектах. Для системных и бизнес‑аналитиков я постоянно показываю подходы к работе через публикацию разборов задач: БД, API, Интеграции, требования, и все, что связано с проектированием систем.

После публикации поста общий подход к работе с задачами системного аналитика, меня попросили показать, как его применить на практике. Собрала примеры постановок задач и описаний системы по одному из проектов. Здесь постараюсь кратко изложить его. А в конце оставлю ссылку на подборку примеров, которые можно посмотреть и переиспользовать в своих проектах.

В этой статье я хочу дать вам структурированную информацию о навыках и возможностях карьерного роста для системных аналитиков. С её помощью начинающие и опытные системные аналитики смогут получить ориентиры и построить собственную карту развития.

Каждый системный и бизнес-аналитик проходит "боевое крещение" в своей карьере, когда получает первую задачу на проектирование интеграций. Звучит серьезно и сложно. И это так, если ни разу не работал с таким видом задач.

С чего начать и куда смотреть при работе с задачами на интеграции? Давайте воспользуемся пошаговой инструкцией, чтобы понять план действий.

Мы привыкли к тому, что в российских командах разработки есть позиция системного аналитика.

А есть ли системные аналитики за рубежом? Что входит в их обязанности? Востребованные ли это специалисты?

В этой статье я показываю результаты анализа рынков труда США и Германии.

Архитектура ПО — это Вселенная. Все очень сложно, но если все правильно, то все невероятно просто. Шаг за шагом познаю что и как. Ищу лучшие практики и шаблоны. В конечном счете, в очередной раз делаю одно и то же заключение:

Изученные правильные практики и шаблоны проектирования - лишь вектор, который вдохновляет на новые красивые и уникальные решения.

Здесь нет примеров хорошей архитектуры, советов как должно быть и как правильно. Я просто хочу зафиксировать мысли, которые надо не забывать воспроизводить при решении очередной задачи.

Сейчас нужно написать краткое введение о том, что важно проводить аналитику для задачи на разработку: оценить влияние изменений, проработать все возможные сценарии и т.д.

Понимание сути и объема задачи должно появиться до первой строки кода. Писать сколь угодно емкое введение о важности этого этапа можно долго, но кажется, что все мы понимаем, что самые дорогие ошибки — на этапе проектирования.

Разработчику с проектированием и документированием решения задачи помогает аналитик.

С чего начинается IT-стартап и вообще любая новая задача в IT-проекте? С идеи и вопросов к себе