Я всегда спрашиваю: какая цель?

И вот что рассказывали мне в GetAnalyst в октябре:
◾️Хочется сменить проект, но на текущем месте работы нет возможности получить нужный опыт
◾️Ничего не знаю про REST API. Хочу освоить, чтобы меня повысили
◾️Структурировать знания и пополнить резюме новыми навыками
◾️Необходимо углубленное понимание как проектировать дизайн REST API
◾️Освоить новые инструменты: Postman и Swagger

🏢 Компании выбрают обучение для своих сотрудников, чтобы сохранить их внутри компании за счет роста, повысить качество работы, внедрить корпоративную культуру по разработке REST API и снизить количество ошибок разработки, которые влияют на стоимость проектов.

Моя цель - доводить вас до результата. Поэтому любое обучение я начинаю с постановки целей.

Дизйн REST API — это продвинутый навык для опытных аналитиков, для junior-разработчиков. Глубокое понимание этой темы помогает лучше разобраться с архитектурой приложений, Backend и Frontend, как мобильные приложения и сайты общаются с сервером, как получать данные из БД и отображать их пользователям, интеграции между системами во всех возможных комбинациях.

REST API добавляет в резюме не только навык "REST API", но и следом подтягиваются "JSON", "Понимание архитектуры приложений на базовом уровне", "Postman", "Swagger", "OpenAPI".

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

Можно разобраться с проектированием REST API самостоятельно. В среднем на самостоятельное освоение уходит от 6 месяцев до 1 года. И все нюансы всплывают только когда начинаешь делать практику.

Я приглашаю вас разобраться с этим навыком за 2 месяца вместе со мной, в GetAnalyst:

🎓 Дизайн REST API, 18 апреля
🟢 Информация и запись по ссылке
Следующий поток в августе-сентябре

Профессиональный рост и интересные проекты начинаются с обучения. Делайте шаги вперед в своем развитии, любыми способами. У вас все получится! 🚀

Не успели узнать про:
• создание методов REST API с нуля,
• погружение в фишки Postman с документированием по OpenAPI,
• создание Mock-сервера?

Тогда ждем вас:
🗓 8 апреля (сб) в 15:00 (Мск)

Регистрируйтесь и приходите на повтор практикума:
🔑 5 принципов дизайна REST API
👉 Регистрация по ссылке

Сможете пересмотреть его и повторить то, что мы делали в эфире еще раз. Было очень много крутой информации! Полезно посмотреть второй раз и закрепить результат!

Когда впервые сталкиваешься с задачей проектирования REST API, особенно имея опыт работы с проектированием интеграций, то кажется, что это просто.

Но на деле можно столкнуться со следующими проблемами:

✖️ В одном месте эндпоинты /user, а в другом /documents. А как правильно?
✖️ В одном месте метод называется POST /createDocument, а в другом POST /user
✖️ А почему у нас в API все методы POST
✖️ Для метода на изменение данных выбрать PUT или PATCH?
✖️ А мы тут удалить документ из списка хотим. На экране его скроем, а в базе оставим. Что брать? PUT, PATCH или DELETE для API?
✖️ А в JSON мы делаем "userId" или "user_id" или "user-id"?
✖️ А если у нас пустой список, то возвращаем [] или HTTP-404? И вообще в каком формате у нас ошибки?

И это лишь малая часть вопросов при разработке дизайна REST API. Нюансов много. И вариантов решений всегда несколько.

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

Чтобы разработать гайд, я начала с того, что изучила лучшие практики дизайна API и уже существующие API на проекте. Со всеми этими знаниями я начала разрабатывать его. Гайд по дизайну REST API включал в себя понятные правила, которые помогали определить структуру запросов и ответов. Например, рекомендации по именованию ресурсов, выбору типов методов и кодов ошибок.

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

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

Я считаю, что гайд по дизайну API - неотъемлемая часть процесса разработки. И я помогаю командам и компаниям его прорабатывать, а также делюсь этими знаниями со своими учениками.

Продолжим про подводные камни ChatGPT 🤖

4. ChatGPT придумывает 🤭
Хи-хи, ха-ха. Но я столкнулась с неприятной ситуацией. Я на пресэиле проекта радовалась, что у платформы, с которой надо интегрироваться, есть REST API. В гугле не могла найти, а ChatGPT нашел.

Когда запрашивала ссылку на ресурс, откуда ChatGPT берет API-документацию, то он вел меня на реальный сайт разработчика платформы. Но с ходу нужную API-документацию найти не могла, т.к. там много-много C# кода и других деталей. Сайт этот видела раньше, своим первичным анализом REST не находила.

Проверила API-документации от ChatGPT, увидела, что всех данных хватает, и их даже больше, чем нужно. Про авторизацию инстукцию запросила, где API-ключ получить. Все было правдоподобно. И... Когда начала тестировать через Postman, оказалось, что никакого REST API на самом деле нет. Тех поддержка позже подтвердила.

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


5. Невозможно установить источник информации
В случае с API-документацией ChatGPT дал мне ссылку на сайт разработчика. Хотя по факту документации на нем не было.

Чуть позже я была шокирована выдаваемой информацией по проектированию. Каждый раз, получая от ChatGPT спорную информацию, которая не бьется с моим опытом, приходилось идти в Google. И не было источников данных - не могла найти их, т.к. он перефразирует все. Он должен оперировать данными из сети Интернет. Но какими, как он собирает результат?
Его "креативность" не позволяет проверить текст на правду-ложь.

Проверить, насколько правдивые данные он выдал, можно только командой "Это неверно, это выглядит как ошибка. Откуда такие данные?". Он либо подтвержит, что ошибся. Либо усомнится в своем ответе :) Говорят.ю его переучивали уже на 1+1=3.

Постмотрите на пост про безопасность REST и комментарии к нему. Это был один из тестов, когда я использовала его в помощь для ведения канала. Придумал интересно, как просила, но не правду. По факту HTTPS и SSL/TLS обеспечивают шифрование. Методы REST ни на что не влияют. Но ChatGPT придумал иначе. В конечном счете подтверждения нет.
Есть шанс, что если ChatGPT выдает 10 полезных ответов, а потом присылает ошибку, то мы даже не заметим ее. Так работает со всеми источниками информации. Наш мозг и поведение так устроены. Мы быстро заучиваем сценарии, быстро привыкаем к удобствам. И нам тяжело от них отказываться.
Чтобы увидеть некоторые ошибки проектирования ChatGPT, должен быть большой опыт.

*С описанием бизнес-процессов, Use Cases, User Story, UML и BPMN, работой по алгоритму, он справляется хорошо: явно видно, к чему приложить руку на доработку. А вот в моментах с техническим проектированием. при отсутствии должного опыта, ошибку вам не распознать


6. Машинный текст. Мертвый язык
Не буду много комментировать. Но когда я запрашиваю у него помощь с текстом для поста или для ТЗ, то все равно переписываю. Не всегда мой лайфхак со вставкой prompt "в стиле + "мой текст" " срабатывает.


7. В маркетинговом бизнесе мы приняли решение запретить использовать ChatGPT для генерации текстов
Соучредитель сказал: мы не будем делать статьи через ChatGPT, т.к. мы занимаемся маркетингом и наша задача быть креативнми, мыслить своей головой, а не выдавать роботизированную информацию. Это может сыграть злую шутку в будущем.
Теперь тексты от сотрудников мы прогоняем через AI detector.


Итог и мое мнение:
Использовать ChatGPT можно, но очень внимательно. И прежде, чем его использовать как ускоритель и помощника в работе, необходимо самому глубоко разобраться в темах.

ChatGPT - младший аналитик. Используйте его в своей работе, но помните про ошибки. Они есть вплоть до версии 4. И думаю, что не смотря на быстрое развитие и хайп, он еще долго будет обучаться, чтобы давать 100% точные ответы 🤨

❗️Уже через 15 минут❗️

📹Повтор онлайн-практикума Екатерины Ананьевой:
5 главных принципов дизайна REST API

Подключайтесь по ➡️ ссылке

Про культуру в компаниях разработки

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

Но если вы попадаете в любой новый проект, но при этом с ходу нет чёткого понимания, как поставить задачу разработчику, то результат будет «каким-то»… Всегда важно проявить открытость и честность по отношению к команде, с которой работаешь. Не стоит бояться задавать вопросы, уточнять, где-то переспрашивать.

Существует поговорка:
«Глуп не тот, кто не знает, а тот, кто не спрашивает»
Согласны?

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

Для нас аналитиков особенно важно взаимодействовать и общаться с разработчиками. Понимать их язык.

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

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

Успешное развитие IT-специалистов зависит от взаимопонимания команды, и какую культуру пропагандирует руководство. Важно, чтобы за ошибки не ругали. Важна поддержка от руководителей, что бы ни случилось. И я искренне благодарна корпоративной культуре тех компаний и бизнесов, с которыми мне удалось посотрудничать. Сейчас я переношу их опыт в свои команды, на обучение. Я ценю открытость и отношусь к ошибкам как к нашим общим точкам роста.

🪲 ТОП простых ошибок при проктировании API 🪲

1. Все POST
Тип метода POST в REST API предназначен для создания новых данных. Есть еще GET (получить), PUT (создать или изменить), PATCH (изменить) и DELETE (удалить). Используйте их.

2. HTTP-200 на создание
Если новый объект данных (новая записы) создана в результате работы метода POST/PUT, то код успешного ответа HTTP-201 (created). Или код ошибки, если запрос выполнен неуспешно.

3. Тело в GET
Никакого JSON-тела запроса {"key": "value"} быть не может. Только query- и path-параметры для сортирововк и фильтраций. Тело запроса GET игнорируется на уровне HTTP.

4. Имя ресурса содержит глагол
Обычно, если мы хотим создать данные, например, о книге, то мы именуем метод не POST /createBook, а POST /book. Иногда, какие-то отдельные действия именуются глаголами, но это редкие исключения. Если можно без глаголов - именуем без них.

5. Потеряны limit, offset, count для списков
В методах GET на получение списков может возвращаться очень много объектов данных - библиотека книг. Десятки тысяч строк за один запрос. Чтобы случайно не получить в списке всю БД, для подобных запросов используют limit+offset+count параметры запроса.

Пересылайте себе в избранное и сохраняйте, чтобы не потерять.

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

Возможно, звучит немного пафосно.
Но на примере своих учеников часто вижу, как большинство, достигая крутых результатов, продолжают развиваться дальше.

Самое интересное, наблюдать, что у многих нет стандартного понимания точки А и В. У них этих точек может быть 5-8-12, причём как в горизонтальном, так и вертикальном направлениях развития карьерного роста.

Стабильность «выжигает».
Когда не знаешь, куда расти и изо дня в день сидишь в ожидании, что-то изменится.

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

На примере историй учеников поделюсь, как знания помогли расти дальше по карьерной лестнице.

«Курс по дизайну REST API — самый полезный, понятный и практический курс, который когда-либо мне приходилось проходить. Екатерина делала акцент на нюансах, которые можно узнать только из опыта, такое не прочитаешь в статьях и книгах. Считаю, что курс стоил своих денег на 200%.
Ну и да, помог пройти собеседование в компанию, где проектирование REST API сплошь и рядом»

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

«Получилось создать проект. Научилась создавать архитектуру api, описание JSON. Очень понравилась подача Екатерины. Понравилась подробность информации, развёрнутость, нюансы, которые обсуждали, методы, простой, доступный язык, понятный даже новичку. Понравилась, подробная проверка ДЗ, вплоть до того, где надо поставить пробел)»

«В процессе удалось хорошо разобраться с Postman: от настройки до тестирования. Активно стала использовать CRUD-модель, она помогла систематизировать информацию»

Если вы хотите, чтобы ваши знания и опыт высоко оценивали, то нужно сначала накопить их. Важно не ждать, а действовать. Именно так начинается путь к успеху 🚀

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

Где нормальные аналитики?🧐

Возможно, для кого-то это будет шок-контент, но на рынке порой действительно непросто найти стоящего специалиста.

Получается, когда одни кричат, что рынок IT переполнен и скоро лопнет от переизбытка, другие заявляют, что не могут найти толкового специалиста в команду, т.к. надо искать иголку в стоге сена 🤔
И за эту «иголку» компания всегда готова хорошо платить!

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

Развитие IT-специалиста можно сравнить с игрой в шахматы.
Изучение и понимание, как ходят фигуры, а в случае аналитика это БД, Интеграции, API, архитектура, Kafka, много всего, и даже нейросети... это все продвигает быстрее по игровому полю к победе.

Все эти навыки — ваше войско ♟️
И если, например, величественный ферзь — это понимание REST API, то король — это предводитель — знания об архитектуре. И дорога к ней лежит через ферзя.

В итоге то, как вы ловко управляете «фигурами», ценят и работодатели, и разработчики.

Если заканчиваешь учиться, цель развиваться — Game over. То же самое происходит и с доходом — он перестаёт расти.

Когда переходишь из позиции "я борюсь за работу", в позицию, где работодатель борется за тебя и ты диктуешь условия. Где-то здесь начинается волшебство, кайф и свобода 🙌

Одни из ТОП-навыков для резюме аналитиков: знание инструментов Postman и Swagger.
Эти инструменты незаменимы для системных аналитиков и разработчиков, которые разрабатывают API.

🟧 Postman - это приложение, которое позволяет отправлять запросы к API и получать ответы от него. Это полезно для тестирования, отладки и проверки работоспособности API. Postman предоставляет крутой интуитивно-понятный интерфейс для пользователей, не знакомых с языками программирования. Postman также предоставляет возможность сохранять запросы и создавать коллекции запросов, что делает процесс тестирования API более организованным и быстрым. Таже в нем можно вести API-документацию, писать автотесты для Backend.

🟩 Swagger - это набор инструментов, который позволяет создавать документацию для API. Swagger использует язык описания OpenAPI, который позволяет описывать API, используя YAML или JSON. Swagger автоматически генерирует документацию для API на основе этих описаний в OpenAPI, что упрощает процесс документирования API. Также через Swagger можно тестировать API.

Из опыта скажу, что более User Friendly и достаточно быстрый к освоению - Postman. Если вы освоили этот инструмент, то вы уже на 70% пути к успеху, так как в вашей копилке знаний появляются навыки тестирования и документирования любого API. Swagger менее удобный. Да, для документации его хорошо использовать, но долго. С тестированием аналогично. Да и Postman все возможности Swagger уже давно поддержал, только гораздо круче и удобнее.

Знание Postman и Swagger может быть полезным для системных аналитиков при общении с другими членами команды, такими как разработчиками и QA-инженерами, которые также могут использовать эти инструменты для тестирования и документирования API.

Использование Postman и Swagger помогает улучшить процесс проектирования API, упростить процесс тестирования и документирования, а также повысить качество кода за счет написания автотестов.

Оба инструмента бесплатные. Поэтому вы можете начать осваивать их самостоятельно в любой момент 🙌

❗️Если вы еще не посмотрели вебинар Екатерины Ананьевой

📹 5 главных принципов дизайна REST API

Подключайтесь по ➡️ ссылке

Про уверенность, которой постоянно так не хватает...

Если ты:

🎯 уверен в себе и своих знаниях
🎯 регулярно развиваешь hard/soft skills
🎯 умеешь грамотно рассказать о своих навыках работодателю.

то найти крутой проект, попросить повышение, или просто вести митинги с разработчиками становится так легко!

Уверенность всегда на первом месте. Но ее как-то вечно мало.

К сожалению, она никогда не приходит и не повышается сама по себе. Её нужно развивать. Можно, конечно, устроиться на работу, пройдя курс по подготовке к собеседованиям, и сказать работодателю: "Да, я это умею!" (про себя размышляя: если что, научусь в процессе). Но мы не в школе. И эта история с неумением всплывет на испытательном сроке, который может завершиться не так, как хочется.

Всегда важно подкреплять знания релевантным опытом. Дальше ловкость коммуникаций и никакого мошенничества: рассказ про ПРАКТИКУ = УВЕРЕННОСТЬ.
Именно через нее я росла.

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

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

Чтобы разобраться, как все реально работает, все понять, нужны действия. И да, это не так просто как посмотреть видео. Но именно так с каждым разом прокачивается опыт и появляется уверенность.

Уверенность -это преимущество. Она как игра в карты с козырями. Это внутреннее ощущение позволяет легко принимать решения, быстро и эффективно решать задачи 🙌

+ комментарий 👇

Обращали внимание, как сейчас стали популярны бизнес-завтраки, мастермайнды и разные комьюнити?

Всё просто: человеку нужен человек 🫂

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

Кто водит автомобиль, знает про выражение «слепая зона».
Это участок обзора, который остаётся без внимания водителя. И порой нужно быть предельно внимательным при смене полосы на дороге, чтобы не попасть в ДТП.

Такая «слепая зона» может стать причиной стагнации в работе👤

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

Только представьте: сколько времени сэкономит наставник, который поможет вырваться вперёд и расскажет как обстоят дела на трессе, чтобы ты мог пройти ее с легкостью, который чётко может подсказать, где необходимо «поднажать»?
Это прямая дорога от хаоса в голове к структурности.

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

Моя цель — передавать актуальные знания. Сухая теория - не ко мне. Я даю теорию только с применением сразу на практике. Информацию про навыки аналитиков можно долго искать на просторах сети. И все равно ничего не понять, потоу что не сделал ничего сам. Не попробовал. Не смог спросить конкретный вопрос, который важен тебе, и получить ответ.

А ещё я немного зануда и люблю разбирать всё до мелочей. Чтобы уйти от меня без навыков - нужно постараться 😁

Получайте навыки здесь. Просто будьте частью нашего IT-комьюнити системных аналитиков GetAnalyst ❤🦭