Пример хард-скила: умение проектировать БД.

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

Для меня скил проектирования БД ассоциируется со строительством дома 🏡

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

ЭТО ВСË ПОВЛИЯЕТ НА ФУНДАМЕНТ. И ЕСЛИ НЕ СОБРАТЬ ДАННЫЕ ПРАВИЛЬНО ИЛИ ЧТО-ТО НЕ УЧЕСТЬ, ТО ДОМ РУХНЕТ ПРИ ПЕРВОМ ЖЕ УРАГАНЕ.

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

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

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

Базы данных - основа основ в системах. Даже дизайн REST API на их основе строится

Продуктивного просмотра 😉
Связь базы данных и дизайна REST API

Как понимать разработчиков всегда? 😀

В этом посте я расскажу несколько причин, почему знание БД так помогло мне в карьере системного аналитика.

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

✔️ Оценка выполнимости требований
Системные аналитики, знакомые с БД, могут оценить, насколько реалистичны требования и могут предложить более эффективное решение для реализации требований.

✔️ Понимание связей между данными
Это позволяет лучше понимать, какие данные нужны для выполнения определенных задач, и как их можно использовать для улучшения процессов в компании.


✔️ Оптимизация производительности
Зная, как данные хранятся и как работает база данных, системные аналитики могут оптимизировать процессы, связанные с чтением и записью данных, улучшить производительность и уменьшить нагрузку на систему.


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

Есть три уровня моделей БД:
1. Концептуальный
2. Логический
3. Физический

Каждый из них имеет свое назначение, и создается на определенных стадиях работы над проектом.

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

Давайте поделюсь с вами фишками по проектированию моделей БД, которые использую в своей работе 😉

Но перед этим небольшой опрос ✔️

🎓 Концептуальная модель базы данных 🎓

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

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

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

Давайте без воды и сразу пример 💦

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

Что будет в концептуальной модели?

Список сущностей:
▫️Камера
▫️Сотрудник
▫️Гость
▫️Зона
▫️Факт присутствия - запись в журнале или отчете

Связи:
🔵 Одна камера может зарегистрировать несколько сотрудников или гостей
🔵 Камера устанавливается в определенной зоне офиса
🔵 Факт присутствия включает информацию о зоне съемки, камере и сотруднике / госте


И что, всё? 😂 Нет. Не все. У меня начинаются вопросы:
1. А система видеонаблбдения будет разработана только под один офис или под несколько? Нужна ли сущность "Офис"?
2. Может ли быть на одной зоне несколько камер?
...

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

Если быть честной, то я всегда пропускаю концептуальный уровень и сразу строю модель БД на логическом уровне. Но без понимания того, как строить концептуальную модель, я бы не смогла это сделать.

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


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

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


Системные аналитики должны понимать, как изменения в функциональности меняют БД и влияют на всю систему. Как их можно сделать их наиболее безболезненно и ничего не упустить из виду.

Знаете, есть такая боль, когда тебе кажется, что задача простая, а разработчик говорит, что там работы на 100500 часов? Именно при осознании сколько связанных сущностей мы затронем, мы сможем понять, почему разработчик считает задачу сложной и все его объснения на "птичьем" языке 😀 В этом нам поможет концептуальная модель БД.

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

Когда-то я не догадывалась, что путешествия это настолько круто!

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

Конечно, в поездках не раз представляла себе, как было бы круто работать на берегу океана, с хорошим интернетом и вкусным коктейлем из кокоса🏖
Думаю, у многих такая картинка сразу всплывает в голове😄

Спустя время так случилось!🤘
До сих пор помню, как в первый раз отчётливо осознала, как это круто работать на удалёнке — иметь возможность каждый раз при желании находиться в неожиданных и классных местах.

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

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

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

Если посмотреть глобально, то понимаю — мои увлечения и есть моя работа ❤️
А работа с шикарным видом из окна теперь для меня не мечта, а реальность.

Поделитесь, а о чём вы мечтаете в карьере?

Good morning! 🚀

Расскажу вам сегодня о статистике по востребованности hard-skill "Проектирование БД" (database design).


✔️ 67% системных аналитиков работают с задачами на проектирование БД ✔️

Это значит, что навык действительно нужен.
Устраиваясь в компании коллег, с вас как минимум спросят понимание логической модели БД. Хорошо, если попросят написать простой SQL-запрос на собеседовании. Иногда просят и сложные.

Системные и бизнес-аналитики работают с данными. Тренд идет в сторону того, чтобы специалисты понимали техническую сторону систем глубоко.

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

А еще, при добавлении нового поля надо предусмотреть обратную совместимость и описать процесс обновления схемы БД - миграцию, чтобы в процессе релиза система не сломалась, пока вся функциональность целиком не включилась...

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



✔️ 17% системных аналитиков работают с БД, но НЕ проектируют ее

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

За проектирование БД в таких компаниях отвечают разработчики.

На собеседованиях системного аналитика могут спросить знание инструментов для подключения к БД и о работе с SQL-запросами. Например, есть очень популярный инструмент DBeaver. Я так же использовала для этого phpStorm, pgAdmin, SQLite и другие, в зависимости от БД.



✔️ 16% системных аналитиков не работают с БД

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

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



Что делать, если пока не работали с БД? С чего начать?
▫️Почитайте про концептуальную, логическую и физичесую модели БД
▫️Скачайте DBeaver
▫️Возьмите тестовую БД
▫️Посмотрите ее в виде ER-диаграммы
▫️Поищите простые SQL-запросы в интернете
▫️Попробуйте сделать несколько простых SQL-запросов к БД через DBeaver
А дальше можно придумывать себе задания и практиковаться.

Всё получится 🙌

Логическая модель базы данных - это план по созданию БД, который показывает:

🔵 какие таблицы нужно создать,
🔵 какие поля в этих таблицах будут,
🔵 как они будут связаны между собой.

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

Список сущностей из концептуальной модели дополняем полями, то есть свойствами сущностей:

▫️Камера
- Номер
- Место установки
- Дата создания
- Описание (модель и пр.)

▫️Сотрудник
- Табельный номер
- Фамилия
- Имя
- Отчество
- Телефон
- Должность
- Фото
- Информция о биометрии для считывания лица с камеры
- ...

▫️Гость
- ФИО
- Дата регистрации
- Период допуска - время старта
- Период допуска - время окончания
- Телефон
- Информция о биометрии для считывания лица с камеры
- ...

▫️Зона
- Номер
- Описание

▫️Факт присутствия - запись в журнале или отчете
- Камера
- Зона
- Гость / Сотрудник
- Время регистрации

Связи, необходимые для логической модели, уже есть.

Дополнительно на логическом уровне:
+ добавлю id в каждую таблицу - первичные ключи (PK - primary key),
+ добавлю внешние ключи (FK - foreign key), чтобы организовать связи - переименую в факте присутсвия "Камера" на "Камера_id" и остальное по аналогии,
+ уберу избыточные связи - например, зону из "Факта присутствия"



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

Привет всем!

Сегодня, 23 февраля, я хочу поздравить системных аналитиков и всех, кто работает в ИТ-индустрии, с Днем защитника Отечества!

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

Спасибо за вашу трудолюбивую работу и за то, что вы делаете нашу жизнь более удобной и безопасной ❤️

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

С праздником, друзья!

Я тут про ChatGPT начинала историю, хочу продолжить.

Сейчас много работаю с задачами на интеграции, описываю Use Case и алгоритмы обработки данных по разным проектам. А еще веду обучение, где работаем с требованиями, BPMN-диаграммами. Мне помогает работать ChatGPT.

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

Сегодня, на вебинаре группы по Интеграциям для разбора ДЗ, я просто взяла и начала показывать, как пользоваться ChatGPT для работы на нашем курсе, для моего проекта, и как результаты из него могут СОХРАНИТЬ ЧАСЫ ЖИЗНИ!

Я всегда даю самые новые и продвинутые знания и лайфхаки, которыми не стоит пренебрегать!
Искусственный интеллект - помощник аналитика! Пользуйтесь!
Даже картинка для этого поста создана при поддержке искусственного интеллекта 🤖

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

Собираем 111 🔥 под этой записью, и договариваемся с вами об удобом времени эфира
#chatgpt_getanalyst

Какие перспективы в IT у аналитиков?

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

Такая ситуация может быть маркером, что пора прокачивать очередной скилл.
Навыки по проектированию БД и знания в SQL сейчас нужны практически в любой компании, особенно — в крупных и развивающихся, где собирается много данных.

Кадровое агентство Алексея Сухорукова регулярно проводит исследования в сфере вакансий IT-сектора. Речь идет о результатах большой выборки и относятся к аудитории России. Она показывает, как растёт средний уровень зарплат аналитиков специализирующихся по проектированию БД, и как увеличивается спрос на них. Такая тенденция прокачивает перспективы развития в карьере.

В буквальном смысле, компании не то что, ищут технически грамотных и глубоко понимающих внутренности систем аналитиков, они охотятся за ними!

Я также провела своё независимое исследование и посмотрела, что сейчас запрашивают работодатели от соискателей у системных аналитиков.

В вакансиях встречаются следующие требования:
✔️ понимание основ реляционной БД,
✔️ умение проектировать БД,
✔️ знание простых запросов на SQL.

Вот некоторые из них:
Системный аналитик, БУРГЕР КИНГ РОССИЯ
Бизнес/системный аналитик, ТОО KAP Technology Казахстан
Системный аналитик, Сбербанк Россия
Ведущий системный аналитик, HR Prime Россия

Если брать статистику по США, то здесь это начало развиваться ещё раньше и данные по востребованности этого навыка выше, что соответственно и отражается на доходе специалистов.

Знания по работе с физической моделью баз данных и СУБД могут значительно увеличить зарплату системного аналитика. По данным сайта Indeed, в США заработная плата начинается от 85 000$ в год, но может достигать более 150 000$ в год для специалистов, которые знают, как эффективно работать с физической моделью баз данных.

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

«Базы данных невероятно важны для любой компании. Когда компания понимает это, они обычно ищут кого-то, кто является экспертом в области управления базами данных и обработки. Экспертов по базам данных намного меньше, чем разработчиков, и меньше, чем вакантных рабочих мест для них. Людей с таким набором знаний и навыков не так много, это делает их более ценными в глазах работодателя. Следовательно, им проще найти работу».

Без этих знаний будет со временем сложнее. Если честно, не знаю как без них вообще можно будет работать.
Я всегда за то, чтобы адаптироваться на рынке заранее и понимать куда направлять вектор.
Надеюсь, вы как и я, выберете действовать и покорять рынок IT, а не наблюдать за всем со стороны.

Физическая модель реляционной базы данных - это почти реальная схема базы данных. Остается только напистаь SQL-запросы по ее созданию и готово 🙂

Что показывает физическая модель базы данных:
🔵 таблицы с наименованиями, которые фактически будут БД,
🔵 поля с наименованиями, которые фактически будут БД,
🔵 типы данных и ограничения для полей,
🔵 первичные и внешние ключи,
🔵 обязательность для полей,
🔵 уникальность для полей,
🔵 связи между таблицами и за счет каких полей они реализуются.

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

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

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

В логической модели у нас была таблица:

▫️Камера
- Номер
- Место установки
- Дата создания
- Описание (модель и пр.)


Для физической модели этой же таблицы:

▫️Camera
- id (UUID, Not Null, Unique)
- number (integer, Not Null, Unique)
- zone_id (UUID, Not Null)
- created (timestamp, Not Null)
- description (varchar(256))


Это маленький шаг в переходе от логической к физической модели. Нужно еще связанные таблицы сделать. И посмотреть, насколько БД соответствует всей той функциональности, которую мы хотим поддержать. И это безумно интересно! Я обожаю техническое проектирование. Это одна из любимейших частей работы ❤️

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

Практический кейс - про банковскую систему и SQL-запросы

В банке обслуживаются клиенты.
Каждый клиент может открыть в банке несколько счетов.
Со счетов клиент банка может делать переводы, оплачивать покупки, может пополнять счет .

Есть банковская система. В ней есть база данных. Как определяю сущности? Внимательно вычитываю текст и ищу сущности - объекты, у которых есть свойства.

Простой пример: пирог
Свойства пирога: тип начинки (фруктовый/овощной), форма (квадрат, прямоугольник или круг), размер

В банковском примере:
В банке (уточнить, 1 или много банков в системе) обслуживаются клиенты.
Каждый клиент может открыть в банке несколько счетов.
Со счетов клиент банка может делать переводы, оплачивать покупки, может пополнять счет (это все виды его транзакций).

Создаем по получившемуся описанию три таблицы в логической модели данных (ER-диаграмма). Наполняем свойствами, исходя из опыта. Связываем их между собой по уникальным идентификаторам (ID).

Получилась какая-то модель 😀 "Это зачем вообще?" - спросила бы я когда-то.
Но это первый шаг, на пути к пониманию птичьего языка разработчиков. Один из их языков - SQL.

Давайте посмотрим как действуют разработчики, решая наши задачи.
Они говорят на языке SQL с данными, которые хранятся под капотом в программе.

Нужна форма просмотра списка клиентов в программе. Отобразить надо ID, ФИО клиента и номер телефона.

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

Разработчик, чтобы показать данные пользователям, пишет обращение к БД:.

🔵 SELECT
ID, ФИО, Телефон
FROM
Клиент;

или

🔵 SELECT
ID AS `ID клиента`,
ФИО AS `ФИО клиента`,
Номер телефона AS `Номер телефона клиента`
FROM
Клиент

Пояснение:
▫️SELECT- ключевое слово, означает "Выбрать"
▫️FROM - ключевое слово, означает "Из"
▫️AS - ключевое слово, означает "Как"

Форма запроса:
SELECT ..... FROM .....
ВЫБРАТЬ (параметры) ИЗ (таблиц)

AS используем для переименования колонок в результате. Если будем дествовать без AS, как в первом запросе, то в ответ вернется таблица, как на картинке, без лишних колонок. А если с AS, то названия нужных нам колонок поменяются.

Кажется, что ничего сложного нет.
Давайте теперь вы попробуете написать пару SQL-запросов.
1. Нужна форма просмотра списка счетов в программе. Отобразить надо ID счета, номер счета и дату открытия. Переименовывать столбцы не надо.
2. Нужна форма просмотра списка транзакций в программе. Отобразить надо ID транзакции, ID счета, Сумма транзакции и Дата транзакции. Переименовать первые две колонки в "Идентификатор Транзакции" и "Идентификатор счета".

Ответы в комментарии! 👇

А теперь давайте напишем SQL-запрос на получение списка счетов клиентов, чтобы в ответе были:

▫️номер счета,
▫️ФИО клиента,
▫️баланс счета,
▫️тип счета,
▫️дата открытия счета,
▫️дата закрытия счета.


SQL-запрос на получение списка счетов клиентов с необходимыми полями:

SELECT
Счет.Номер_счета AS Номер счета,
Клиент.ФИО AS ФИО клиента,
Счет.Баланс AS Баланс счета,
Счет.Тип AS Тип счета,
Счет.Дата_открытия AS Дата открытия счета,
Счет.Дата_закрытия AS Дата закрытия счета
FROM
Счет
INNER JOIN Клиент ON Счет.ID_клиента = Клиент.ID;

Пояснение:
• SELECT - выбираем поля, которые нам нужны.
• Счет.Номер_счета - номер счета из таблицы Счет.
• Клиент.ФИО - ФИО клиента из таблицы Клиент.
• Счет.Баланс - баланс счета из таблицы Счет.
• Счет.Тип - тип счета из таблицы Счет.
• Счет.Дата_открытия - дата открытия счета из таблицы Счет.
• Счет.Дата_закрытия - дата закрытия счета из таблицы Счет.
• FROM - указываем таблицы, из которых берем данные.
• INNER JOIN Клиент ON Счет.ID_клиента = Клиент.ID - объединяем таблицы Счет и Клиент по полю ID_клиента из таблицы Счет и полю ID из таблицы Клиент.

В INNER JOIN важен порядок, так как определяет порядок объединения таблиц и влияет на то, какие данные будут использованы при объединении.

В приведенном запросе INNER JOIN Клиент ON Счет.ID_клиента = Клиент.ID сначала выбираются данные из таблицы Счет, а затем объединяются с таблицей Клиент по условию равенства ID_клиента из таблицы Счет и ID из таблицы Клиент.

Если бы порядок был изменен на INNER JOIN Счет ON Клиент.ID = Счет.ID_клиента, то сначала выбирались бы данные из таблицы Клиент, а затем объединялись с таблицей Счет.

Оба запроса могут вернуть одинаковый результат, но порядок в INNER JOIN может быть важен, когда в запросе есть операторы WHERE, GROUP BY и др.


А теперь вы 😉

Напишите SQL-запрос который возвращает список всех транзакций в составе параметров: ID транзакции, номера счета, идентификаторов клиента, тип транзакции, сумма, дата

Ответы в комментарии 👇

Привет-привет!

Всем продуктивного понедельника! Я для вас готовлю на этой неделе как минимум один практический вебинар. А как только наберется еще несколько огонечков на этот пост, то и прямой эфир появится про лайфхаки с ChatGPT в работе аналитиков 🙂

Мне кажется, что моя любовь к системному анализу бесконечна ❤️ Вы не представляете с каким восторгом я погружаюсь в новые проекты, новые предметные области, алгоритмы. Иногда с 10 утра до 2 часов ночи сижу, потому что затягивает! (P.S. в середине дня обязательно гуляю и делаю перерывы)

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

Я постоянно ищу новые крутые фишки для вас! И стараюсь дать все самое-самое через практику, чтобы не только я рассказывала как, но и вы сразу пробовали применять теорию на практике😉