Системные аналитики, дневники на стол 😏

С Днём знаний! Ольга Андреевна подготовила расписание на сентябрь 👩‍🏫

5 и 12 сентября — Вайбкодинг для аналитиков

На реальном Telegram-архиве научимся обрабатывать большие объёмы информации с помощью ИИ, соберём базу знаний и превратим её в сайт с поиском, навигацией и авторизацией

7 сентября — Архитектура систем. База

Разберём НФТ, архитектурные стили, декомпозицию, API, очереди, вебхуки и System Design. В итоге спроектируем собственную систему

28 сентября — Архитектура систем. Хард

Пойдём глубже в C4, архитектурные слои, антипаттерны, индексы, репликацию, шардирование, кэширование и NoSQL

А ещё скоро — «Собесы с ИИ»

Готовим воркшоп-челлендж по подготовке к собеседованиям с помощью искусственного интеллекта. Формат — игра на выбывание 😈

Дату и подробности объявим немного позже

Не хотите ждать определённой даты?

У нас есть "факультативы", которые можно начать в любое время: ИИ для аналитика, AI-агенты в Cursor, брокеры сообщений, базы данных и SQL, REST API, Postman, Swagger, UX/UI и другие программы

👉 Посмотреть всё обучение

На какой урок записываетесь? 😏

Почему нельзя просто увеличить timeout?

Однажды, прекрасным утром на проекте Х возникла следующая ситуация: один их сервисов стал отвечать 20 секунд. Заказчики предлагают:

Сейчас timeout 5 секунд. Давайте поставим 30 — и проблема исчезнет

Что должен проверить аналитик?

Кстати, в тему завтрашнего воркшопа и как ИИ разгружает рутину, не только рабочую, но и помогает в жизни!

Я планирую путешествие в Японию, и не могла не воспользоваться тем, что как раз будет на воркшопе: я выгрузила из тг-канала блогера места по японии, попросила сформировать локации (бары, шопинг, парки и т.д.) прям на гугл-карту

получилась просто супер крутая гид-карта

так что применять можно навыки с воркшопа не только в работе!

А вообще считаю, что я капец лайфхакер по путешествиям! Обращайтесь 😅

Реальная домашка ученика. Найдёте ошибку?

Наши эксперты проверяли домашку на курсе «Архитектура. База» и решили принести нам один реальный кейс. Задание было следующее: разбить образовательную платформу на DDD-поддомены и определить тип каждого поддомена. Фрагмент ответа представлен в фото

Задача
В этом ответе есть 2 технические ошибки по DDD. Попробуйте найти их в комментариях. Спойлер: ошибки не в названиях поддоменов, а в логике определения их типа.

Первые, кто найдёт обе ошибки и объяснит почему, наш почет и уважение ❤️
А для кого было трудно - ждем на курсе "Архитектура.База" уже в понедельник

Я не всегда делюсь на этом канале своим личным, но про визу в Великобританию не могла обойти стороной! 😅

Пишите рекомендации по UK в комментариях)

А если хотите больше видеть моей жизни, то велком на канал "Сегодня с Олей". Скоро полечу в Японию и Корею - буду делиться)

Когда анализа уже достаточно?

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

Команда читает и спорит

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

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

А вы до какой степени детализируете свое описание? Где для вас проходит граница между "хорошо проработал" и "переработал"?