Хореография
Паттерн "Оркестрация" был рассмотрен в предыдущем посте, теперь поговорим про хореографию.
В комментариях писали, что подход с оркестратором в современных реалиях достаточно устарел и, в основном, все работает через что-то похожее на хореографию - и да, в общем-то это так и есть. Но нам все равно нужно держать в голове разные способы и подходы, как минимум потому, что на практике существует очень много систем, где от них еще не отказались.
Хореография — разработка системы, в которой взаимодействие между подсистемами происходит без необходимости в центральном контроллере. В таких системах каждый компонент отвечает за понимание своей роли и координацию общения с другими компонентами системы.
Особенности архитектуры:
➖ Децентрализованное управление: система распределяет управление между участвующими компонентами. Каждый из них самостоятельно решает, как реагировать на события или сообщения, которые он получает;
➖ Автономность: компоненты в отлаженной системе должны работать автономно и не полагаться на внешние команды. Они отвечают за анализ входящих сообщений и запуск необходимых действий на основе своей собственной внутренней логики;
➖ Слабая связь: Данный подход способствует слабой связи между компонентами, позволяя им взаимодействовать без сильной зависимости друг от друга, что повышает гибкость системы (в отличие от оркестрации, в которой все жестко завязано на центральное звено);
➖ Асинхронная связь: связь между компонентами в системах с хореографией как правило асинхронная. Это позволяет компонентам обмениваться между собой сообщений или событиями, на которые не нужно немедленно и синхронно отвечать, что обеспечивает намного более лучшую отказоустойчивость (и масштабируемость);
➖ Управляемые события: компоненты реагируют на события или изменения состояния системы. События запускают действия внутри отдельных компонентов, те на них реагируют, создавая новые события, на которые триггерятся другие компоненты - и получается, что таким "Коллективным разумом" определяется поведение всей системы целиком.
Из-за ее особенностей, хореография часто используется в тех случаях, когда система должна быть масштабируемой, отказоустойчивой и адаптируемой (т.е. почти всегда).
P.S. И на самом деле сейчас такой подход на практике я встречаю чаще. А у вас на проектах как?
Паттерн "Оркестрация" был рассмотрен в предыдущем посте, теперь поговорим про хореографию.
В комментариях писали, что подход с оркестратором в современных реалиях достаточно устарел и, в основном, все работает через что-то похожее на хореографию - и да, в общем-то это так и есть. Но нам все равно нужно держать в голове разные способы и подходы, как минимум потому, что на практике существует очень много систем, где от них еще не отказались.
Хореография — разработка системы, в которой взаимодействие между подсистемами происходит без необходимости в центральном контроллере. В таких системах каждый компонент отвечает за понимание своей роли и координацию общения с другими компонентами системы.
Особенности архитектуры:
Из-за ее особенностей, хореография часто используется в тех случаях, когда система должна быть масштабируемой, отказоустойчивой и адаптируемой (т.е. почти всегда).
P.S. И на самом деле сейчас такой подход на практике я встречаю чаще. А у вас на проектах как?
Please open Telegram to view this post
VIEW IN TELEGRAM
Раздражающие вещи в работе СА
Да, именно об этом хотелось бы сегодня поговорить, т.к. работа не только приносит удовлетворение и удовольствие - но и определенные негативные эмоции.
Хочу поделиться несколькими вещами, из-за которых они возникали у меня.
➖ Повторяющиеся, однообразные задачи
Я думаю с этим сталкивались все. Особенно опытные аналитики. И у каждого были такие задачи и свои примеры, когда из спринта в спринт приходилось заниматься одним и тем же. Например, написанием ТЗ на добавление очередных документов, которые система будет формировать в заявке на кредит. Когда тебе нужно из спринта в спринт заполнять один и тот же шаблон, немного меняя условия формирования документа.
➖ Созвоны
Многие меня поймут, как это напрягает, когда у тебя календарь выглядит как сплошное забитое полотно, в котором нет слотов даже под обед 😅 Но ладно под обед - а работать то когда?) Ведь дедлайны по задачам приближаются, а время на них только в перерывах между встречами.
Помню, что у меня в моих первых лекциях по поводу гибких методологий был отдельный пункт в разделе "Недостатки", который примерно так и назывался. В то время меня большое количество встреч прям триггерило - ибо хотелось работать и созвоны воспринималась как помеха работе, а не как что-то позитивное или хотя потенциально полезное.
➖ Сроки
Раздражает срок "Нужно еще вчера". Особенно когда задача была не приоритетной и ты смело занимался другим, а потом всё резко поменялось и приходится на пол пути бросать одно и браться за другое.
➖ Спонтанные изменения
Раздражают разработчики, которые решили сделать не по ТЗ, а по-своему и не сказали об этом. Потом тратишь много времени на разбор во время тестирования - почему работает не так, как описано. Я не против, когда разработчики изменяют реализацию на основании своих бест практис - но приди и скажи об этом, обсудим.
С заказчиками аналогично, когда задача уже на условном ПМИ - и тут вдруг захотелось все переделать потому что потому. А то что согласовано ТЗ, прошло множество обсуждений - это уже все, не котируется.
Раздражают другие аналитики, с которыми ты что-то согласовал. Потом они внутри себя обсудили, поменяли - а ты не в курсе. Привет доработки в самом конце релизного цикла с горящей жопой.
➖ Люди
См. предыдущий пункт.Но в основном все лапушки, конечно.
➖ Доступы
Да, да. Те самые доступы, которые ты можешь получать по месяцу, каждый (!). Привет банки, особенно.
Я только один раз видел в онбординге таблицу, в которой были перечислены все доступы, которые нужно запросить и которые понадобятся в работе аналитика. Часто бывает так, что ты спустя пол года работы на что-то натыкаешь в первый раз и идешь получать доступы, которые долго выдают.
P.S. Сейчас таких негативных эмоций почти не возникает, потому что работа находится в балансе по уровню задач, количеству встреч и коллег, которые меня окружают. Но в разные этапы моей карьеры было по-разному, решил немного порефлексировать и вспомнить такие моменты. Может быть вам какие-то из них прямо сейчас близки - поделитесь этим в комментариях, если хотите.
А также поделитесь в комментариях своими вариантами того, что вас раздражает\огорчает\демотивирует в работе - интересно будет почитать и подумать, откликается ли это мне или другим.
Да, именно об этом хотелось бы сегодня поговорить, т.к. работа не только приносит удовлетворение и удовольствие - но и определенные негативные эмоции.
Хочу поделиться несколькими вещами, из-за которых они возникали у меня.
Я думаю с этим сталкивались все. Особенно опытные аналитики. И у каждого были такие задачи и свои примеры, когда из спринта в спринт приходилось заниматься одним и тем же. Например, написанием ТЗ на добавление очередных документов, которые система будет формировать в заявке на кредит. Когда тебе нужно из спринта в спринт заполнять один и тот же шаблон, немного меняя условия формирования документа.
Многие меня поймут, как это напрягает, когда у тебя календарь выглядит как сплошное забитое полотно, в котором нет слотов даже под обед 😅 Но ладно под обед - а работать то когда?) Ведь дедлайны по задачам приближаются, а время на них только в перерывах между встречами.
Помню, что у меня в моих первых лекциях по поводу гибких методологий был отдельный пункт в разделе "Недостатки", который примерно так и назывался. В то время меня большое количество встреч прям триггерило - ибо хотелось работать и созвоны воспринималась как помеха работе, а не как что-то позитивное или хотя потенциально полезное.
Раздражает срок "Нужно еще вчера". Особенно когда задача была не приоритетной и ты смело занимался другим, а потом всё резко поменялось и приходится на пол пути бросать одно и браться за другое.
Раздражают разработчики, которые решили сделать не по ТЗ, а по-своему и не сказали об этом. Потом тратишь много времени на разбор во время тестирования - почему работает не так, как описано. Я не против, когда разработчики изменяют реализацию на основании своих бест практис - но приди и скажи об этом, обсудим.
С заказчиками аналогично, когда задача уже на условном ПМИ - и тут вдруг захотелось все переделать потому что потому. А то что согласовано ТЗ, прошло множество обсуждений - это уже все, не котируется.
Раздражают другие аналитики, с которыми ты что-то согласовал. Потом они внутри себя обсудили, поменяли - а ты не в курсе. Привет доработки в самом конце релизного цикла с горящей жопой.
См. предыдущий пункт.
Да, да. Те самые доступы, которые ты можешь получать по месяцу, каждый (!). Привет банки, особенно.
Я только один раз видел в онбординге таблицу, в которой были перечислены все доступы, которые нужно запросить и которые понадобятся в работе аналитика. Часто бывает так, что ты спустя пол года работы на что-то натыкаешь в первый раз и идешь получать доступы, которые долго выдают.
P.S. Сейчас таких негативных эмоций почти не возникает, потому что работа находится в балансе по уровню задач, количеству встреч и коллег, которые меня окружают. Но в разные этапы моей карьеры было по-разному, решил немного порефлексировать и вспомнить такие моменты. Может быть вам какие-то из них прямо сейчас близки - поделитесь этим в комментариях, если хотите.
А также поделитесь в комментариях своими вариантами того, что вас раздражает\огорчает\демотивирует в работе - интересно будет почитать и подумать, откликается ли это мне или другим.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Всё ты можешь
Профдеформация
Давно уже поймал себя на мысли, что чем больше работаю в IT в целом и в качестве системного аналитика в частности - тем больше подмечаю вокруг то, как в разных сферах реализованы системы или выстроены процессы.
Недавно, когда был на приеме у стоматолога и мне нужно было сделать снимок челюсти с помощью какой-то специальной 3D-камеры, у которой было что-то вроде настроенной нейросетки, которая подсказывала оператору, куда еще необходимо эту камеры направить.
И вот я не знаю, что за гениальный человек это придумал - но я в первый раз увидел такой способ взаимодействия системы с пользователем. В тот момент когда оператор делал всё правильно - играла приятная, гармоничная фортепианная мелодия. Но если он начинал снимать те области, которые уже прошел или если объектив камеры запотел - то начинала играть какая-то ужасно дисгармоничная мелодия, которая прям явно намекала на то, что что-то идет не так.
И мне почему-то прям запомнился этот момент, подумал для себя, что это как минимум забавный, а как максимум интересный вариант взаимодействия системы с пользователем.
А какие вы интересные вещи подмечали в жизни?
Давно уже поймал себя на мысли, что чем больше работаю в IT в целом и в качестве системного аналитика в частности - тем больше подмечаю вокруг то, как в разных сферах реализованы системы или выстроены процессы.
Недавно, когда был на приеме у стоматолога и мне нужно было сделать снимок челюсти с помощью какой-то специальной 3D-камеры, у которой было что-то вроде настроенной нейросетки, которая подсказывала оператору, куда еще необходимо эту камеры направить.
И вот я не знаю, что за гениальный человек это придумал - но я в первый раз увидел такой способ взаимодействия системы с пользователем. В тот момент когда оператор делал всё правильно - играла приятная, гармоничная фортепианная мелодия. Но если он начинал снимать те области, которые уже прошел или если объектив камеры запотел - то начинала играть какая-то ужасно дисгармоничная мелодия, которая прям явно намекала на то, что что-то идет не так.
И мне почему-то прям запомнился этот момент, подумал для себя, что это как минимум забавный, а как максимум интересный вариант взаимодействия системы с пользователем.
А какие вы интересные вещи подмечали в жизни?
Модель OSI (Open System Interconnection), часть 1
Сегодня мы опустимся на несколько уровней ниже классического системного анализа и рассмотрим модель OSI. Это эталонная модель взаимодействия открытых систем, которая описывает, как устройства в локальных и глобальных сетях обмениваются данными и что с этими самыми данными происходит. Ее предложили в 1984 году инженеры из Международной организации по стандартизации (небезызвестной нам ISO), которая в то время работала над единым стандартом передачи данных по интернету.
Вообще, это не то, что нужно обязательно знать системному аналитику для выполнения своей работы, скорее я предлагаю ознакомиться с этой темой просто для того, чтобы чуть лучше понять, что происходит не только на прикладном уровне приложений (которым мы, как правило, и оперируем), но и спуститься ниже до самого основания этой модели. Ну и иногда это спрашивают на собеседовании, по крайней мере на middle+ позициях такие вопросы могут встречаться)
Так вот, сама по себе эталонная модель - это не стандарт интернета, как TCP/IP, скорее в рамках эдакой "коробки" OSI доступны различные веб-стандарты, такие как UDP, HTTP, FTP и другие (всего порядка сотни штук).
И наша модель разделяет процесс сетевого взаимодействия на семь взаимосвязанных слоев (уровней), каждый из которых выполняет свою четко определенную функцию и взаимодействует с уровнями, которые выше и ниже. Если упростить, то эти уровни работают с одними и теми же данными, но по-разному. Например, кабели передают информацию в виде нулей и единиц (самый нижний уровень), а сетевое оборудование (3 уровень) использует эти данные, чтобы передать их в другую точку страны или мира, чтобы компьютер конечного пользователя мог их получить и преобразовать в понятный для человека вид.
Рассмотрим каждый из слоев чуть более детально.
1️⃣ 1 уровень OSI - физический (physical layer)
Как я уже упоминал - на самом нижнем уровне модели данные представляют собой физические объекты, такие как ток, свет или радиоволны, которые передаются по проводам или с помощью беспроводных сигналов.
Самый известный протокол на физическом уровне это Ethernet. Он описывает, как сигналы кодируются и передаются по проводам. Кроме этого есть Bluetooth, WI-FI, давно забытые ИК-порты, которые также содержат инструкции для передачи данных.
2️⃣ 2 уровень OSI - канальный (data link layer)
Этот уровень располагается над физическим и его задача в том, чтобы проверить целостность полученных данных и, по возможности, исправить ошибки. Поэтому он немного "умнее" физического уровня и уже имеет алгоритмы, которые определяют нули и единицы по различным амплитуда напряжения. Кроме этого канальный уровень умеет кодировать сигналы в биты и передавать их дальше.
Если немного упростить, то на канальном уровне происходит передача информации в рамках одной локальной подсети.
P.S. О следующих уровнях поговорим во второй части. А пока поделитесь - задавали ли вам вопросы на собеседованиях на эту тему или вас эта участь обходила стороной?)
Сегодня мы опустимся на несколько уровней ниже классического системного анализа и рассмотрим модель OSI. Это эталонная модель взаимодействия открытых систем, которая описывает, как устройства в локальных и глобальных сетях обмениваются данными и что с этими самыми данными происходит. Ее предложили в 1984 году инженеры из Международной организации по стандартизации (небезызвестной нам ISO), которая в то время работала над единым стандартом передачи данных по интернету.
Вообще, это не то, что нужно обязательно знать системному аналитику для выполнения своей работы, скорее я предлагаю ознакомиться с этой темой просто для того, чтобы чуть лучше понять, что происходит не только на прикладном уровне приложений (которым мы, как правило, и оперируем), но и спуститься ниже до самого основания этой модели. Ну и иногда это спрашивают на собеседовании, по крайней мере на middle+ позициях такие вопросы могут встречаться)
Так вот, сама по себе эталонная модель - это не стандарт интернета, как TCP/IP, скорее в рамках эдакой "коробки" OSI доступны различные веб-стандарты, такие как UDP, HTTP, FTP и другие (всего порядка сотни штук).
И наша модель разделяет процесс сетевого взаимодействия на семь взаимосвязанных слоев (уровней), каждый из которых выполняет свою четко определенную функцию и взаимодействует с уровнями, которые выше и ниже. Если упростить, то эти уровни работают с одними и теми же данными, но по-разному. Например, кабели передают информацию в виде нулей и единиц (самый нижний уровень), а сетевое оборудование (3 уровень) использует эти данные, чтобы передать их в другую точку страны или мира, чтобы компьютер конечного пользователя мог их получить и преобразовать в понятный для человека вид.
Рассмотрим каждый из слоев чуть более детально.
Как я уже упоминал - на самом нижнем уровне модели данные представляют собой физические объекты, такие как ток, свет или радиоволны, которые передаются по проводам или с помощью беспроводных сигналов.
Самый известный протокол на физическом уровне это Ethernet. Он описывает, как сигналы кодируются и передаются по проводам. Кроме этого есть Bluetooth, WI-FI, давно забытые ИК-порты, которые также содержат инструкции для передачи данных.
Этот уровень располагается над физическим и его задача в том, чтобы проверить целостность полученных данных и, по возможности, исправить ошибки. Поэтому он немного "умнее" физического уровня и уже имеет алгоритмы, которые определяют нули и единицы по различным амплитуда напряжения. Кроме этого канальный уровень умеет кодировать сигналы в биты и передавать их дальше.
Если немного упростить, то на канальном уровне происходит передача информации в рамках одной локальной подсети.
P.S. О следующих уровнях поговорим во второй части. А пока поделитесь - задавали ли вам вопросы на собеседованиях на эту тему или вас эта участь обходила стороной?)
Please open Telegram to view this post
VIEW IN TELEGRAM
Модель OSI (Open System Interconnection), часть 2
Продолжаем разговаривать про уровни модели OSI.
3️⃣ 3 уровень OSI - Сетевой уровень (Network Layer)
На этом уровне происходит маршрутизация пакетов данных между узлами сети. Кроме этого сетевой уровень обеспечивает логическую адресацию и определяет пути передачи данных через различные сети (например, IP-адресация, маршрутизаторы).
Т.е. по сути на этом уровне происходит передачи информации между различными локальными сетями, например, с помощью упомянутого выше маршрутизатора.
4️⃣ 4 уровень OSI - Транспортный уровень (Transport Layer)
Уровень обеспечивает надежную передачу данных, контроль ошибок, сегментацию данных и повторную их сборку. Плюс к этому идет гарантия того, что данные передаются без потерь и дубликатов.
Т.к. передача данных происходит по сети, то используются, как правило, два главных протокола TCP и UDP (о них еще поговорим).
5️⃣ 5 уровень OSI - Сеансовый уровень (Session Layer)
Уровень обеспечивает управление сеансами связи между приложениями. Обеспечивает установку, поддержание, завершение сеансов и синхронизацию и управление обменом данными.
Начиная с этого уровня и выше мы уже приходим к привычному нам формату данных в виде, например, .jpeg, .mp3 файлов. Задача сети на этих уровнях - представить информацию в понятном для человека виде и сделать так, чтобы пользователь мог с ней взаимодействовать.
6️⃣ 6 уровень OSI - Уровень представления данных (presentation layer)
Уровень отвечает за преобразование данных в формат, подходящий для приложения или сети. Сюда же включаются задачи по шифрованию\дешифрованию, сжатию и преобразованию данных.
Например, полученные данные могут превратиться в GIF или MP4 формат. Или в обратном порядке, если пользователь отправляет файл другому человеку - в этом случае данные сначала конвертируются в биты и сжимаются, а потом уже передаются на транспортный уровень.
7️⃣ 7 уровень OSI - Прикладной (application layer)
Уровень обеспечивает доступ приложения к сетевым услугам. Реализует протоколы, которые поддерживают конечные пользовательские процессы и сетевые приложения.
Прикладной уровень похож на некий графический интерфейс для всей модели OSI - с его помощью пользователь взаимодействует с другими уровнями, причем даже не подозревая об этом. Этот интерфейс называется сетевым. Самые популярные из сетевых интерфейсов - это HTTP, HTTPS, FTP, SMTP.
По сути это как раз тот уровень, с которым, если мы говорим про работу, взаимодействует (и даже проектирует) системный аналитик. Особенно это касается нас в части проектирования интеграций, т.е. то как наши приложения будут взаимодействовать между собой по HTTP (S), кто, как и кого будет вызывать и что получать в ответ.
На это наше небольшое погружение в теорию "сетей" закончено. Потому что по сути про это можно рассказывать бесконечно и про каждый из уровней написано огромное количество теории. Но нас больше интересует именно уровень приложения, с которым нам приходится взаимодействовать и который приходится описывать. Но для общего обозрения того, как вообще данные передаются по сети из одного приложения в другое - точно пригодится.
Продолжаем разговаривать про уровни модели OSI.
На этом уровне происходит маршрутизация пакетов данных между узлами сети. Кроме этого сетевой уровень обеспечивает логическую адресацию и определяет пути передачи данных через различные сети (например, IP-адресация, маршрутизаторы).
Т.е. по сути на этом уровне происходит передачи информации между различными локальными сетями, например, с помощью упомянутого выше маршрутизатора.
Уровень обеспечивает надежную передачу данных, контроль ошибок, сегментацию данных и повторную их сборку. Плюс к этому идет гарантия того, что данные передаются без потерь и дубликатов.
Т.к. передача данных происходит по сети, то используются, как правило, два главных протокола TCP и UDP (о них еще поговорим).
Уровень обеспечивает управление сеансами связи между приложениями. Обеспечивает установку, поддержание, завершение сеансов и синхронизацию и управление обменом данными.
Начиная с этого уровня и выше мы уже приходим к привычному нам формату данных в виде, например, .jpeg, .mp3 файлов. Задача сети на этих уровнях - представить информацию в понятном для человека виде и сделать так, чтобы пользователь мог с ней взаимодействовать.
Уровень отвечает за преобразование данных в формат, подходящий для приложения или сети. Сюда же включаются задачи по шифрованию\дешифрованию, сжатию и преобразованию данных.
Например, полученные данные могут превратиться в GIF или MP4 формат. Или в обратном порядке, если пользователь отправляет файл другому человеку - в этом случае данные сначала конвертируются в биты и сжимаются, а потом уже передаются на транспортный уровень.
Уровень обеспечивает доступ приложения к сетевым услугам. Реализует протоколы, которые поддерживают конечные пользовательские процессы и сетевые приложения.
Прикладной уровень похож на некий графический интерфейс для всей модели OSI - с его помощью пользователь взаимодействует с другими уровнями, причем даже не подозревая об этом. Этот интерфейс называется сетевым. Самые популярные из сетевых интерфейсов - это HTTP, HTTPS, FTP, SMTP.
По сути это как раз тот уровень, с которым, если мы говорим про работу, взаимодействует (и даже проектирует) системный аналитик. Особенно это касается нас в части проектирования интеграций, т.е. то как наши приложения будут взаимодействовать между собой по HTTP (S), кто, как и кого будет вызывать и что получать в ответ.
На это наше небольшое погружение в теорию "сетей" закончено. Потому что по сути про это можно рассказывать бесконечно и про каждый из уровней написано огромное количество теории. Но нас больше интересует именно уровень приложения, с которым нам приходится взаимодействовать и который приходится описывать. Но для общего обозрения того, как вообще данные передаются по сети из одного приложения в другое - точно пригодится.
Please open Telegram to view this post
VIEW IN TELEGRAM
Примеры тестовых заданий для джунов
Под предыдущим постом был вопрос ко мне, есть ли у меня примеры тестовых заданий для джунов СА. Честно говоря, я давненько не интервьюировал людей на позицию СА уровня junior и мои ученики не делились подобным (потому что раньше тестовые задания не пользовались популярностью, но сейчас, я подозреваю, эта позиция изменилась и они будут встречаться прям сильно чаще, с учетом того, что диван немного поворачивается в сторону работодателя).
Поэтому если у кого-то есть под рукой более-менее актуальные примеры и не жалко ими поделиться - поделитесь, пожалуйста, в комментариях или со мной в личке @schadulin.
Предполагаю, что глобально, не так много чего поменялось и это стандартные вопросы на сбор требований, какие-то базовые вопросы про SQL, возможно про REST и всё около этого - но действительно на конкретных примерах проще разбирать).
Поэтому буду благодарен тем, кто откликнется 🤝.
Под предыдущим постом был вопрос ко мне, есть ли у меня примеры тестовых заданий для джунов СА. Честно говоря, я давненько не интервьюировал людей на позицию СА уровня junior и мои ученики не делились подобным (потому что раньше тестовые задания не пользовались популярностью, но сейчас, я подозреваю, эта позиция изменилась и они будут встречаться прям сильно чаще, с учетом того, что диван немного поворачивается в сторону работодателя).
Поэтому если у кого-то есть под рукой более-менее актуальные примеры и не жалко ими поделиться - поделитесь, пожалуйста, в комментариях или со мной в личке @schadulin.
Предполагаю, что глобально, не так много чего поменялось и это стандартные вопросы на сбор требований, какие-то базовые вопросы про SQL, возможно про REST и всё около этого - но действительно на конкретных примерах проще разбирать).
Поэтому буду благодарен тем, кто откликнется 🤝.
Я — тот человек, который узнал о сокращениях в своей компании из новостных пабликов и вопросов знакомых 😄 просто некогда ходить на общие сборы, а на ковер пока никто не вызывал.
В течение пары месяцев бурлят различные новости и слухи в интернетах по поводу проблем с наймом, пронизанные то паникой (со стороны сотрудников, которых со всех сторон эмоционально накрутили), то радостью (со стороны компаний, которые говорят, что теперь выбор на стороне работодателей).
Видел и реальные кейсы увольнений, сокращений и, в целом, эта вся история просвистела где-то прям рядом со мной, но не задела. Поэтому хочу спросить у вас - как дела на рынке? Испытывали ли проблемы с сокращениями/трудоустройством? Изменилось ли что-то в процессах найма?
Поделитесь своими переживаниями\кейсами\информацией в комментариях - пообщаемся. А я поделюсь своим мнением и информацией, собранной из разных (неофициальных) источников.
В течение пары месяцев бурлят различные новости и слухи в интернетах по поводу проблем с наймом, пронизанные то паникой (со стороны сотрудников, которых со всех сторон эмоционально накрутили), то радостью (со стороны компаний, которые говорят, что теперь выбор на стороне работодателей).
Видел и реальные кейсы увольнений, сокращений и, в целом, эта вся история просвистела где-то прям рядом со мной, но не задела. Поэтому хочу спросить у вас - как дела на рынке? Испытывали ли проблемы с сокращениями/трудоустройством? Изменилось ли что-то в процессах найма?
Поделитесь своими переживаниями\кейсами\информацией в комментариях - пообщаемся. А я поделюсь своим мнением и информацией, собранной из разных (неофициальных) источников.
Я прошел собес на СА, но ничего не понимаю - памагите 😅 (с)
Сегодня хочу поделиться несколькими историями из моей менторской практики, которые сводятся примерно к одному: "Я устроился на работу системным аналитиком, но практических знаний нет, а дедлайны по рабочим задачам уже горят прям сейчас. Сможешь помочь?".
Пик таких запросов был уже года три назад (ужс как быстро время идет), когда ко мне пришло 4 таких запроса за месяц. После третьего подряд я уже не удивлялся такому повороту событий, хотя для меня всегда было интересно, как это вообще происходит? Но ответы были достаточно просты:
➖ Один человек перешел из поддержки в СА в достаточно небольшую компанию, где почти не было понимания кто такие СА, поэтому получилось пройти собес;
➖ Один человек переквалифицировался из "бизнесовой" (не IT) позиции, в СА внутри компании;
➖ Еще один, будучи начинающим БА, резко взял на себя задачи еще и СА после его увольнения и ему пришлось в очень большой спешке доучиваться на ходу;
➖ И еще один тоже пришел извне рынке в одну IT-компанию каким-то образом и тоже нужно было как-то выполнять свои задачи, без, почти что, минимального понимания.
При этом, никто из них не был, так называемым "волком", которые через накрутку опыта и обман как-то устроились на позицию, которую они не заслуживали. Просто так сложились звезды (и мне до сих пор попадаются такие случае на пути моего менторства), поэтому я взялся им помочь.
И, честно, я на тот момент не видел более мотивированных и целеустремленных людей, чем они 😅 Так активно и быстро гранит науки на моей памяти еще никто не грыз (что, впрочем, и понятно).
Поэтому работать с ними было максимально приятно и продуктивно. Если, обычно, я провожу занятия раз в неделю, потому что я даю большое количество домашки и у учеников, как правило, нет возможности делать ее быстрее, чем за это время - то тут мы проводили по 2-3 занятия и меня еще буквально засыпали вопросами по той обратной связи, что я давал, по моим замечаниям и так далее.
К моему удовольствию, после такого экспресс курса, на котором мы разобрали столько тонкостей работы системным аналитиком, сколько только возможно - все из них остались работать на тех позициях, на которые они устроились. Кого-то из них даже схантили с более вкусным оффером в соседнюю компанию.
К слову сказать, это был мой первый опыт работы с человеком, который развивается в СА именно с бизнесовой позиции той же отрасли, и я был просто в восторге. Менти работал в сфере, связанной с аэропортами и обслуживанием воздушных судов. И я до сих пор, даже спустя эти три года, предлагаю его ТЗ, разработанное в рамках обучения, в качестве примера для своих текущих менти, потому что это техническое задание на "Контроль наземного обслуживания воздушных судов" написано настолько мощно с точки зрения требований, что не все миддловые+ БА могли бы это повторить.
P.S. Впрочем, меня до сих пор преследуют запросы подобного характера от учеников, пусть и более распределенные по времени. А я и не против, потому что каждый такой кейс развивает меня как ментора, за счет того, что приходится погружаться в очень специфичные и разнообразные предметные области, чтобы как можно качественнее помочь в обучении.
Были ли у вас такие случаи, что вы устроились на работу и потом в очень напряженном темпе приходилось осваивать какие-то новые навыки?
Сегодня хочу поделиться несколькими историями из моей менторской практики, которые сводятся примерно к одному: "Я устроился на работу системным аналитиком, но практических знаний нет, а дедлайны по рабочим задачам уже горят прям сейчас. Сможешь помочь?".
Пик таких запросов был уже года три назад (ужс как быстро время идет), когда ко мне пришло 4 таких запроса за месяц. После третьего подряд я уже не удивлялся такому повороту событий, хотя для меня всегда было интересно, как это вообще происходит? Но ответы были достаточно просты:
При этом, никто из них не был, так называемым "волком", которые через накрутку опыта и обман как-то устроились на позицию, которую они не заслуживали. Просто так сложились звезды (и мне до сих пор попадаются такие случае на пути моего менторства), поэтому я взялся им помочь.
И, честно, я на тот момент не видел более мотивированных и целеустремленных людей, чем они 😅 Так активно и быстро гранит науки на моей памяти еще никто не грыз (что, впрочем, и понятно).
Поэтому работать с ними было максимально приятно и продуктивно. Если, обычно, я провожу занятия раз в неделю, потому что я даю большое количество домашки и у учеников, как правило, нет возможности делать ее быстрее, чем за это время - то тут мы проводили по 2-3 занятия и меня еще буквально засыпали вопросами по той обратной связи, что я давал, по моим замечаниям и так далее.
К моему удовольствию, после такого экспресс курса, на котором мы разобрали столько тонкостей работы системным аналитиком, сколько только возможно - все из них остались работать на тех позициях, на которые они устроились. Кого-то из них даже схантили с более вкусным оффером в соседнюю компанию.
К слову сказать, это был мой первый опыт работы с человеком, который развивается в СА именно с бизнесовой позиции той же отрасли, и я был просто в восторге. Менти работал в сфере, связанной с аэропортами и обслуживанием воздушных судов. И я до сих пор, даже спустя эти три года, предлагаю его ТЗ, разработанное в рамках обучения, в качестве примера для своих текущих менти, потому что это техническое задание на "Контроль наземного обслуживания воздушных судов" написано настолько мощно с точки зрения требований, что не все миддловые+ БА могли бы это повторить.
P.S. Впрочем, меня до сих пор преследуют запросы подобного характера от учеников, пусть и более распределенные по времени. А я и не против, потому что каждый такой кейс развивает меня как ментора, за счет того, что приходится погружаться в очень специфичные и разнообразные предметные области, чтобы как можно качественнее помочь в обучении.
Были ли у вас такие случаи, что вы устроились на работу и потом в очень напряженном темпе приходилось осваивать какие-то новые навыки?
Please open Telegram to view this post
VIEW IN TELEGRAM
ТЗ. Норм или стрём?
В прошлом посте я, на свою голову, упомянул про ТЗ, которое написал в рамках обучения мой ученик и это привело к большому количеству вопросов формата: "А что это было за ТЗ такое волшебное, дай посмотреть". Чему я, на самом деле, удивлен. Кому-то, кстати, я наверняка забыл скинуть из просивших - прастите.
Но вообще меня это натолкнуло на написание этого поста и породило вопрос - а как вы оцениваете чьи-то ТЗ? Или своё, например? Какие у вас в голове есть критерии "приемки" своего ТЗ, перед тем как вы его покажете на-гора команде? Напишите в комментариях, очень интересно обсудить это.
Со своей стороны скажу, что я уже не задумываюсь об этом, я просто пишу на автомате текст, стираю, снова пишу и повторяю так пока не получится определенный набор структурированных (или не очень 😅) требований\описаний контрактов\whatever.
А вот когда провожу ревью чужих ТЗ, то обращаю внимание на следующие критерии:
➖ Орфография (это не важно на самом деле, но я прям стал grammar nazi после перехода в СА. Профдеформация, чтоб ее);
➖ Логичность написанного;
➖ Непротиворечивость самому себе\бизнес-требования\логике системы в целом. Это частая проблема СА, что хочется сделать красиво и правильно, но твое решение, допустим, начинает противоречить текущей архитектуре системы (какой бы она не была). Или упускаешь какой-то кусок бизнес-требований, что бывает;
➖ Понятность написанного. Очень частая боль требований в том - что они могут казаться автору понятными и логичными, но при прочтении их со стороны просто ломается мозг в попытке разобраться о чем вообще речь.
Собственно все эти пункты критерии можно применять и к написанным собственноручно требованиям - хотя это и тяжелее, потому что глаз замыливается капитально. Тут самое лучшее, что вы можете сделать - это дать требованиям полежать денек, вернуться к ним завтра и посмотреть не ерунда ли там написана)
Делитесь своими мыслями на эту тему в комментариях.
В прошлом посте я,
Но вообще меня это натолкнуло на написание этого поста и породило вопрос - а как вы оцениваете чьи-то ТЗ? Или своё, например? Какие у вас в голове есть критерии "приемки" своего ТЗ, перед тем как вы его покажете на-гора команде? Напишите в комментариях, очень интересно обсудить это.
Со своей стороны скажу, что я уже не задумываюсь об этом, я просто пишу на автомате текст, стираю, снова пишу и повторяю так пока не получится определенный набор структурированных (или не очень 😅) требований\описаний контрактов\whatever.
А вот когда провожу ревью чужих ТЗ, то обращаю внимание на следующие критерии:
Собственно все эти пункты критерии можно применять и к написанным собственноручно требованиям - хотя это и тяжелее, потому что глаз замыливается капитально. Тут самое лучшее, что вы можете сделать - это дать требованиям полежать денек, вернуться к ним завтра и посмотреть не ерунда ли там написана)
Делитесь своими мыслями на эту тему в комментариях.
Please open Telegram to view this post
VIEW IN TELEGRAM
Mock Interview
Только что проводил очередное мок-интервью и по горячим следам могу выделить следующие преимущества работы в таком формате:
➖ Самый большой бонус в том, что можно отработать свои нервы, переживания, стресс в комфортной и неформальной обстановке, понимая при этом, что если ты сейчас ошибешься в ответе на вопрос, то не лишишься "последнего" шанса устроится на работу мечты;
➖ Происходит отработка навыков самопрезентации. Очень многие недооценивают важность первых 5-7 минут рассказа о себе или не умеют сформулировать краткую выжимку своего опыта и начинают растекаться мыслью по древу;
➖ ➖ Своеобразный подпункт о таймингах. Это очень важно (!). Не просто так я упомянул про 5-7 минут самопрезентации, потому что это идеальное время, в которое очень желательно уложить рассказ о себе. Никто не хочет слушать дополнительные 5 минут про не интересный и не актуальный опыт (относительно той позиции, на которую вы претендуете) десятилетней давности. Поэтому важно подсобрать весь ваш опыт и научиться его презентовать в короткие сроки;
➖ В процессе интервью определяем слабые места и нехватку теории\практики в определенных темах, чтобы закрыть их к "реальному" собеседованию;
➖ Попутная прокачка знаний. Так как я задаю не только различные вопросы с углубленным погружением во все области, которые всплывают на собеседованиях, но и даю ответы на них, если интервьюируемый затрудняется с ним. Правда, иногда я увлекаюсь и мои ответы превращаются в мини-лекцию, но ничего не могу с собой поделать 😅;
➖ Проработка уверенности в себе. За счет того, что ты уже понимаешь, как в среднем проходит интервью, чего ожидать от интервьюера, какие типы вопросов или задач он тебе задаст - ты начинаешь спокойнее вести себя на интервью и уже только за счет повышается качество его прохождения;
➖ Подсвечиваю, какие вопросы можно (а иногда и нужно) задать самому интервьюеру. Потому что часто забывают, что собеседование это двусторонний процесс и вы, в том числе, оцениваете потенциального работодателя по рассказу его представителя (интервьюера). Да и лично для меня достаточно странно звучит, когда человек на собеседовании не задает никаких вопросов про команду\процесс\задачи\культуру компании и так далее. Эта незаинтересованность (пусть даже это можно объяснить зажатостью) - расстраивает.
P.S. Был ли у вас опыт "прохождения" мок-интервью? Понравилось ли вам или было ли это полезно?
Только что проводил очередное мок-интервью и по горячим следам могу выделить следующие преимущества работы в таком формате:
P.S. Был ли у вас опыт "прохождения" мок-интервью? Понравилось ли вам или было ли это полезно?
Please open Telegram to view this post
VIEW IN TELEGRAM
Пример практической задачи на интервью
Вдогонку к теме с интервью поделюсь одним из вариантов практической задачи, которую мне уже очень давно задавали на собеседовании, и с тех пор я ее транслирую, когда сам выступаю в роли интервьюера.
Представим такой случай - вы СА на проекте "Школа" (обычная общеобразовательная). У школы есть сайт, что-то вроде дневник.ру, на котором можно посмотреть различные табели, оценки в разрезе классов, информацию об учителях, учениках - в общем что угодно. И директор, который является вашим заказчиком, заказал установку системы биометрического отслеживания прихода\ухода учеников. Условно говоря это сканеры отпечатков пальцев на турникетах у входа в школу, которые записывают время прихода\ухода учеников или учителей, в момент когда они прикладывают палец к сканеру. Эти данные хранятся в системе биометрии.
Суть задачи: директор очень хочет видеть табель прихода\ухода учеников и учителей на своем аналоге дневника.ру.
Для упрощения - вы владеете обеими системами и можете дорабатывать их как хотите, идентификаторы людей в дневнике и биометрии идентичны. На данный момент никакой интеграции между ними нет и системы не знают друг о друге. Соответственно у дневника.ру есть свой фронт и бэк, у системы биометрии есть только свой бэк и вот их надо подружить друг с другом таким образом, чтобы данные из биометрии каким-то чудом оказывались у директора"на столе" на его фронте.
Какой способ интеграции вы выберите, почему именно такой и как вы его реализуете?
Непосредственно на интервью я даю пару минут на подумать, позадавать вопросы мне, как к заказчику и после этого готов слушать ответ.
Давайте подискутируем в комментариях - как бы вы отвечали на такой вопрос на собеседовании, интересно послушать ваши варианты. Я с удовольствием отвечу на ваши вопросы или прокомментирую ответы.
Вдогонку к теме с интервью поделюсь одним из вариантов практической задачи, которую мне уже очень давно задавали на собеседовании, и с тех пор я ее транслирую, когда сам выступаю в роли интервьюера.
Представим такой случай - вы СА на проекте "Школа" (обычная общеобразовательная). У школы есть сайт, что-то вроде дневник.ру, на котором можно посмотреть различные табели, оценки в разрезе классов, информацию об учителях, учениках - в общем что угодно. И директор, который является вашим заказчиком, заказал установку системы биометрического отслеживания прихода\ухода учеников. Условно говоря это сканеры отпечатков пальцев на турникетах у входа в школу, которые записывают время прихода\ухода учеников или учителей, в момент когда они прикладывают палец к сканеру. Эти данные хранятся в системе биометрии.
Суть задачи: директор очень хочет видеть табель прихода\ухода учеников и учителей на своем аналоге дневника.ру.
Для упрощения - вы владеете обеими системами и можете дорабатывать их как хотите, идентификаторы людей в дневнике и биометрии идентичны. На данный момент никакой интеграции между ними нет и системы не знают друг о друге. Соответственно у дневника.ру есть свой фронт и бэк, у системы биометрии есть только свой бэк и вот их надо подружить друг с другом таким образом, чтобы данные из биометрии каким-то чудом оказывались у директора
Какой способ интеграции вы выберите, почему именно такой и как вы его реализуете?
Непосредственно на интервью я даю пару минут на подумать, позадавать вопросы мне, как к заказчику и после этого готов слушать ответ.
Давайте подискутируем в комментариях - как бы вы отвечали на такой вопрос на собеседовании, интересно послушать ваши варианты. Я с удовольствием отвечу на ваши вопросы или прокомментирую ответы.
Ответ на практическую задачу
Для начала - спасибо всем, кто писал свои ответы, я это ценю. Под последними постами получались хорошие дискуссии и это не может меня не радовать как автора.
По существу - вариантов ответов было предложено множество и были предложены прям очень интересные варианты и заходы с тех сторон, которые я даже не подразумевал в рамках задачи. Сразу видно, что настоящие системные аналитики читают и комментируют в том числе 😅
➖ Крепкий лайк за те ответы, где сначала задавались вопросы или рассматривалось несколько вариантов реализации, в зависимости от различных вводных.
Мы должны задавать вопросы и подстраивать реализацию (если это уместно), в зависимости от потребностей бизнеса. Потому что реализация интеграции для синхронного получения данных в онлайне на фронт директору - это одно, а реализации асинхронной интеграции в том случае, если нам нужны данные только за вчера и раньше - это уже совсем другое. А если нам нужно просто это в формате файла-отчета формировать - это вообще третье. И так далее.
Поэтому крайне рекомендую задавать свои уточняющие вопросы интервьюерам, когда они задают вам какие-то практические задачи - это их порадует и поставят вам лишние балл в уме за это.
➖ Лайк за то, что подумали про экономию денег для школы и выбор более дешевого варианта. Например, выбор RabbitMQ вместо kafka. Это не наша прямая обязанность, но проектировать решения с учетом бюджета заказчика - хороший скилл.
➖ Лайк за то, что превентивно думает про требования к безопасности и о том, что безопасники (хотя в условном примере и в условной школе их может и не быть вовсе) могу "забрить" ваше решение. Видимо кто-то много обжигался на этом)
➖ Лайк за проработку корнер-кейсов формата: "А что будет, если ученик забыл палец дома и он пройдет по биометрии другого человека? Как нам обрабатывать эту ситуацию". "А что будет, если он приложит палец, но не пройдет через турникет и убежит?". Отсюда родились, я считаю, вообще гениальные подробности на тему того, что турникеты имеют такую систему, что если его разблокировали, но при этом не прошли - то он удаляет запись о проходе (или что-то в этом духе).
Вот примерно такого я и жду от собеседуемого. Я всегда и в своих постах упоминал, и в целом клиентам говорю - что на собеседовании очень важно рассуждать, генерировать идеи, докапываться до различных корнер-кейсов - это здорово. Потому что навык "рассуждать" - это один из самых важных навыков, которые вы можете показать на собеседовании. Даже если вы не знаете точного ответа или с чем-то не сталкивались, но в своих рассуждениях подошли близко к правильному ответу - то это будет даже ценнее.
Сорри за оффтоп и очередное напоминание.
Пост получается слишком длинным и не влезает в формат телеги, поэтому мои предложенные решения в следующем.
↕️
Для начала - спасибо всем, кто писал свои ответы, я это ценю. Под последними постами получались хорошие дискуссии и это не может меня не радовать как автора.
По существу - вариантов ответов было предложено множество и были предложены прям очень интересные варианты и заходы с тех сторон, которые я даже не подразумевал в рамках задачи. Сразу видно, что настоящие системные аналитики читают и комментируют в том числе 😅
Мы должны задавать вопросы и подстраивать реализацию (если это уместно), в зависимости от потребностей бизнеса. Потому что реализация интеграции для синхронного получения данных в онлайне на фронт директору - это одно, а реализации асинхронной интеграции в том случае, если нам нужны данные только за вчера и раньше - это уже совсем другое. А если нам нужно просто это в формате файла-отчета формировать - это вообще третье. И так далее.
Поэтому крайне рекомендую задавать свои уточняющие вопросы интервьюерам, когда они задают вам какие-то практические задачи - это их порадует и поставят вам лишние балл в уме за это.
Вот примерно такого я и жду от собеседуемого. Я всегда и в своих постах упоминал, и в целом клиентам говорю - что на собеседовании очень важно рассуждать, генерировать идеи, докапываться до различных корнер-кейсов - это здорово. Потому что навык "рассуждать" - это один из самых важных навыков, которые вы можете показать на собеседовании. Даже если вы не знаете точного ответа или с чем-то не сталкивались, но в своих рассуждениях подошли близко к правильному ответу - то это будет даже ценнее.
Сорри за оффтоп и очередное напоминание.
Пост получается слишком длинным и не влезает в формат телеги, поэтому мои предложенные решения в следующем.
↕️
Please open Telegram to view this post
VIEW IN TELEGRAM
↕️
Теперь к сути, что конкретно по применяемым технологиям я еще хочу услышать. Желательно, чтобы было предложено несколько вариантов решения, как синхронных, так и асинхронных.
➖ По базе предложить выделить на бэке системы "Дневник.ру" новый сервис со своей базой и своими ручками и выделить на бэке системы биометрии схожий сервис. И при возникновении события на стороне биометрии сервис по триггеру отправляет запрос в сервис дневника, который сохраняет запись к себе.
➖ Можно предложить сделать GET-ручку на сервисе биометрии, по которой сервис дневника согласно своей логике будет получать все необходимые ему данные хоть по времени, хоть точечно по ученику, хоть еще как-то. Тоже рабочий вариант.
➖ Можно предложить реализовать какую-то джобу или на стороне биометрии или на стороне дневника, которая раз в N времени (хоть каждую секунду, хоть раз в сутки ночью) ходит в тот или другой сервис и забирает или отдает данные за минуту\час\день.
➖ Можно подумать на тему гарантированной доставки данных и прийти к брокерам. Реализовать по триггеру отправку данных в исходящий топик сервиса биометрии и вычитывать его в сервисе дневника, сохраняя данные к себе. Можно порассуждать на тему, какой именно брокер тут лучше подойдет и почему (например, лучше выбрать кролика, потому что объемы данных тут не большие, даже пиковая нагрузка слабенькая и он к тому же опенсорсный - поэтому как будто бы большая kafka тут и не нужна). Можно сюда с жиру докрутить еще transactional outbox pattern на стороне биометрии, вдобавок к кролику - чтобы прям точно данные не потерялись, ну прям никак.
➖ Можно предложить хоть обмен файлами, когда система биометрии будет раз в день формировать .csv файл, выкидывать его на интеграционную папку и сервис дневника будет его вычитывать, парсить данные и сохранять к себе.
Как вы поняли - вариантов очень много, все рабочие, все имеют какие-то свои преимущества и недостатки, но принят был бы любой. Тут самое главное для меня, как для интервьюера, понять - какие способы вы знаете, насколько умеете их готовить и насколько уверенно на ходу, за ограниченный промежуток времени, можете спроектировать решение.
P.S. Как вам такой формат, если мы периодически будем разбирать какие-то интересные задачки с собесов? Судя по количеству комментариев и реакций - вполне зашло, но если дадите еще обратной связи, я буду только рад.
Теперь к сути, что конкретно по применяемым технологиям я еще хочу услышать. Желательно, чтобы было предложено несколько вариантов решения, как синхронных, так и асинхронных.
Как вы поняли - вариантов очень много, все рабочие, все имеют какие-то свои преимущества и недостатки, но принят был бы любой. Тут самое главное для меня, как для интервьюера, понять - какие способы вы знаете, насколько умеете их готовить и насколько уверенно на ходу, за ограниченный промежуток времени, можете спроектировать решение.
P.S. Как вам такой формат, если мы периодически будем разбирать какие-то интересные задачки с собесов? Судя по количеству комментариев и реакций - вполне зашло, но если дадите еще обратной связи, я буду только рад.
Please open Telegram to view this post
VIEW IN TELEGRAM
Ироничное про людей
Вчера написал пост на Пикабу, который уже вам писал чуть ранее, про пример практической задачи на собеседовании. И я там привык к стандартной токсичности какой-то (пожалуй, не маленькой) и комментариям:
➖ "А что, тебя на хабре уже забанили, да?" (Это раньше был топ-1 комментарий, который появлялся почти под каждым моим постом);
➖ "А нафига ты сюда это пишешь? Пикабу это развлекательный ресурс, нам эта "твая тиория" не нужна тут";
➖ Комментарии с недовольством того, что я ссылку на ТГ-канал вставляю в свои посты (но это ладно, это я не осуждаю, очевидно что 70% постов на Пикабу пишутся только для того, чтобы привлечь кого-то куда-то, поэтому это всех достало);
➖"шитпост! автор убейся" (эх, а я еще помню времена когда всего лишь вежливо просили автора выпить яду);
И много чего еще, достаточно стандартного, того к чему авторы уже давно привыкли. Но были и забавные комментарии, мемы и так далее, формата: "Как пропатчить KDE2 под FreeBSD?" — это все одобряем.
Приятного и хорошего тоже было много, когда за меня заступались незнакомые мне люди, писали слова благодарности и задавали интересные вопросы. Многие приходили на обучение с Пикабу или просто писали, что вот я прочитал\а ваши посты и решилась на смену работы. Это меня и мотивирует что-то писать, на самом деле.
Я даже работу себе нашел благодаря Пикабу, когда один руководитель вдохновился моими постами, начал скидывать их своим БА\СА и связался со мной, предложив интересное сотрудничество.
К чему я все это пишу. В комментарии ко вчерашнему посту, почти что спустя наносекунду после его размещения, ворвался, видимо, "Рыцарь Свежего" и призвал модератора удалить мой пост на основании того.. Ну, вы готовы, да? (голосом Задорнова).. что я жирным выделяю и явно рекламирую сайт. Это он про дневник.ру, если что.
Такого со мной еще не было, но на тот момент я, с одной стороны, выпал в осадок, с другой прям очень пожалел, что министерство образования РФ не знает об этом и не доплачивает мне за каждый собес, на котором я упоминаю этот сайт. И за эти посты тоже, к сожалению(
Так что каждый раз забавно наблюдать за различными реакциями у разных людей на одно и то же. Но поймал себя на мысли, что это пересекается с работой (конечно, как не привести любую историю к любимой работе аналитика) в том контексте, что когда ты собираешь или пишешь требования - нужно всегда держать в голове то, что ты можешь написать даже абсолютно очевидным и недвусмысленным образом какой-то тезис, но кто-то, один хрен, все переврет и поймет по-другому. А потом решать конфликтные ситуации с заказчиком или баги из-за этого)
И сколько раз такое бывало, что происходит разбор какого-то бага и тебе разработчик или тестер говорит: "Ну вот в требованиях написано вот так, а оно работает не так\я реализовал по требованиям". И ты прям на созвоне вслух зачитываешь требование, которые ты написал и человек такой: "А, ну да.. Чет вообще не так понял, пойду править".
Ну и не буду строить из себя непогрешимого, это вполне работает и в обратную сторону. Когда ты читаешь какое-нибудь БТ, читаешь через одно место, пишешь ТЗ соответственно неправильно и потом к тебе точно также приходят и тыкают носом. Бывает всякое, я без осуждения)
P.S. А что вы думаете об этом всем? Сталкиваетесь ли в своей работе с такой разницей восприятия на, казалось бы, очевидные вещи?
Вчера написал пост на Пикабу, который уже вам писал чуть ранее, про пример практической задачи на собеседовании. И я там привык к стандартной токсичности какой-то (пожалуй, не маленькой) и комментариям:
➖ "А что, тебя на хабре уже забанили, да?" (Это раньше был топ-1 комментарий, который появлялся почти под каждым моим постом);
➖ "А нафига ты сюда это пишешь? Пикабу это развлекательный ресурс, нам эта "твая тиория" не нужна тут";
➖ Комментарии с недовольством того, что я ссылку на ТГ-канал вставляю в свои посты (но это ладно, это я не осуждаю, очевидно что 70% постов на Пикабу пишутся только для того, чтобы привлечь кого-то куда-то, поэтому это всех достало);
➖"шитпост! автор убейся" (эх, а я еще помню времена когда всего лишь вежливо просили автора выпить яду);
И много чего еще, достаточно стандартного, того к чему авторы уже давно привыкли. Но были и забавные комментарии, мемы и так далее, формата: "Как пропатчить KDE2 под FreeBSD?" — это все одобряем.
Приятного и хорошего тоже было много, когда за меня заступались незнакомые мне люди, писали слова благодарности и задавали интересные вопросы. Многие приходили на обучение с Пикабу или просто писали, что вот я прочитал\а ваши посты и решилась на смену работы. Это меня и мотивирует что-то писать, на самом деле.
Я даже работу себе нашел благодаря Пикабу, когда один руководитель вдохновился моими постами, начал скидывать их своим БА\СА и связался со мной, предложив интересное сотрудничество.
К чему я все это пишу. В комментарии ко вчерашнему посту, почти что спустя наносекунду после его размещения, ворвался, видимо, "Рыцарь Свежего" и призвал модератора удалить мой пост на основании того.. Ну, вы готовы, да? (голосом Задорнова).. что я жирным выделяю и явно рекламирую сайт. Это он про дневник.ру, если что.
Такого со мной еще не было, но на тот момент я, с одной стороны, выпал в осадок, с другой прям очень пожалел, что министерство образования РФ не знает об этом и не доплачивает мне за каждый собес, на котором я упоминаю этот сайт. И за эти посты тоже, к сожалению(
Так что каждый раз забавно наблюдать за различными реакциями у разных людей на одно и то же. Но поймал себя на мысли, что это пересекается с работой (конечно, как не привести любую историю к любимой работе аналитика) в том контексте, что когда ты собираешь или пишешь требования - нужно всегда держать в голове то, что ты можешь написать даже абсолютно очевидным и недвусмысленным образом какой-то тезис, но кто-то, один хрен, все переврет и поймет по-другому. А потом решать конфликтные ситуации с заказчиком или баги из-за этого)
И сколько раз такое бывало, что происходит разбор какого-то бага и тебе разработчик или тестер говорит: "Ну вот в требованиях написано вот так, а оно работает не так\я реализовал по требованиям". И ты прям на созвоне вслух зачитываешь требование, которые ты написал и человек такой: "А, ну да.. Чет вообще не так понял, пойду править".
Ну и не буду строить из себя непогрешимого, это вполне работает и в обратную сторону. Когда ты читаешь какое-нибудь БТ, читаешь через одно место, пишешь ТЗ соответственно неправильно и потом к тебе точно также приходят и тыкают носом. Бывает всякое, я без осуждения)
P.S. А что вы думаете об этом всем? Сталкиваетесь ли в своей работе с такой разницей восприятия на, казалось бы, очевидные вещи?
Сообщество аналитиков на Пикабу
Еще немного в тему Пикабу - я вчера создал сообщество аналитиков. До этого все посты я выкладывал с привязкой к Лиге Программистов, но сколько можно их уже отвлекать своей аналитикой и гневить почем зря)
Поэтому - если вы вдруг когда-либо хотели начать писать какие-то статьи, делиться историями из работы или своей практики, как будто бы теперь у вас есть уютное (я надеюсь) место хотя бы на Пикабу, откуда можно начать это делать.
Любая активность приветствуется, тем более такая как шутки и юмор. Кстати, если вы сможете в комменты сюда предложить какую-нибудь прикольную и говорящую картинку или мем, который мог бы стать аватаркой для этого сообщества - я буду прям очень признателен, одного моего креатива тут явно не хватает, нужна помощь)
Вот ссылка на сообщество. А вот ссылка на пост, в котором я рассказываю о его создании.
Еще немного в тему Пикабу - я вчера создал сообщество аналитиков. До этого все посты я выкладывал с привязкой к Лиге Программистов, но сколько можно их уже отвлекать своей аналитикой и гневить почем зря)
Поэтому - если вы вдруг когда-либо хотели начать писать какие-то статьи, делиться историями из работы или своей практики, как будто бы теперь у вас есть уютное (я надеюсь) место хотя бы на Пикабу, откуда можно начать это делать.
Любая активность приветствуется, тем более такая как шутки и юмор. Кстати, если вы сможете в комменты сюда предложить какую-нибудь прикольную и говорящую картинку или мем, который мог бы стать аватаркой для этого сообщества - я буду прям очень признателен, одного моего креатива тут явно не хватает, нужна помощь)
Вот ссылка на сообщество. А вот ссылка на пост, в котором я рассказываю о его создании.
Про отпуск и отдых в целом
У меня сегодня первый рабочий день после отпуска - пытаюсь понять где я, какой сегодня год спринт и что вообще происходит. В общем обычная послеотпускная рутина.
Но не об этом, на самом деле хотел поделиться одной мыслью - оказывается можно просто уйти в отпуск, ничего не планировать и отдыхать. Ужс, да? Лично для меня - да.
Все предыдущие 9 лет моей работы у меня каждый отпуск был так или иначе распланирован и несмотря на то, что вроде бы не надо было работать - но нужно было проводить обучения, делать что-то по дому, ехать на море, за границу, куда-нибудь (нужное подчеркнуть) и там тоже обязательно что-то делать, потому что просто отдыхать в номере естественно табу.
И так выдалось, что всю позапрошлую неделю я был в отпуске и у меня не было абсолютно никаких планов 😱. Когда наступил понедельник я даже растерялся и начал по привычке читать все рабочие чаты, продумывать как я буду решать после отпуска свои рабочие задачи - в общем абсолютно не мог замедлиться и переключиться с работы на отдых.
Забавное состояние на самом деле, поймал себя на нем и понял что это отдельный повод для рефлексии)
Но потом к середине недели я уже привык, абстрагировался от работы и начал спокойно проходить FF XVI и вторую Готику, еще больше читать и ходить на тренировки. О работе напоминал только голос жены, которая постоянно вела свои консультации из своего кабинета (вот он - минус работы на себя).
Правда вторая неделя была уже более привычной - 14-ти часовые перелеты, бесконечные (как мне казалось) тысячи шагов в гору по Принцевым островам, по самому Стамбулу и его окресностям. Но силы на это были за неделю скоплены, поэтому я с большим удовольствием провел неделю в прогулках по этому красивому городу и его достопримечательностям. В этот раз посетили все то, что не успевали посмотреть в предыдущие разы.
В качестве заключения могу сказать, что для себя понял - насколько важно просто ничего не делать (хотя бы иногда), отключать мозг совсем или переключать его с рабочих и достигаторских задач на какие-то нейтральные.
Раньше еще я был большим любителем в принципе не ходить в отпуск и после увольнения с работы у меня было по 40+ неистраченных отпускных дней. Сейчас я уже слишком стар для этого и так не могу, хотя вижу по коллегам, что они до сих пор продолжают так делать (а потом выгорают и увольняются).
P.S. А как вы ходите в отпуск? Или тоже "храните" деньги в отпускных днях?
У меня сегодня первый рабочий день после отпуска - пытаюсь понять где я, какой сегодня
Но не об этом, на самом деле хотел поделиться одной мыслью - оказывается можно просто уйти в отпуск, ничего не планировать и отдыхать. Ужс, да? Лично для меня - да.
Все предыдущие 9 лет моей работы у меня каждый отпуск был так или иначе распланирован и несмотря на то, что вроде бы не надо было работать - но нужно было проводить обучения, делать что-то по дому, ехать на море, за границу, куда-нибудь (нужное подчеркнуть) и там тоже обязательно что-то делать, потому что просто отдыхать в номере естественно табу.
И так выдалось, что всю позапрошлую неделю я был в отпуске и у меня не было абсолютно никаких планов 😱. Когда наступил понедельник я даже растерялся и начал по привычке читать все рабочие чаты, продумывать как я буду решать после отпуска свои рабочие задачи - в общем абсолютно не мог замедлиться и переключиться с работы на отдых.
Забавное состояние на самом деле, поймал себя на нем и понял что это отдельный повод для рефлексии)
Но потом к середине недели я уже привык, абстрагировался от работы и начал спокойно проходить FF XVI и вторую Готику, еще больше читать и ходить на тренировки. О работе напоминал только голос жены, которая постоянно вела свои консультации из своего кабинета (вот он - минус работы на себя).
Правда вторая неделя была уже более привычной - 14-ти часовые перелеты, бесконечные (как мне казалось) тысячи шагов в гору по Принцевым островам, по самому Стамбулу и его окресностям. Но силы на это были за неделю скоплены, поэтому я с большим удовольствием провел неделю в прогулках по этому красивому городу и его достопримечательностям. В этот раз посетили все то, что не успевали посмотреть в предыдущие разы.
В качестве заключения могу сказать, что для себя понял - насколько важно просто ничего не делать (хотя бы иногда), отключать мозг совсем или переключать его с рабочих и достигаторских задач на какие-то нейтральные.
Раньше еще я был большим любителем в принципе не ходить в отпуск и после увольнения с работы у меня было по 40+ неистраченных отпускных дней. Сейчас я уже слишком стар для этого и так не могу, хотя вижу по коллегам, что они до сих пор продолжают так делать (а потом выгорают и увольняются).
P.S. А как вы ходите в отпуск? Или тоже "храните" деньги в отпускных днях?
Модель зрелости REST API Ричардсона
Много рассказывал про API, в частности про то, что есть очень много подходов к проектированию сервисов и очень много холиваров на тему того, что является REST, как правильно проектировать эндпоинты, обзывать сущности и так далее. Мне кажется, что такие концепции, как модель зрелости Ричардсона родились как раз из-за того, что тысячи копий были сломаны в обсуждениях на эту тему.
О чем она?
Модель зрелости REST API - концепция, которая оценивает API по нескольким параметрам и определяет, насколько этот интерфейс соответствует принципам REST. Т.е. является ли ваш сервис простым RPC или он уже эволюционировал в полноценный REST. Чем выше "уровень" вашего сервиса, тем лучше (по мнению Ричардсона) он спроектирован.
Уровни зрелости модели
➖ Уровень 0: API как RPC
Сервис имеет единственный URI, который использует единственный HTTP-метод (в основном POST). Т.е. API является точкой входа, которая принимает параметры и возвращает результат.По сути используется просто как обертка для вызова удаленных процедур (т.е. стандартный RPC), не используя RESTful принципы вообще.
Например: POST /api, в теле которого передается {"action": "deleteOrder", "data": {id: "123", ...}}.
Как видим из примера, запрос обрабатывается не как операция с ресурсом (как мы привыкли), а как действие.
➖ Уровень 1: Resources
Сервис на этом уровне имеет несколько URI, каждый из которых использует только один HTTP метод. Разница между нулевым и первым уровне заключается в том, что на первом уровне сервис выставляет множество логических ресурсов, а на нулевом уровне сервис объединяет все взаимодействия через единственный (и намного более сложный) ресурс.
Кроме этого, в сервисах этого уровня имена операций, параметров и даже действий зашиты в сам URI.
Например: POST /deleteOrder. Или POST /getOrders.
➖ Уровень 2: HTTP-verbs
Сервис на этом уровне имеет много URI-адресуемых ресурсов и использует несколько HTTP-методов для каждого из них. Тут мы начинаем работать с концепцией CRUD, т.е. с управлением состояния ресурса (бизнес-сущности) через отдельные ручки.
То есть тут уже используется все многообразие методов (GET, POST, PUT, PATCH, DELETE), используем корректные коды ответа (200, 201, 404 и т.д.).
Например:
GET /orders/123
DELETE /orders/123
➖ Уровень 3: HATEOAS
Самый высокий уровень зрелости в рамка этой модели.
На этом уровне сервис предоставляет не только возможности работы с данными, но и гиперссылки на них, которые показывают те действия, которые пользователь может совершить с данными.
И кроме этого получается, что ресурсы сами описывают свои возможности и взаимосвязи в формате само-документации.
По-другому это называется HATEOAS (Hypermedia as the Engine of Application State) — характеристика веб-сервиса возвращать действия, которые могут быть выполнены с ресурсом, в виде URL
Пример использования HATEOAS:
Есть сервис, который предоставляет возможность управлять заказами клиента. В ответ на запрос списка заказов сервер может вернуть ответ, в котором в том числе, будут гиперссылки:
➖ self — ссылка на текущий ресурс;
➖ update — ссылка на ресурс обновления заказа;
➖ delete — ссылка на ресурс удаления заказа.
P.S. А у вас сервисы какого уровня? Оценивали ли вы их?
Лично я на своей практики ни разу, кажется, на видел сервисов выше 2 уровня. Зачастую, это может быть излишне и в большинстве случаев просто нет такой необходимости. Но если кто-то сталкивался с таким - расскажите про свой опыт, пожалуйста.
Много рассказывал про API, в частности про то, что есть очень много подходов к проектированию сервисов и очень много холиваров на тему того, что является REST, как правильно проектировать эндпоинты, обзывать сущности и так далее. Мне кажется, что такие концепции, как модель зрелости Ричардсона родились как раз из-за того, что тысячи копий были сломаны в обсуждениях на эту тему.
О чем она?
Модель зрелости REST API - концепция, которая оценивает API по нескольким параметрам и определяет, насколько этот интерфейс соответствует принципам REST. Т.е. является ли ваш сервис простым RPC или он уже эволюционировал в полноценный REST. Чем выше "уровень" вашего сервиса, тем лучше (по мнению Ричардсона) он спроектирован.
Уровни зрелости модели
Сервис имеет единственный URI, который использует единственный HTTP-метод (в основном POST). Т.е. API является точкой входа, которая принимает параметры и возвращает результат.По сути используется просто как обертка для вызова удаленных процедур (т.е. стандартный RPC), не используя RESTful принципы вообще.
Например: POST /api, в теле которого передается {"action": "deleteOrder", "data": {id: "123", ...}}.
Как видим из примера, запрос обрабатывается не как операция с ресурсом (как мы привыкли), а как действие.
Сервис на этом уровне имеет несколько URI, каждый из которых использует только один HTTP метод. Разница между нулевым и первым уровне заключается в том, что на первом уровне сервис выставляет множество логических ресурсов, а на нулевом уровне сервис объединяет все взаимодействия через единственный (и намного более сложный) ресурс.
Кроме этого, в сервисах этого уровня имена операций, параметров и даже действий зашиты в сам URI.
Например: POST /deleteOrder. Или POST /getOrders.
Сервис на этом уровне имеет много URI-адресуемых ресурсов и использует несколько HTTP-методов для каждого из них. Тут мы начинаем работать с концепцией CRUD, т.е. с управлением состояния ресурса (бизнес-сущности) через отдельные ручки.
То есть тут уже используется все многообразие методов (GET, POST, PUT, PATCH, DELETE), используем корректные коды ответа (200, 201, 404 и т.д.).
Например:
GET /orders/123
DELETE /orders/123
Самый высокий уровень зрелости в рамка этой модели.
На этом уровне сервис предоставляет не только возможности работы с данными, но и гиперссылки на них, которые показывают те действия, которые пользователь может совершить с данными.
И кроме этого получается, что ресурсы сами описывают свои возможности и взаимосвязи в формате само-документации.
По-другому это называется HATEOAS (Hypermedia as the Engine of Application State) — характеристика веб-сервиса возвращать действия, которые могут быть выполнены с ресурсом, в виде URL
Пример использования HATEOAS:
Есть сервис, который предоставляет возможность управлять заказами клиента. В ответ на запрос списка заказов сервер может вернуть ответ, в котором в том числе, будут гиперссылки:
{
"orders": [
{
"id": 1,
"goodsName": "Table",
"status": "PAID",
"_links": {
"self": "/orders/1",
"update": "/orders/1/update",
"delete": "/orders/1/delete"
}
},
...P.S. А у вас сервисы какого уровня? Оценивали ли вы их?
Лично я на своей практики ни разу, кажется, на видел сервисов выше 2 уровня. Зачастую, это может быть излишне и в большинстве случаев просто нет такой необходимости. Но если кто-то сталкивался с таким - расскажите про свой опыт, пожалуйста.
Please open Telegram to view this post
VIEW IN TELEGRAM
Postman и его практическое применение
Postman — один из основных инструментов тестировщиков, который позволяет тестировать API.
Вообще этот сервис предоставляет больше функций, чем просто тестирование — это еще и создание, публикация, документирование API, но в основном он используется именно для тестирования, т.к. позволяет "дергать" ручки ваших сервисов.
Как он работает?
Для начала вам необходимо зарегистрироваться на официальном сайте сервиса. После этого необходимо создать своё рабочее пространство, нажав на соответствующую кнопку Create Workspace. Далее выбираете по умолчанию пустое пространство (Blank workspace) и нажимаете далее, придумав какое-то имя для своего пространства.
В общем-то самое сложное уже сделано - у вас теперь есть рабочее пространство, в котором вы можете делать все что хотите, вплоть до создания своих собственных API.
Но я предлагаю воспользоваться API, которые уже есть в свободном доступе, например, с помощью ресурса DaData. Этот сервис предоставляет тонну апишек, которые можно подергать бесплатно, для этого достаточно просто зарегистрироваться (это необходимо, чтобы вам присвоили secret key и token без которого вы будете получать 401 ошибку).
После регистрации выбираете любую понравившуюся вам ручку для использования (можно хоть все). Пусть будет ручка стандартизации адресов (которой, кстати, пользуются много компаний, как и вообще DaDat'ой в целом). Тут вы можете почитать спецификацию этой ручки, посмотреть с каким request\response она работает, посмотреть корнер-кейсы и в целом варианты использования. Спецификация специфичная (сорри за тавтологию), но это один из вариантов того, как можно их писать — и, в целом, по ней все понятно.
После этого вам нужно скопировать cURL этой ручки и вставить ее в вашу коллекцию в Postman через кнопку Import. После вставки Postman сразу "кушает" cURL и преобразует его в понятный вид, подставляя в заголовки ваш токен и ключ, а в тело сообщения дефолтный пример, предложенный самой DaData. Собсна, вы можете сразу нажать на кнопку Send и отправить запрос с дефолтными параметрами, которое было зашито в cURL, и посмотреть какой результат вам вернется.
После этого, я обычно рекомендую своим ученикам, поиграться с Headers и Body, редактируя их по своему усмотрению. Например, выключая передачу токенов, передавая пустое тело (или нулловое), передавая массив строк в теле и так далее. И смотреть как ответы меняются в зависимости от того, что вы передали.
Для новичков это прям полезно и неплохо помогает посмотреть на логику работы API с другой стороны, непосредственно используя его. Когда пощупаешь логику работы ручки снаружи - потом проще проектировать сервисы изнутри — проверено.
P.S. Приходилось ли вам использовать Postman не просто в образовательных целях, но и вполне в рабочих? Для тестирования, например?
Postman — один из основных инструментов тестировщиков, который позволяет тестировать API.
Вообще этот сервис предоставляет больше функций, чем просто тестирование — это еще и создание, публикация, документирование API, но в основном он используется именно для тестирования, т.к. позволяет "дергать" ручки ваших сервисов.
Как он работает?
Для начала вам необходимо зарегистрироваться на официальном сайте сервиса. После этого необходимо создать своё рабочее пространство, нажав на соответствующую кнопку Create Workspace. Далее выбираете по умолчанию пустое пространство (Blank workspace) и нажимаете далее, придумав какое-то имя для своего пространства.
В общем-то самое сложное уже сделано - у вас теперь есть рабочее пространство, в котором вы можете делать все что хотите, вплоть до создания своих собственных API.
Но я предлагаю воспользоваться API, которые уже есть в свободном доступе, например, с помощью ресурса DaData. Этот сервис предоставляет тонну апишек, которые можно подергать бесплатно, для этого достаточно просто зарегистрироваться (это необходимо, чтобы вам присвоили secret key и token без которого вы будете получать 401 ошибку).
После регистрации выбираете любую понравившуюся вам ручку для использования (можно хоть все). Пусть будет ручка стандартизации адресов (которой, кстати, пользуются много компаний, как и вообще DaDat'ой в целом). Тут вы можете почитать спецификацию этой ручки, посмотреть с каким request\response она работает, посмотреть корнер-кейсы и в целом варианты использования. Спецификация специфичная (сорри за тавтологию), но это один из вариантов того, как можно их писать — и, в целом, по ней все понятно.
После этого вам нужно скопировать cURL этой ручки и вставить ее в вашу коллекцию в Postman через кнопку Import. После вставки Postman сразу "кушает" cURL и преобразует его в понятный вид, подставляя в заголовки ваш токен и ключ, а в тело сообщения дефолтный пример, предложенный самой DaData. Собсна, вы можете сразу нажать на кнопку Send и отправить запрос с дефолтными параметрами, которое было зашито в cURL, и посмотреть какой результат вам вернется.
После этого, я обычно рекомендую своим ученикам, поиграться с Headers и Body, редактируя их по своему усмотрению. Например, выключая передачу токенов, передавая пустое тело (или нулловое), передавая массив строк в теле и так далее. И смотреть как ответы меняются в зависимости от того, что вы передали.
Для новичков это прям полезно и неплохо помогает посмотреть на логику работы API с другой стороны, непосредственно используя его. Когда пощупаешь логику работы ручки снаружи - потом проще проектировать сервисы изнутри — проверено.
P.S. Приходилось ли вам использовать Postman не просто в образовательных целях, но и вполне в рабочих? Для тестирования, например?
OpenAPI
В прошлую пятницу проводил митап для коллег, которым рассказывал про то, что такое OpenAPI, как им пользоваться и как с помощью него вести спецификацию наших сервисов.
Получилось душевно, с интересными вопросами, в том числе из разряда "А это вообще реально применить у нас и договориться с разработчиками об использовании такого подхода?" Что, кстати, является весьма важным поинтом, потому что без их участия это все бессмысленно - особенно если они будут игнорировать описанные контракты и делать отсебятину, без оповещения аналитика об изменениях. Но на этот вопрос у меня не было ответа)
Планирую провести на эту тему воркшоп в следующем месяце. Когда подготовлю кейсы и буду готов - сделаю дополнительный анонс.
Я уже рассказывал про Swagger\OpenAPI вот в этом посте. Сейчас хочу более подробно раскрыть те блоки, из которых состоит контракт, описанный в спецификации OpenAPI, и что в них нужно указывать.
Но перед этим важно упомянуть, что между версиями спецификации 2.0 и 3.0 есть достаточно весомые отличия, особенно в наименовании различных полей (хоть и общая суть идентична), которую тоже стоит учитывать. Я буду рассказывать сразу про версию 3.0, т.к. она наиболее актуальная на данный момент.
И еще момент, советую для описания использовать editor.swagger.io, т.к. это наиболее удобный и широкий инструмент, который кроме всех прочих функций будет отображать вам визуальное представление описанных контрактов и валидировать его. Можно прям открыть его, при первом открытии у вас откроется пет-проект, который можно поизучать.
Список корневых элементов контракта:
➖ openapi: 3.0.0
Это обязательный атрибут спецификации, без которого она не будет считаться валидной. Тут указывается именно версия спецификации, не контракта вашего сервиса.
➖ info:
Этот блок также является обязательным. В нем мы задаем наименование нашего сервиса, его версию, описание и различную контактную информацию (например, какая команда им владеет, чтобы можно было понять, к кому обращаться с вопросами).
➖ externalDocs:
В этом блоке можем дать различные ссылки на документацию сервиса, например на описание его логики работы в конфлюенсе.
➖ servers:
Тут мы можем указать массив ссылок на сервера, на которых крутится описываемый сервис. Например его хосты с прода и теста.
➖ tags:
В этом блоке мы можем задать массив тэгов, которые потом сможем присваивать нашим endpoint'ам. Тэги — это просто визуальная группировка наших методов по бизнес-юниту, по какому-то техническому признаку или вашему хотению. Например, если ваш микросервис работает с заявкой на кредит, то вы можете выделить тэги LoanApplication, ApplicationOffers, ApplicationStatus, ApplicationScore и т.д. И каждому методу, который вы будете далее описывать присвоить один или несколько из этих тэгов.
➖ components:
Это очень важный блок, в котором вы описываете модель данных, с которой работают ваши методы. Это необходимо для того, чтобы в рамках контракта один раз задать какие-либо сущности и потом просто ссылаться на них, вместо того, чтобы объявлять в рамках каждого метода одни и те же объекты. Например, у вас есть метод, который возвращает список заявок и метод, который возвращает одну конкретную. Модель данных у них будет почти одинаковая, кроме того, что в первом случае будет массив заявок. И вот вместо того, чтобы в двух местах описывать все сотни атрибутов, которыми обладает заявка - мы делаем это один раз и потом ссылаемся на эти сущности.
➖ paths:
Самый важный и тоже обязательный блок. Именно в рамках него мы описываем все имеющиеся endpoint'ы и все их методы. Как это сделать - расскажу в следующем посте.
Итого: для проектирования контракта нужно минимально иметь блок openapi, info и paths. Остальные опциональные (но очень желательно их тоже описывать).
В прошлую пятницу проводил митап для коллег, которым рассказывал про то, что такое OpenAPI, как им пользоваться и как с помощью него вести спецификацию наших сервисов.
Получилось душевно, с интересными вопросами, в том числе из разряда "А это вообще реально применить у нас и договориться с разработчиками об использовании такого подхода?" Что, кстати, является весьма важным поинтом, потому что без их участия это все бессмысленно - особенно если они будут игнорировать описанные контракты и делать отсебятину, без оповещения аналитика об изменениях. Но на этот вопрос у меня не было ответа)
Планирую провести на эту тему воркшоп в следующем месяце. Когда подготовлю кейсы и буду готов - сделаю дополнительный анонс.
Я уже рассказывал про Swagger\OpenAPI вот в этом посте. Сейчас хочу более подробно раскрыть те блоки, из которых состоит контракт, описанный в спецификации OpenAPI, и что в них нужно указывать.
Но перед этим важно упомянуть, что между версиями спецификации 2.0 и 3.0 есть достаточно весомые отличия, особенно в наименовании различных полей (хоть и общая суть идентична), которую тоже стоит учитывать. Я буду рассказывать сразу про версию 3.0, т.к. она наиболее актуальная на данный момент.
И еще момент, советую для описания использовать editor.swagger.io, т.к. это наиболее удобный и широкий инструмент, который кроме всех прочих функций будет отображать вам визуальное представление описанных контрактов и валидировать его. Можно прям открыть его, при первом открытии у вас откроется пет-проект, который можно поизучать.
Список корневых элементов контракта:
Это обязательный атрибут спецификации, без которого она не будет считаться валидной. Тут указывается именно версия спецификации, не контракта вашего сервиса.
Этот блок также является обязательным. В нем мы задаем наименование нашего сервиса, его версию, описание и различную контактную информацию (например, какая команда им владеет, чтобы можно было понять, к кому обращаться с вопросами).
В этом блоке можем дать различные ссылки на документацию сервиса, например на описание его логики работы в конфлюенсе.
Тут мы можем указать массив ссылок на сервера, на которых крутится описываемый сервис. Например его хосты с прода и теста.
В этом блоке мы можем задать массив тэгов, которые потом сможем присваивать нашим endpoint'ам. Тэги — это просто визуальная группировка наших методов по бизнес-юниту, по какому-то техническому признаку или вашему хотению. Например, если ваш микросервис работает с заявкой на кредит, то вы можете выделить тэги LoanApplication, ApplicationOffers, ApplicationStatus, ApplicationScore и т.д. И каждому методу, который вы будете далее описывать присвоить один или несколько из этих тэгов.
Это очень важный блок, в котором вы описываете модель данных, с которой работают ваши методы. Это необходимо для того, чтобы в рамках контракта один раз задать какие-либо сущности и потом просто ссылаться на них, вместо того, чтобы объявлять в рамках каждого метода одни и те же объекты. Например, у вас есть метод, который возвращает список заявок и метод, который возвращает одну конкретную. Модель данных у них будет почти одинаковая, кроме того, что в первом случае будет массив заявок. И вот вместо того, чтобы в двух местах описывать все сотни атрибутов, которыми обладает заявка - мы делаем это один раз и потом ссылаемся на эти сущности.
Самый важный и тоже обязательный блок. Именно в рамках него мы описываем все имеющиеся endpoint'ы и все их методы. Как это сделать - расскажу в следующем посте.
Итого: для проектирования контракта нужно минимально иметь блок openapi, info и paths. Остальные опциональные (но очень желательно их тоже описывать).
Please open Telegram to view this post
VIEW IN TELEGRAM