ПРО АНАЛИТИКА | КАНАЛ ПРО СИСТЕМНЫЙ АНАЛИЗ В АЙТИ

Готовые шаблоны - польза или вред? Вчера в чате курса увидел сообщение от ученика, не мог пойти мимо, так как мне важно, чтобы ученики получали точно результат, а сегодня хочу рассмотреть подробно с вами его ситуацию Собрал четко требования , точней продумал сам всю логику и как должно это выглядеть Посмотрел обучение постановка тз на бэк с внешней системой Мы сейчас интегрируемся с 1с , они создают сервис и мы будем его дергать , но у нас своей апишки нет к примеру . Бэк говорит что мы просто будем туда обращаться , тянуть данные и создавать уведомления и задачи Я могу по тому шаблону расписать Бизнес часть Логику И тот сервис который 1с нам создаст ? *орфография автора сохранена Погнали 🚀 С чего стоит начать в ситуациях, когда ничего не понятно? 1️⃣ Точно не надо бежать и использовать какой-то шаблон, а для начала нужно разобраться в требованиях. ✔️ Что нужно, ✔️ Как должно работать, ✔️ Какие системы участвуют и так далее. То есть сформировать в голове, а лучше в документе, то как сейчас и как должно быть. ➡️ Из сообщения видно, что с точки зрения бизнеса более-менее понятно, а вот с точки зрения систем - есть вопросы. Но так как я не работаю с системой, то чтобы дать совет, который реально поможет мне надо выяснить: ✔️ что за CRM, ✔️ как они планируют ее вызывать, ✔️ какие особенности у 1С и так далее. Потому что реализаций может быть достаточно много. Например, ✔️ CRM может напрямую вызывать 1с при определенном действии пользователя с фронта, тогда нужно взять шаблон из курса на постановку между фронтом и бэком. ✔️ CRM может по шедуллеру выполнять какие-то действия, а можно сделать APIшку и в этом варианте развития событий ученику понадобиться шаблон из курса на проектирование API, но с небольшими изменениями. Обсудив детали, я с учеником пришел к понимаю, что реализация будет через шедуллер. Дальше, уже дело техники. Просто делаем описание, обращаем внимание на важные моменты в спеке и вуаля, все готово. Но шаблон - это уже финальный этап и прежде чем до него добраться Вам надо сделать определенные шаги и чтобы ученику было легче - я еще сделал чек-лист по проектированию API, которым хочу поделиться с вами. Надеюсь, что этот чек-лист поможет и Вам избежать критических ошибок, ведь его можно использовать, как контрольный инструмент на каждом этапе разработки, чтобы не пропустить важные вещи при проектировании, разработке и внедрении API.

Yandex Go в Анталье Наконец-тоооо это случилось 🥳 Сейчас объясню почему я так этому рад Такси в Турции работает так: ✔️ Вызов происходит по кнопке, которая висит на дереве, нажимаешь ее и ждешь. Приедет ли к тебе водила и работает ли кнопка в целом - не узнаешь никак. ✔️ Ожидание, как вы понимаете, тоже бесконечно вечным может быть. А самое главное, что службы такси закреплены за районами и таксист с другого района, который может проезжать мимо, не возьмет тебя, потому что его могут просто за это отметелить, а пассажиров попросят пересесть в правильную машину. ➖➖➖ А теперь внимание вопрос, господа аналитики, что не так на скрине и что стоит поправить? 😁

ИЩУ АНАЛИТИКОВ, КОТОРЫЕ ХОТЯТ ВЫЙТИ НА НОВЫЙ УРОВЕНЬ В ПРОФЕССИИ ЧЕРЕЗ 5 НЕДЕЛЬ Да, да, всего за 5 недель можно прокачать себя в теме интеграций и проектирования API и выйти на новый уровень. Проверено участниками пяти потоков курса 🔥🔥🔥 И сегодня, я торжественно открываю продажи моего авторского курса-практикума «ИНТЕГРАЦИИ И ПРОЕКТИРОВАНИЕ API” ⬇️ ДЛИТЕЛЬНОСТЬ КУРСА - 5 недель Курс состоит из видео-уроков, а также 19 практических заданий после выполнения которых вы получите развернутую обратную связь лично от меня ДОПОЛНИТЕЛЬНО: 🔗 2 часовой онлайн вебинар в формате вопрос-ответ по итогам 5 недель обучения, 🔗 Чат поддержки и ответов на вопросы, который с вами останется навсегда и после окончания курса, 🔗 Сопроводительные материалы: конспекты к урокам, чек-листы, дополнительные файлы для наилучшего усвоения информации Доступ к материалам 3 месяца КОМУ ПОДХОДИТ КУРС: 🔘 системным аналитикам, 🔘 бизнес-аналитикам, 🔘 продакт менеджерам. КОТОРЫЕ ХОТЯТ: 🔗 понять с чего начать и научиться БАЗЕ в теме интеграций, тестировании и документировании требований, 🔗 освежить и углубить знания, а также разобраться, что там под "капотом", 🔗 прокачать свои технические знания, 🔗 научится разрабатывать ТЗ для разработчиков и подтянуть знания в этом вопросе, 🔗 заполнить пробелы в системном анализе для трудойстройства, 🔗 подтянуть для себя проектирование API или научиться понимать: как работает API, работе c JSON и научиться пользоваться такими инструментами, как Postman и Swagger, 🔗 познакомится с новыми людьми и коллегами и обменяться опытом КАКОЙ ТЕБЯ ЖДЁТ РЕЗУЛЬТАТ ПО ИТОГАМ КУРСА: Получишь практические навыки и сможешь: 📌 пройти тех собес в секции «интеграции», 📌 успешно применять в работе, 📌 сменить проект на более оплачиваемый и интересный Результаты тех, кто уже прошел курс можно изучить по тегу #отзыв 😉 ❗️ДЕЙСТВУЙ и ты и уже через 5 недель получишь первый результат❗️ ➖➖➖ ПОДРОБНЕЕ ПРО СТОИМОСТЬ И ПРОГРАММУ КУРСА, СПОСОБЫ ОПЛАТЫ И ТД 👉🏻 САЙТ КУРСА 👈🏻 👉🏻 САЙТ КУРСА 👈🏻 👉🏻 САЙТ КУРСА 👈🏻 ➖➖➖ образовательная лицензия No Л035-01298-77/01352304 от 16.08.2024

Как документировать ошибки в API? Сегодня про то, что часто пропускают и не особо продумывают в современных компаниях - API ошибки. Типичный кейс, как и с НФТ, что люди просто делают ctrl-c + ctrl-v. Однако, это классно работает, когда вы занимаетесь доработкой готовой системы, а что делать, если у вас что-то новое? Как быть? Прежде, чем ответить на этот вопрос, давайте скажу, почему важно думать про ошибки: ✔️ Легче анализировать возникающие проблемы, ✔️ Это юзер френдли и пользователи и разработчики вам за это скажут только спасибо. Как описать ошибки, чтобы это было красиво и правильно? 1️⃣ используем стандартизированные коды HTTP ✔️ 400 Bad Request — клиент что-то напутал; ✔️ 401 Unauthorized — нужна аутентификация; ✔️ 404 Not Found — не нашли, что искали; ✔️ 500 Internal Server Error — что-то сломалось на сервере. ➖➖➖ 2️⃣ добавляем дополнительную информацию в ответ Краткость, конечно, сестра таланта, но зачастую код-статуса не всегда информативен и нужна пояснительная бригада, поэтому в ответ можно добавить: ✔️ Уникальный ID ошибки (пусть коллеги ищут её в логах, а не в панике). Только не добавляйте это наружу; ✔️Чёткое описание проблемы; ✔️ Подсказку, как её исправить. Если такое возможно 😉 Например, { "status": 400, "error": "invalid_request", "message": "Поле 'email' обязательно.", "details": [ { "field": "email", "issue": "missing" } ], "timestamp": "2025-01-08T14:45:00Z", "trace_id": "abc123xyz" } ➖➖➖ 3️⃣ Придерживайтесь правил, которые приняты в компании. Формат ошибок должен быть единым для всех эндпоинтов и желательно для всех API. Это позволит поддерживать универсальность обработки этого добра ➖➖➖ Надеюсь с этим понятно, но, чтобы было нагляднее, как можно сделать, то вот парочка примеров от известных компаний: ✔️Google API: они добавляют у себя детальную информацию об ошибке, код и статус. { "error": { "code": 404, "message": "Requested entity was not found.", "status": "NOT_FOUND" } } ➖➖➖ ✔️ Stripe: они разделяют ошибки по типам и добавляют пояснение. { "error": { "type": "invalid_request_error", "message": "Missing required param: email" } } ➖➖➖ ✔️ GitHub: эти ребята немного борщат на мой взгляд, но подход интересный. Они добавляют ошибки с подсказками и ссылками на документацию. { "message": "Validation Failed", "errors": [ { "resource": "Issue", "field": "title", "code": "missing_field" } ], "documentation_url": "https://docs.github.com/rest" } ➖➖➖ На этом пожалуй все. Делитесь, как у вас оформляют ошибки в компании?

Открыта предзапись на курс по интеграциям*: https://proanalitika.ru *вы гарантировано не пропустите старт продаж курса **вам напишет менеджер, когда будут открыты продажи #отзыв