Описание процессов AS IS + TO BE ✍️
На этапе описания процессов AS IS + TO BE поисходит структурирование информации, полученной в ходе встреч, исследования предметной области и общения с сотрудниками компании. Это необходимый шаг. Именно благодаря ему определяется реальный объем работ и формируются требования на разработку - ТЗ.
ТЗ - техническое задание, договор с заказчиком.
В ходе описания процессов у аналитика возникает множетсво уточнений и вопросов к заказчику.
*Хороший тон: не заваливать заказчика сообщениями в мессенджере каждый час, а один раз на созвоне задать все сразу.
⚠️ Что я заметила? Всегда прохожу один и тот же цикл:
1. Придумала 10 вопросов.
2. Пока дописывала ТЗ и разбиралась в деталях - отбросила 8.
3. На встречах 1-2 раза в неделю обсудила вопросы и продемонстрировала макеты экранов, чтобы показать, что примерно будет результатом работ.
Получила ответы и комментарии. Прошла еще круг после встречи. И так до готовности ТЗ. Уровнь детализации зависит от вашей компании, проекта и заказчика.
Описание бизнес-процессов и понимание, как они затем лягут на систему - зона ответственности бизнес- и системных аналитиков 🙌
1. Запись машины в сервис по телефону через менеджера или на сайте, с SMS-уведомлениями клиента:
1.1. Первичная запись с регистрацией клиента и авто
1.2. Повторная запись старого клиента со старым авто
1.3. Повторная запись старого клиента с новым авто
1.4. Повторная запись - новый клиент со старым авто (изменен владелец)
1.5. Повторная запись - добавлен второй владелец
1.6. ... еще что-то подскажете или найдем по ходу дела)))
2. Получение информации о записи клиентом через сайт, по ссылке из SMS
3. Получение истории обслуживания автомобиля мастером и менеджером.
4. Отмена записи:
4.1. мастером,
4.2. менеджером,
4.3. клиентом на сайте.
5. Получение информации о клиенте:
5.1. Список авто.
5.2. История обращений - общая по всем авто.
5.3. Редактирование информации.
6. и так далее 🙌
Обратите внимание, как начинает пополняться Confluence⚡️
На этапе описания процессов AS IS + TO BE поисходит структурирование информации, полученной в ходе встреч, исследования предметной области и общения с сотрудниками компании. Это необходимый шаг. Именно благодаря ему определяется реальный объем работ и формируются требования на разработку - ТЗ.
ТЗ - техническое задание, договор с заказчиком.
В ходе описания процессов у аналитика возникает множетсво уточнений и вопросов к заказчику.
*Хороший тон: не заваливать заказчика сообщениями в мессенджере каждый час, а один раз на созвоне задать все сразу.
1. Придумала 10 вопросов.
2. Пока дописывала ТЗ и разбиралась в деталях - отбросила 8.
3. На встречах 1-2 раза в неделю обсудила вопросы и продемонстрировала макеты экранов, чтобы показать, что примерно будет результатом работ.
Получила ответы и комментарии. Прошла еще круг после встречи. И так до готовности ТЗ. Уровнь детализации зависит от вашей компании, проекта и заказчика.
Описание бизнес-процессов и понимание, как они затем лягут на систему - зона ответственности бизнес- и системных аналитиков 🙌
1. Запись машины в сервис по телефону через менеджера или на сайте, с SMS-уведомлениями клиента:
1.1. Первичная запись с регистрацией клиента и авто
1.2. Повторная запись старого клиента со старым авто
1.3. Повторная запись старого клиента с новым авто
1.4. Повторная запись - новый клиент со старым авто (изменен владелец)
1.5. Повторная запись - добавлен второй владелец
1.6. ... еще что-то подскажете или найдем по ходу дела)))
2. Получение информации о записи клиентом через сайт, по ссылке из SMS
3. Получение истории обслуживания автомобиля мастером и менеджером.
4. Отмена записи:
4.1. мастером,
4.2. менеджером,
4.3. клиентом на сайте.
5. Получение информации о клиенте:
5.1. Список авто.
5.2. История обращений - общая по всем авто.
5.3. Редактирование информации.
6. и так далее 🙌
Обратите внимание, как начинает пополняться Confluence
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤4🔥3
GetAnalyst_Шаблон_требований_описание_процессов_Запись_машины_в.pdf
161.7 KB
⭐️ Шаблон документации - бизнес-процессы, без технических деталей ⭐️
Результат работы - описание процессов AS IS+TO BE по проекту PorscheLab.
Ключевое:
🔶 Сейчас заполнена основная информация по процессам.
🔶 Выделены основные процессы. Нет сильного дублирования информации, есть ссылочность внутри документа.
🔶 Я не сторонник писать, чтобы было больше текста. Можно описать отдельно AS IS, отдельно TO BE, чтобы как по ГОСТу, но задача спроектировать систему и скорее отдать задачи в разработку, а не лить воду.
🔶 Меньше текста, короче предложения - лучше читаемость, больше счастья.
🔶 Шаблон может быть доработан: добавить критерии приемки, добавить User Story на место общего описания, добавить диаграммы, можно поменять формат описания сценариев (я использовала Use Case без тех деталей). Это один из возможных вариантов.
Сохраняем, пользуемся ⭐️ Есть, что добавить или можете поделиться своими шаблонами? Комментарии ❤️
Результат работы - описание процессов AS IS+TO BE по проекту PorscheLab.
Ключевое:
🔶 Сейчас заполнена основная информация по процессам.
🔶 Выделены основные процессы. Нет сильного дублирования информации, есть ссылочность внутри документа.
🔶 Я не сторонник писать, чтобы было больше текста. Можно описать отдельно AS IS, отдельно TO BE, чтобы как по ГОСТу, но задача спроектировать систему и скорее отдать задачи в разработку, а не лить воду.
🔶 Меньше текста, короче предложения - лучше читаемость, больше счастья.
🔶 Шаблон может быть доработан: добавить критерии приемки, добавить User Story на место общего описания, добавить диаграммы, можно поменять формат описания сценариев (я использовала Use Case без тех деталей). Это один из возможных вариантов.
Сохраняем, пользуемся ⭐️ Есть, что добавить или можете поделиться своими шаблонами? Комментарии ❤️
❤12👍4🔥1
На прошлой неделе мы опубликовали пост с подходом к решению задач для системного аналитика - порядок работы.
Собрали для вас список ссылок на посты с примерами 😉🔗
1. Знакомство с бизнес-контекстом и бизнес-требованиями, их уточнение
https://t.me/getanalysts/713
2. Определение ролей пользователей и приложений, которые будут задействованы
Указаны далее для каждого сценария
+ в работе с архитектурой, которая создается совместно с системным аналитиком на старте IT-проекта
https://t.me/getanalysts/734
https://t.me/getanalysts/735
https://t.me/getanalysts/739
https://t.me/getanalysts/742
https://t.me/getanalysts/746
https://t.me/getanalysts/747
https://t.me/getanalysts/749
3. Выделение и описание основных сценариев + 4. Проработка альтернативных сценариев
https://t.me/getanalysts/718
до https://t.me/getanalysts/720
5. Задачи на дизайнера
Примера постановки задачи нет. Если нужен, ставим ❤️ к посту
----
Про уровень детализации требований:
https://t.me/getanalysts/762
----
10. Задачи на фронтенд / мобильные
https://t.me/getanalysts/773
до https://t.me/getanalysts/776
-----
Прежде чем ставить задачи на бэкенд
https://t.me/getanalysts/790
-----
6. Определение сущностей и свойств + 7. Задачи на БД
https://t.me/getanalysts/794 (шаблон Confluence)
8. Задачи на подготовку тестовых данных
Примера нет. Просим тестировщиков обычным текстом заготовить данные в определенных форматах, если это необходимо. Не обязательный шаг.
9. Задачи на разработку методов Backend (API)
https://t.me/getanalysts/797 (шаблон Confluence)
11. Задачи на тестирование
Без примера 🙂 Исходная задача переходит в статус "Ready for Testing", либо создается подзадача на тестировщика.
12. Задачи на сохранение важных артефактов по документации после разработки - документация
Без примера 🙂 Это текстовое описание в Jira: указания что-где поправить, что дописать, и куда перенести, по окончании разработки.
Чтобы сохранить, пересылаем себе в ЛС! Делаем репосты коллегам и ставим 🔥
Собрали для вас список ссылок на посты с примерами 😉🔗
1. Знакомство с бизнес-контекстом и бизнес-требованиями, их уточнение
https://t.me/getanalysts/713
2. Определение ролей пользователей и приложений, которые будут задействованы
Указаны далее для каждого сценария
+ в работе с архитектурой, которая создается совместно с системным аналитиком на старте IT-проекта
https://t.me/getanalysts/734
https://t.me/getanalysts/735
https://t.me/getanalysts/739
https://t.me/getanalysts/742
https://t.me/getanalysts/746
https://t.me/getanalysts/747
https://t.me/getanalysts/749
3. Выделение и описание основных сценариев + 4. Проработка альтернативных сценариев
https://t.me/getanalysts/718
до https://t.me/getanalysts/720
5. Задачи на дизайнера
Примера постановки задачи нет. Если нужен, ставим ❤️ к посту
----
Про уровень детализации требований:
https://t.me/getanalysts/762
----
10. Задачи на фронтенд / мобильные
https://t.me/getanalysts/773
до https://t.me/getanalysts/776
-----
Прежде чем ставить задачи на бэкенд
https://t.me/getanalysts/790
-----
6. Определение сущностей и свойств + 7. Задачи на БД
https://t.me/getanalysts/794 (шаблон Confluence)
8. Задачи на подготовку тестовых данных
Примера нет. Просим тестировщиков обычным текстом заготовить данные в определенных форматах, если это необходимо. Не обязательный шаг.
9. Задачи на разработку методов Backend (API)
https://t.me/getanalysts/797 (шаблон Confluence)
11. Задачи на тестирование
Без примера 🙂 Исходная задача переходит в статус "Ready for Testing", либо создается подзадача на тестировщика.
12. Задачи на сохранение важных артефактов по документации после разработки - документация
Без примера 🙂 Это текстовое описание в Jira: указания что-где поправить, что дописать, и куда перенести, по окончании разработки.
Чтобы сохранить, пересылаем себе в ЛС! Делаем репосты коллегам и ставим 🔥
❤30🔥17👍6💯3
Проектирование БД - фундамент, на котором держатся системы.
Баг, про который я рассказала в первом видео по проекту PorscheLab, с которым я столкнулась в реально работающей системе:
У одного автомобиля может быть несколько владельцев, в разные периоды времени.
Разработчики этого не учли.
⚠️ Как его решают? Никак, методом "костылей".
Видимо история обслуживания автомобиля будет утеряна при переводе его на нового владельца.
Т.е. старое авто пересоздадут как новое, без истории обслуживания.
⚠️ Почему такое "решение"?
Плохо спроектированная БД, которая не учитывает этот Use Case - перевод одного авто между клиентами автосалона.
⚠️ В чем проблема БД?
Сейчас связь в реляционной БД:
▫️1 авто - 1 владелец,
▫️1 владелец - много авто.
= 1-ко-многим.
Нужно было:
▫️1 авто - много владельцев в разные периоды,
▫️1 владелец - много авто.
= многие-ко-многим.
Чтобы исправить ситуацию, минимум 10 задач на разработчиков, если не 20. Почему?! Что за задачи?!
Надо соблюдать обратную совместимость при проектировании БД. А лучше проектировать фундамент аккуратно, со взглядом в будущее.
У нас будет продуманная БД!
Смотрим новое видео-обучение:
2. Определение сущностей и проектирование логической модели БД
Баг, про который я рассказала в первом видео по проекту PorscheLab, с которым я столкнулась в реально работающей системе:
У одного автомобиля может быть несколько владельцев, в разные периоды времени.
Разработчики этого не учли.
⚠️ Как его решают? Никак, методом "костылей".
Видимо история обслуживания автомобиля будет утеряна при переводе его на нового владельца.
Т.е. старое авто пересоздадут как новое, без истории обслуживания.
⚠️ Почему такое "решение"?
Плохо спроектированная БД, которая не учитывает этот Use Case - перевод одного авто между клиентами автосалона.
⚠️ В чем проблема БД?
Сейчас связь в реляционной БД:
▫️1 авто - 1 владелец,
▫️1 владелец - много авто.
= 1-ко-многим.
Нужно было:
▫️1 авто - много владельцев в разные периоды,
▫️1 владелец - много авто.
= многие-ко-многим.
Чтобы исправить ситуацию, минимум 10 задач на разработчиков, если не 20. Почему?! Что за задачи?!
Надо соблюдать обратную совместимость при проектировании БД. А лучше проектировать фундамент аккуратно, со взглядом в будущее.
У нас будет продуманная БД!
Смотрим новое видео-обучение:
2. Определение сущностей и проектирование логической модели БД
YouTube
2. Системный анализ для проекта: определение сущностей и проектирование логической модели БД
Проект:
Система для Автосервиса.
Шаблоны документации Confluence для системных аналитиков:
https://t.me/getanalysts/828
Видео про БД с нуля:
https://www.youtube.com/watch?v=Y9V1h6IICL0
О сообществе:
https://getanalyst.ru/about
В видео:
✔️ Проектирование…
Система для Автосервиса.
Шаблоны документации Confluence для системных аналитиков:
https://t.me/getanalysts/828
Видео про БД с нуля:
https://www.youtube.com/watch?v=Y9V1h6IICL0
О сообществе:
https://getanalyst.ru/about
В видео:
✔️ Проектирование…
❤7👍2
В продолжение к видео о важности БД, я рекомендую посмотреть вебинар про связь базы данных и дизайна методов REST API (Backend) 👀
На видео я рассказывала про обратную совместимость. Изменение структуры хранения данных ведет к доработкам логики работы сервера....
На видео я рассказывала про обратную совместимость. Изменение структуры хранения данных ведет к доработкам логики работы сервера....
YouTube
Связь базы данных и дизайна REST API / Вебинар 17.02.2022
На вебинаре сделали модель базы данных и дизайн REST API:
— построили логическую модель базы данных
— описали JSON-объекты и методы REST API
— разобрали, какие бывают ошибки и как их избежать
Бесплатные вебинары GetAnalyst:
https://getanalyst.ru/events
…
— построили логическую модель базы данных
— описали JSON-объекты и методы REST API
— разобрали, какие бывают ошибки и как их избежать
Бесплатные вебинары GetAnalyst:
https://getanalyst.ru/events
…
🔥5❤1
Работа с опытными коллегами - это радость ❤️
Профессия системного аналитика - это непрерывная возможность для роста и обучения. Мы расширяем свой кругозор, знакомясь с разными проектами (банки, туризм, страхование, социальные сети, медицина и другие), улучшаем как технические навыки, так и навыки мягкого взаимодействия (soft skills) в ходе ежедневной работы.
Мы учимся через опыт взаимодействия с другими людьми. Про бизнес нам рассказывают заказчики, а вот сложные детали проектирования объясняют опытные коллеги разработчики и старшие аналитики.
Бывает, что приходится задавать самые странные вопросы. Иногда страшно, что спрашиваешь что-то глупое. Но все же... Они терпеливо рассказывают, объясняют, или отправляют что-то почитать 😄
Спасибо разработчикам, кто с удовольствием делится своим опытом, рассказывает про то, как надо делать, и как не надо. Спасибо старшим коллегам, которые также передают свой опыт и направляют в решении задач. И за то, что скидывают шаблоны, примеры постановок задач, чтобы было на что ориентироваться❤️
Ведь потом, через время, становится круто, когда начинаешь всех их по-настоящему понимать: говоришь на их языке, понимаешь технические детали проектов! Это не только ускоряет и упрощает процесс работы, но и придает уверенность!
Карьера в IT - это процесс непрерывного обучения и развития, и круто, когда есть возможность обучаться у лучших ❤️
Давайте мысленно вспомним тех, кто помогал или помогает нам расти, и выразим им огромную благодарность за то, что нам посчастливилось взаимодействовать с этими талантливыми людьми!
P.S. А еще можно написать ✉️
Профессия системного аналитика - это непрерывная возможность для роста и обучения. Мы расширяем свой кругозор, знакомясь с разными проектами (банки, туризм, страхование, социальные сети, медицина и другие), улучшаем как технические навыки, так и навыки мягкого взаимодействия (soft skills) в ходе ежедневной работы.
Мы учимся через опыт взаимодействия с другими людьми. Про бизнес нам рассказывают заказчики, а вот сложные детали проектирования объясняют опытные коллеги разработчики и старшие аналитики.
Бывает, что приходится задавать самые странные вопросы. Иногда страшно, что спрашиваешь что-то глупое. Но все же... Они терпеливо рассказывают, объясняют, или отправляют что-то почитать 😄
Спасибо разработчикам, кто с удовольствием делится своим опытом, рассказывает про то, как надо делать, и как не надо. Спасибо старшим коллегам, которые также передают свой опыт и направляют в решении задач. И за то, что скидывают шаблоны, примеры постановок задач, чтобы было на что ориентироваться❤️
Ведь потом, через время, становится круто, когда начинаешь всех их по-настоящему понимать: говоришь на их языке, понимаешь технические детали проектов! Это не только ускоряет и упрощает процесс работы, но и придает уверенность!
Карьера в IT - это процесс непрерывного обучения и развития, и круто, когда есть возможность обучаться у лучших ❤️
Давайте мысленно вспомним тех, кто помогал или помогает нам расти, и выразим им огромную благодарность за то, что нам посчастливилось взаимодействовать с этими талантливыми людьми!
P.S. А еще можно написать ✉️
❤16
Как простым языком объяснить, что приложение - это не просто красивые экраны? 🤓
Что за красивой картинкой пользовательского интерфейса с кнопками и полями ввода скрываются сервер, база данных, сервисы, микросервисы... И API 🙌
API - это программный интерфейс, который нужен для обмена данными между Frontend (UI - пользовательский интерфейс приложения) и Backend.
С API можно встретиться:
▫️ при постановках задач на Backend - сопоставление данных JSON-БД,
▫️при проектировании интеграций - когда нужно сопоставить данные между нашей БД и API чужой системы (P.S. сопоставление = маппинг), а еще протестировать в Postman.
И потом всю информацию по созданному API еще надо документировать - Swagger и опять же Postman в этом прекрасные помощники!
Сейчас один из наиболее популярных программных интерфейсов REST API. Умение его создавать с нуля - это ценный навык в сфере IT.
В моем опыте были как аналитики, так и разработчики, которым приходилось передавать опыт проектирования и стандартизации REST API в проекте, чтобы не было тут "так", а там "сяк". Чтобы не было хаоса в структуре запросов и с вашей системой было приятно взаимодействовать другим программистам.
И теперь я передаю этот опыт вам. Будем разбирать проектирование REST API на примере нашего проекта с автосервисом PorscheLab и не только, чтобы у вас были знания о принятых стандартах в отрасли и понимание, как это работает в реальной жизни! 🚀
Что за красивой картинкой пользовательского интерфейса с кнопками и полями ввода скрываются сервер, база данных, сервисы, микросервисы... И API 🙌
API - это программный интерфейс, который нужен для обмена данными между Frontend (UI - пользовательский интерфейс приложения) и Backend.
С API можно встретиться:
▫️ при постановках задач на Backend - сопоставление данных JSON-БД,
▫️при проектировании интеграций - когда нужно сопоставить данные между нашей БД и API чужой системы (P.S. сопоставление = маппинг), а еще протестировать в Postman.
И потом всю информацию по созданному API еще надо документировать - Swagger и опять же Postman в этом прекрасные помощники!
Сейчас один из наиболее популярных программных интерфейсов REST API. Умение его создавать с нуля - это ценный навык в сфере IT.
В моем опыте были как аналитики, так и разработчики, которым приходилось передавать опыт проектирования и стандартизации REST API в проекте, чтобы не было тут "так", а там "сяк". Чтобы не было хаоса в структуре запросов и с вашей системой было приятно взаимодействовать другим программистам.
И теперь я передаю этот опыт вам. Будем разбирать проектирование REST API на примере нашего проекта с автосервисом PorscheLab и не только, чтобы у вас были знания о принятых стандартах в отрасли и понимание, как это работает в реальной жизни! 🚀
👍14
REST API - самый популярный интерфейс обмена данными между системами ⚡️
Поэтому совсем скоро будет еще один проект, с которым мы начнем работать с нуля до постановок задач на REST API - на практическом курсе "Дизайн REST API", 6-ой поток! 🚀
Это уникальная программа, собранная на основе реального опыта в проектировании систем, в которой мы с коллегами в течение двух месяцев работаем над проектом, где нужно продумать всё: от требований и БД до REST API.
‼️ До 20 ИЮЛЯ открывается анкета предзаписи, по которой можно принять участие в программе на специальных условиях ‼️
АНКЕТА ПРЕЗДАПИСИ REST API
Фокус на практике, а результат - личный проект в Postman и Swagger, постановки задач в Jira+Confluece, которые пополнят портфолио 📈
Поэтому совсем скоро будет еще один проект, с которым мы начнем работать с нуля до постановок задач на REST API - на практическом курсе "Дизайн REST API", 6-ой поток! 🚀
Это уникальная программа, собранная на основе реального опыта в проектировании систем, в которой мы с коллегами в течение двух месяцев работаем над проектом, где нужно продумать всё: от требований и БД до REST API.
‼️ До 20 ИЮЛЯ открывается анкета предзаписи, по которой можно принять участие в программе на специальных условиях ‼️
АНКЕТА ПРЕЗДАПИСИ REST API
Фокус на практике, а результат - личный проект в Postman и Swagger, постановки задач в Jira+Confluece, которые пополнят портфолио 📈
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍1
Привет-привет! Продолжим работу над проектом с автосервисом 🚘
Для реализации функциональности веб-приложений мы будем реализовывать REST API. Он нужен для обмена данными с сервером.
Напоминание:
Часть клиента - экранные формы для пользователей.
Часть сервера - база данных и методы API. Базу данных мы уже делали.
REST API (Representational State Transfer) - это архитектурный стиль проектирования. Он использует протокол HTTP для общения между клиентом и сервером.
⚠️ Важный момент: REST - именно стиль, а протокол - HTTP.
Когда мы работаем над функциональными ребованиями, то часто применяем CRUD-модель, чтобы описать всю функциональность для каждой сущности в системе. CRUD представляет собой четыре основных функции, которые напрямую связаны с REST API:
1. CREATE (Создать):
Это процесс создания новой записи в системе.
REST API: метод POST.
Пример: когда владелец автомобиля создает заявку на обслуживание авто на сайте, сайт может отправить POST-запрос на сервер автосервиса для создания новой записи.
2. READ (Прочитать):
Это операция получения или чтения данных из системы.
REST API: метод GET.
Пример, когда владелец автомобиля хочет узнать статус ремонта своего автомобиля по уникальному номеру заявки на сайте, то сайт может отправить GET-запрос на сервер автосервиса с этого номера, чтобы получить ее статус.
3. UPDATE (Обновить):
Это операция обновления существующих данных в системе.
REST API: метод PUT или PATCH.
Пример: когда владелец автомобиля хочет изменить контактные данные или информацию об автомобиле, сайт может отправить PUT или PATCH запрос на сервер автосервиса.
4. DELETE (Удалить):
Это процесс удаления данных из системы.
REST API: метода DELETE.
Пример: когда владелец автомобиля хочет удалить свою заявку, чтобы удалить данные из БД автосервиса, сайт может отправить DELETE-запрос на сервер.
Важно помнить, что конкретное использование этих методов REST API может отличаться в зависимости от специфики API или системы. Даже POST иногда нужно использовать для получения данных 💻
Для реализации функциональности веб-приложений мы будем реализовывать REST API. Он нужен для обмена данными с сервером.
Напоминание:
Часть клиента - экранные формы для пользователей.
Часть сервера - база данных и методы API. Базу данных мы уже делали.
REST API (Representational State Transfer) - это архитектурный стиль проектирования. Он использует протокол HTTP для общения между клиентом и сервером.
⚠️ Важный момент: REST - именно стиль, а протокол - HTTP.
Когда мы работаем над функциональными ребованиями, то часто применяем CRUD-модель, чтобы описать всю функциональность для каждой сущности в системе. CRUD представляет собой четыре основных функции, которые напрямую связаны с REST API:
1. CREATE (Создать):
Это процесс создания новой записи в системе.
REST API: метод POST.
Пример: когда владелец автомобиля создает заявку на обслуживание авто на сайте, сайт может отправить POST-запрос на сервер автосервиса для создания новой записи.
2. READ (Прочитать):
Это операция получения или чтения данных из системы.
REST API: метод GET.
Пример, когда владелец автомобиля хочет узнать статус ремонта своего автомобиля по уникальному номеру заявки на сайте, то сайт может отправить GET-запрос на сервер автосервиса с этого номера, чтобы получить ее статус.
3. UPDATE (Обновить):
Это операция обновления существующих данных в системе.
REST API: метод PUT или PATCH.
Пример: когда владелец автомобиля хочет изменить контактные данные или информацию об автомобиле, сайт может отправить PUT или PATCH запрос на сервер автосервиса.
4. DELETE (Удалить):
Это процесс удаления данных из системы.
REST API: метода DELETE.
Пример: когда владелец автомобиля хочет удалить свою заявку, чтобы удалить данные из БД автосервиса, сайт может отправить DELETE-запрос на сервер.
Важно помнить, что конкретное использование этих методов REST API может отличаться в зависимости от специфики API или системы. Даже POST иногда нужно использовать для получения данных 💻
👍13🔥6❤1
Время квиза! Какой метод используется для подтверждения заявки на обслуживание менеджером?
Anonymous Quiz
45%
POST
16%
GET
38%
PATCH
1%
DELETE
Какой метод используется для отображения списка заявок клиентов на экране у менеджера?
Anonymous Quiz
8%
POST
89%
GET
2%
PUT
1%
PATCH
Какой метод используется для просмотра деталей существующей заявки менеджером?
Anonymous Quiz
8%
POST
85%
GET
4%
PUT
2%
PATCH
Какой HTTP метод используется для отмены заявки на обслуживание?
Anonymous Quiz
8%
POST
24%
PATCH
27%
DELETE
41%
PATCH и DELETE
Какой метод используется для добавления автомобиля к существующему клиенту?
Anonymous Quiz
28%
POST, PATCH
22%
POST, PUT
37%
POST, PATCH, PUT
14%
POST
❤7
Дизайн REST API, как и дизайн пользовательского интерфейса UI: война за цвет кнопки будет бесконечна, если не ввести хотя бы минимальные правила по работе дизайнера 😄
Представьте, что в проект пришел дизайнер и ему задачу: "Сделай дизайн экрана размещения заявки для приложения менеджера".
При этом:
1. Не дали гайдлайн - набор правил разработки дизайна (лого, цвета, шрифты, размеры, вид и цвет кнопок, от чего зависит цвет кнопок...)
2. Не показали остальные экраны работающего приложения.
3. И не рассказали про адаптивную верстку, чтобы не только под компьютер, но и под мобильные устройства все было хорошо.
Без этих пунктов будет утерян контекст задачи дизайнера UI.
Без него он может сделать свою работу в соответствии с ожиданиями конечных пользователей.
Возможно дизайнер даже даст крутое решение. Но скорее всего оно не впишется в систему, т.к. нет контекста.
🙈 Дизайнер не может решать свою задачу в отсутсвии контекста: ему нужно увидеть хотя бы часть системы или гайдлайны, если проект с нуля, чтобы получить решение, которое будет гармонично вписываться в систему.
В работе системного аналитика и разработчиков так же -
❌ если гайдлайна - стандарта по дизайну методов REST API,
❌ или примера рабочих методов API в системе,
❌ нет понимания, как будет работать логика метода,
то выбрать ответ квиза становится затруднительно.
Полагаю, что меня сейчас поняли опытные в REST API аналитики.
А для тех, у кого пока мало опыта, квиз мог показаться совсем элементарным, с учетом поста перед ним 🙃
Много комментариев накопилось к заданиям. И это круто! Разброр каждого вопроса будет 👌
Представьте, что в проект пришел дизайнер и ему задачу: "Сделай дизайн экрана размещения заявки для приложения менеджера".
При этом:
1. Не дали гайдлайн - набор правил разработки дизайна (лого, цвета, шрифты, размеры, вид и цвет кнопок, от чего зависит цвет кнопок...)
2. Не показали остальные экраны работающего приложения.
3. И не рассказали про адаптивную верстку, чтобы не только под компьютер, но и под мобильные устройства все было хорошо.
Без этих пунктов будет утерян контекст задачи дизайнера UI.
Без него он может сделать свою работу в соответствии с ожиданиями конечных пользователей.
Возможно дизайнер даже даст крутое решение. Но скорее всего оно не впишется в систему, т.к. нет контекста.
🙈 Дизайнер не может решать свою задачу в отсутсвии контекста: ему нужно увидеть хотя бы часть системы или гайдлайны, если проект с нуля, чтобы получить решение, которое будет гармонично вписываться в систему.
В работе системного аналитика и разработчиков так же -
❌ если гайдлайна - стандарта по дизайну методов REST API,
❌ или примера рабочих методов API в системе,
❌ нет понимания, как будет работать логика метода,
то выбрать ответ квиза становится затруднительно.
Полагаю, что меня сейчас поняли опытные в REST API аналитики.
А для тех, у кого пока мало опыта, квиз мог показаться совсем элементарным, с учетом поста перед ним 🙃
Много комментариев накопилось к заданиям. И это круто! Разброр каждого вопроса будет 👌
❤🔥6🔥3👍2👀2
В комментариях Алексей объяснил, почему логичным выглядит именно PATCH:
PATСН выглядит логичным, если на самом деле имеется в виду изменение статуса существующей заявки.
------
Прилетает запрос PATCH на endpoint вида
PATCH /api/v1/orders/{orderId}
В теле запроса идет JSON в духе
{ "orderStatus": "accepted" }.
В ответ на запрос возвращаем 200 OK с JSON с полным набором ключей и значений.
------
Почти полностью согласна с Алексеем, который написал в комментариях пояснение:
------
Прилетает запрос PATCH на endpoint вида
PATCH /api/v1/order/{orderId}/confirm
или
PATCH /api/v1/order/{orderId}/changeStatus
или
PATCH /api/v1/order/{orderId}/changeStatus
В тело JSON менеджер добавляет параметры заявки, которые мог уточнить у клиента автосервиса по телефону, в процессе разговора - комментарий о странном звуке двигателя, добавить гос. номер машины, поменять время записи и другие пожелания.
Возможно частичное или полное изменение заявки после звонка клиенту.
В ответ на запрос возвращаем 200 OK с JSON с полным набором ключей и значений.
------
Мы выбираем PATCH, а не PUT или POST, так как по логике работы системы я, как системный аналитик, закладываю:
1. Менеджер подтверждает существующую заявку пользователя - изменяет ее статус с new на confirmed (approved).
То есть создания нового объекта данных нет. Есть изменение существующей заявки, которую ранее создал клиент автосервиса, и дополнение ее данными собранными в звонке от клиента, при необходимости.
2. Для изменения я выбираю PATCH, а не PUT, потому что нужно частичное изменение ресурса - объекта данных "Заявка". Возможно после звонка надо будет только статус поменять и всё, а тело запроса JSON останется пустым в моем примере метода API.
Многие проголосовали за POST. Почему это тоже может быть верно?
Продолжение скоро 🔽
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍1
3. Можно было бы взять POST в случае если:
1️⃣ Когда клиент оставляет заявку, создается черновик - объект данных "Черновик заявки" / "Запрос клиента" / "...".
2️⃣ Когда менеджер подтверждает созданный клиентом черновик, на уровне БД создается новая сущность "Заявка" на основе данных из "Черновик заявки".
Так как идет создание нового объекта данных, то правильно использовать POST.
Вижу дизайн так:
POST /api/v1/order/{draftId}
Ответ на запрос - HTTP-201 - заявка создана.
Как один из возможных вариантов.
POST может работать в этом контектсе и может быть правильным ответом. Но я склоняюсь к PATCH, т.к. не хочу лишние сущности.
PUT на создание записи в БД в этой задаче не рекомендую использовать, т.к. поддержка оффлайн режима, генерация уникальных идентификаторов на клиенте и идемпотентность здесь не нужны. Но это отдельная большая история... 🙂
Есть еще предложения по решению этой задачи - комментарии! А еще варианты решений точно есть 🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡7
В случае, если нам нужно ТОЛЬКО ПРОЧИТАТЬ ДАННЫЕ ИЗ БД, и не надо их записывать или менять в процессе чтения, то мы используем метод GET.
Просмотр списка, просмотр подробной информации о записи из списка, отображение, получение - это все про запрос данных из Базы двнных без их изменения, без записи данных в БД.
POST - может быть использован, только если мы где-то под капотом в процессе чтения еще и записываем данные в БД (например в журна запроса данных по заявкам клиентов). Но такую функциональность мы не планировали.
PUT и PATCH - для изменения ресурсов - объектов данных. Мы в процессе чтения читаем, изменений нет 🙂 Хотя... Если нужно в мессенджере сменить галочки у сообщения на "прочитано" 😅 Но это не наша история по логике!
Так что при желании можно все 4 метода использовать. Но все же, с точки зрения здравого смысла и реальной логики, которую я хочу заложить в метод REST API для автосервиса - это GET. Т.к. нам всего лишь надо прочитать данные из БД и собрать их в красивый JSON, ничего лишнего 🙌
Просмотр списка, просмотр подробной информации о записи из списка, отображение, получение - это все про запрос данных из Базы двнных без их изменения, без записи данных в БД.
POST - может быть использован, только если мы где-то под капотом в процессе чтения еще и записываем данные в БД (например в журна запроса данных по заявкам клиентов). Но такую функциональность мы не планировали.
PUT и PATCH - для изменения ресурсов - объектов данных. Мы в процессе чтения читаем, изменений нет 🙂 Хотя... Если нужно в мессенджере сменить галочки у сообщения на "прочитано" 😅 Но это не наша история по логике!
Так что при желании можно все 4 метода использовать. Но все же, с точки зрения здравого смысла и реальной логики, которую я хочу заложить в метод REST API для автосервиса - это GET. Т.к. нам всего лишь надо прочитать данные из БД и собрать их в красивый JSON, ничего лишнего 🙌
👌4👍3
This media is not supported in your browser
VIEW IN TELEGRAM
Кейсы, которые не были учтены на этапе аналитики — это одни из самых дорогих ошибок для компании.
Если аналитик что-то не учёл и проектная команда создала ПО с «дырами в логике», продукт придется откатывать до этапа аналитики, а это большие затраты для компании 🙈
Подписывайтесь на нашу запрещенную соцсеть, чтобы увидеть еще больше крутого контента 😉
Если аналитик что-то не учёл и проектная команда создала ПО с «дырами в логике», продукт придется откатывать до этапа аналитики, а это большие затраты для компании 🙈
Подписывайтесь на нашу запрещенную соцсеть, чтобы увидеть еще больше крутого контента 😉
🤣8😁3