🔤🔤🔤🔤🔤: что это и зачем знать аналитикам?

В последнее время всё чаще слышу от разрабов фразы вроде: «Ну мы дергаем их фейн…», «Там фейн запросы делает…». Кажется, что в контексте диалога всё понятно — особенно когда тебе шарят экран и вы обсуждаете задачу.

Но если попытаться объяснить своими словами, выходит что-то вроде: «Ну, это такая штука в коде…» 🤔

Давайте разберёмся, что же такое Feign на самом деле, как он работает и почему о нём стоит знать.

Что такое Feign?
Feign — это декларативный HTTP-клиент для Java, который придумали в Netflix, чтобы упростить взаимодействие с RESTful веб-сервисами. С Feign можно написать пару строк кода вместо полноценного запроса, оставляя остальную логику библиотеке. Всё делается через аннотации в интерфейсах, так что работать с внешними API становится намного проще.

Как это работает на практике?🦔
Например, банк сотрудничает с внешними сервисами для проверки кредитных историй. Когда пользователь подаёт заявку на кредит, система отправляет запрос в эти сервисы, чтобы узнать его кредитную историю. Вместо того чтобы писать длинный код для каждого запроса, разработчик создаёт интерфейс и "дергает их фейн":

@FeignClient(name = "credit-history-client", url = "https://api.creditcheck.com")
public interface CreditHistoryClient {

    @GetMapping("/history")
    CreditHistoryResponse getCreditHistory(@RequestParam("userId") String userId);
}

Здесь FeignClient указывает базовый URL, а GetMapping настраивает конкретный запрос. Теперь, чтобы узнать кредитную историю клиента, достаточно вызвать метод getCreditHistory() — Feign автоматически сделает всю работу за кулисами.

Зачем это знать аналитикам? 🤔
✅Во-первых, чтобы быть в одной плоскости с разработчиками и лучше понимать, как работают интеграции между системами.

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

А вы сталкивались с Feign в своей работе? Часто ли вообще приходится смотреть в код? Делитесь опытом в комментариях👇

И снова здравствуйте💋

Если кто-то не знает, когда-то давно я работал в тех.поддержке и с тех времен осталось много рофлов пользователей. Их можно посмотреть под тэгом #поддержка

IT АНАЛитика

Тут на примерах с кодом объясняют, что такое микросервисы для аналитиков.

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

Ознакомиться📕

🔤🔤🔤🔤🔤🔤🔤🔤🔤: что это и зачем?

В продолжении поста про Feign, есть ещё одна вещь, о которой стоит знать аналитикам — ConfigMap. Если вы работаете с проектами, где используется Kubernetes, то наверняка слышали фразу: «Эта настройка лежит в конфигмапе».

Что такое ConfigMap?
ConfigMap — это объект в Kubernetes, который хранит конфигурационные данные приложения. Это ключевой инструмент для управления настройками, такими как:

➡️адреса API,
➡️ключи доступа,
➡️параметры подключения,
➡️другие переменные, которые могут меняться в зависимости от среды (разработка, тестирование, прод).

Вместо того чтобы "хардкодить" эти параметры в приложении и пересобирать код при каждом изменении, их выносят в ConfigMap. Это даёт возможность обновлять настройки, без остановки работы приложения.

Пример📄
Представьте, у вас есть сервис для отправки уведомлений клиентам. В зависимости от окружения (тест, прод) он должен использовать разные SMTP-серверы для отправки писем. Вместо того чтобы каждый раз менять настройки прямо в коде, эти данные выносят:

apiVersion: v1
kind: ConfigMap
metadata:
  name: smtp-config
data:
  SMTP_SERVER: "smtp.mailserver.com"
  SMTP_PORT: "587"
  SMTP_USER: "noreply@example.com"

И теперь приложение просто подтягивает нужные параметры из ConfigMap. Если вам нужно сменить сервер или обновить логин — достаточно поменять значение, и приложение подхватит новые настройки без необходимости пересобирать код или перезапускать весь сервис.

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

IT АНАЛитика

Иногда конечно бывает смешно, когда в резюме у тебя написано одно, а предлагают совершенно другое😐


IT АНАЛитика

Прибейте меня, я веду проект с нуля. Часть 1🍑

Вы — аналитик, и вам поручили вести новый проект или большую задачу с нуля. Что делать? С чего начать? Объём работы душит, глаза разбегаются, хочется плакать.

Но на самом деле всё не так страшно, как кажется. Недавно на консультации разбирал подобный вопрос, и захотелось сделать серию постов, чтобы разложить всё по полочкам. Let's go🚬

Шаг 1. Первичное погружение 🧐
Хорошо, если у бизнеса есть чёткая постановка. Ещё лучше, если она понятная. И мега кайф, когда он точно знает чего хочет.

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

1. Цели проекта: Зачем он нужен бизнесу? Какую проблему решает?
2. Конечные пользователи: Кто они? Что для них важно?
3. Интеграции: Есть ли системы, с которыми проекту нужно взаимодействовать?

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

Шаг 2. Заводим раздел под документацию 📂
Документация — ваш главный бро. Организуйте место, где вы будете:

А. Хранить протоколы встреч.
Б. Описывать функционал.
В. Фиксировать все важные детали проекта.

Используйте Confluence, Google Docs или любую другую систему, удобную для всей команды. Главное, чтобы всё было доступно, структурировано и понятно другим участникам проекта.

Шаг 3. Работаем с требованиями 🙅‍♂️
Мы и до этого с ними считай работали, но теперь все серьезно:

🤟Если требования есть:

1. Тщательно изучаем.
2. Ищем пробелы и неясности.
3. Назначаем встречу с заказчиком для уточнений.

😡Если требований нет:

1. Назначаем встречу с заказчиком.
2. Выясняем его ожидания, цели и текущие проблемы.
3. Фиксируем все подряд — иногда неожиданные комментарии становятся ключевыми.

Шаг 4. Доуточняем и согласовываем требования🔫

⭐️Решаем все нерешенные вопросы - лучше потратить время на уточнения сейчас, чем переписывать всё потом.

⭐️Разделите требования на функциональные и нефункциональные, чтобы было проще работать.

⭐️Согласуйте требования с бизнесом просим расписаться кровью.

В следующей части разберём, как выглядит итоговый документ, и что в нём обязательно должно быть.
А как вы начинаете вести проект? Делитесь своим опытом в комментариях! 🧐

IT АНАЛитика

vot blin😵
#поддержка

IT АНАЛитика

А я вам напоминаю!🍷

Вопрос на собеседовании:
— Какие курсы вы проходили?
— ДА

IT АНАЛитика

Так кто же виноват?🤔

Раскрываю, в чём была проблема:
На аккаунте оказалась неподтверждённая почта. В результате восстановить доступ через десктоп было невозможно — только через мобильное приложение.

Как можно было предотвратить это на разных этапах разработки?

1. Аналитик

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

2. UX/UI-дизайнер

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

3. Разработчик

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

4. Тестировщик

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

И вот вопрос: Чей был косяк? Делитесь своими версиями!

IT АНАЛитика

Аналитик в банке — это так, для души. На самом деле, я админ Telegram-канала. 😎

Но если серьёзно, это уже 100-й пост! Спасибо, что читали, репостили, комментировали и ставили реакции. 1000 подписчиков — это пока так, разогрев. Обнимаю каждого! ❤️

В следующем году планов много, так что stay tuned, как говорится.

От себя хочу пожелать:
🐈 Новый оффер, если вы в поиске.
💰 Больше зп, если оно вам нужно.
🤟Баланс между работой, которая приносит кайф, и жизнью, которая радует ещё больше. Но лучше вообще не работать.

С Наступающим! 🎄🎉

IT АНАЛитика

Врываемся в первую рабочую неделю! Два дня всего💬
#поддержка


IT АНАЛитика