Кэширование данных на фронтенде

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

Какую роль играет системный аналитик в проработке кэширования?
📌 Мы помогаем ответить на важные вопросы:
* Какие данные нужно кэшировать?
* Сколько времени данные остаются актуальными?
* Что делать, если кэш устарел?

Примеры данных, которые можно закэшировать:
* Значения справочников (страны, валюты, категории услуг).
* Информация о пользователе (если она редко меняется).
* Результаты фильтров, например, товары по заданным критериям.
* Настройки интерфейса (тема, язык).

Пример ТЗ:
Вызвать метод GET <uri> с параметрами <указываем параметры и откуда их брать>.
- Если в ответе пришел http-код = 200, то закэшировать ответ на 5 минут.
- Иначе отобразить ошибку в алерте с текстом из <указываем параметры>.

#frontend

Local Storage и Session Storage

В продолжение темы кэширования давайте поговорим о Local Storage и Session Storage — двух типах хранилищ данных на стороне клиента.

📌 Local Storage — это хранилище данных, которое сохраняет информацию на длительный срок, даже после закрытия браузера.
📌 Session Storage — данные хранятся только на время сессии браузера (до закрытия вкладки).

Пример_1:
Представьте, что вы на сайте онлайн-курса, и можете начать его проходить без регистрации. В какой-то момент вас просят ввести email, и без этого продолжить обучение невозможно.
❗️После регистрации вы ожидаете, что ваш прогресс не исчезнет, а будет перенесен на ваш аккаунт. И вот тут на помощь приходит Local Storage: он позволяет сохранить ваш прогресс в неавторизованной зоне. Когда вы авторизуетесь, данные о вашем прогрессе подтягиваются, сохраняются на сервере, и вам не придется проходить уроки заново.

Пример_2:
Представьте, что вы заполняете форму для записи на прием к врачу (вводите дату, выбираете врача, пишете причину обращения). Нажимаете на ссылку, чтобы посмотреть карточку врача, а затем возвращаетесь обратно на форму.
❗️Благодаря Session Storage все введенные вами данные сохраняются, и после возврата они подтягиваются, как будто вы не покидали страницу. Однако если вы закроете вкладку или браузер, данные исчезнут, и вам нужно будет снова заполнять форму.

#frontend

Кейс:
Представьте, что вы заказываете билеты на мероприятие через сайт. На первой странице вы выбираете количество билетов, дату и время мероприятия. На второй странице — выбираете места и т.д. Однако вы случайно закрыли вкладку до завершения оформления.

❓ Вопрос: где стоит хранить информацию о выбранных билетах: в Local Storage или Session Storage?

Кэширование данных: что, как и насколько?

Представим, что на странице вызываются методы:
* GET /countries — список стран.
* GET /user/profile — данные о текущем пользователе.

❗Почему стоит кэшировать ответы и насколько?

GET /countries
Это справочные данные, которые редко меняются. Их можно закэшировать в Local Storage на сутки или дольше, чтобы не запрашивать их каждый раз при загрузке страницы.

GET /user/profile
Это динамические данные, они меняются редко, но должны быть актуальными. Их можно кэшировать в Session Storage на одну сессию, чтобы уменьшить количество запросов, пока пользователь активен.

💡Конечно же, не стоит забывать об обновлении кэша. Да, мы закэшировали данные пользователя, но ведь пользователь может отредактировать свой профиль в приложении. В таком случае нужно настроить логику, чтобы при редактировании данные в кэше обновлялись.
💡А еще не забываем учитывать, что есть разные пути изменения данных:
* через мобильное приложение,
* веб-версию,
* напрямую в базе данных,
* через API,
и др.

Все эти факторы нужно учитывать и исходя из этого выбирать время жизни кэша.

#frontend

Любите ставить задачи для фронтендеров?
Рубрика: взгляд системного аналитика на процессы, кейсы, боли, холиварные темы

Привет! 👋
С вами Вера, основатель AnalystCore и автор этого канала.
Мне особенно нравится делиться с вами контентом про фронтенд.

В Т-Инвестиции я работала в команде чисто фронта и хорошо прокачалась в вопросах, какие боли есть у фронтендеров, чего им не хватает в ТЗ от системного аналитика.

Знали такое разделение на проекте? На проекте могут быть команды:
1️⃣ веба
2️⃣ ios
3️⃣ android
4️⃣ команды бэка на каждый сервис.
Подобное разделение я видела и в дальнейшем на многих крупных проектах.

В остальном, я была в классических командах, которые занимались и фронтом и бэком.

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

Хочу и вам привить эту любовь к фронту ❤️

#frontend #sa_dev

СА: «Дедлайн к утру? Уже готово, смотри!»
Заказчик: «А это кто согласовал?»

База — наше всё!

Часто начинающий системный аналитик работает 1-2 года, а потом переходит в другую компанию. А при переходе впадает в ступор.

Здесь все по-другому! Процессы другие, терминология другая, все непривычно. 😵‍💫

Или вы чувствуете себя неуверенно на текущей работе. Боитесь отклониться от примеров наставника, страшно сделать шаг влево, шаг вправо. Боитесь накосячить и опозориться перед коллегами. Знакомо? Это ощущение часто приходит от недостатка базы.

📌 База — это фундамент системного мышления аналитика. Как его развивать?

1️⃣ Насмотренность
Изучайте примеры работы других аналитиков, кейсы и подходы.
2️⃣ Алгоритмы
Учитесь не только их описывать, но и продумывать с нуля. Это помогает понимать логику работы систем.
3️⃣ Вопросы
Практикуйтесь задавать точные, полезные вопросы. Это навык, который превращает просто аналитика в профессионала.

У каждого свои пробелы в знаниях и опыте.
Вот что можно сделать:

💡Почитайте книги по навыку, который вы хотите подтянуть в ближайшее время. Например:
📚 «Writing Effective Use Cases», Алистер Коберн
📚 «Пользовательские истории. Искусство гибкой разработки ПО», Паттон Джефф
📚 «Не заставляйте меня думать. Веб-юзабилити и здравый смысл», Стив Круг
📚 «Микросервисы», Крис Ричардсон — актуально, если у вас на проекте микросервисная архитектура. Даже если вы новичок, вы поймете 20% книги, а это уже хорошо!
💡Заведите себе челлендж — изучать по 1 новому кейсу в день. Для этого подойдут статьи на Хабре.
💡Потратьте время на разбор процессов, которые вас окружают. Как они устроены (AS IS)? Как их можно улучшить (TO BE)?

Вы сможете преодолеть неуверенность, расширить кругозор и двигаться к большему. Главное — начните. У вас всё получится!

С вами Вера и Юрий,
основатели AnalystCore ❤️

Реальность перехода в новую компанию

Привет! 👋
С вами Вера.

После нового года многие задумываются о смене работы. А если это ваше 2-е или 3-е место, собеседования могут быть стрессовыми 😩. Как к ним подготовиться?

📌 Повторяйте базу и делайте себе шпаргалки.
Лично я перед собеседованиями всегда обращаюсь к своим заметкам, которые делала 3 года назад, 4, 5, 7 лет назад. Даже многое из того, что писала 5 лет назад, актуально до сих пор — не нужно искать всё заново, просто открываешь и освежаешь память. Это экономит время и нервы.

📌 Будьте готовы к тому, что на новом месте задачи могут быть совершенно другими.
На одном проекте вы просто описывали требования, а на другом нужно будет писать детальные ТЗ для фронтендеров и продумывать кэширование. Или, например, раньше вы проектировали логическую модель данных, а теперь будете делать физическую модель с учетом особенностей СУБД.

#sa_dev

🎁 Подарите обучение

Нет лучшего подарка, чем знания.
Отправьте другу долгожданную сову с зачислением на курс! 🦉✨

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

Сова уже готова доставить подарок! Напишите нам в ЛС 👉 @analystcoreteam, и мы сделаем всё в лучшем виде. 🎁

С вами Вера и Юрий,
основатели AnalystCore ❤️

Мой чеклист перед собеседованиями

Привет! 👋

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

Системного аналитика часто спрашивают на темы:

📌 Методы сбора требований
Какие знаете? Когда какой лучше использовать? Что вы использовали и почему?

📌 Работа с задачами
Как задача поступает к системному аналитику? Какой для вас идеальный процесс работы над задачей?

📌 Требования
Как пишете? Какие виды требований знаете? Что такое User Story и Use Case? Когда что использовать?

📌 Предметная область
Изучите сферу компании, к которой идете на собес. Если это интернет-магазин, то подумайте над сценариями: Что делать, если товара нет в наличии? Как работать с альтернативными сценариями при оформлении заказа? Если идете в банк, то подумайте о банковских процессах.

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

📌 Моделирование данных
На собеседованиях часто просят построить модель данных. Разобрать предметную область. Как правило, это логическая модель. Но отсюда вы выйдете на темы, как разбить связь М-М, какие типы данные выбрать? Какие ключи?

📌 Интеграции
Виды интеграций.
Про удаленный вызов процедур: REST vs SOAP — в чем разница? Какие преимущества и ограничения у каждого подхода? Примеры их применения из вашей практики. Принципы REST. Что такое идемпотентность? Как сделать метод POST идемпотентным? Про HTTP.

📌 Что есть кроме REST и SOAP
GraphQL, WebSockets, gRPC, паттерны вроде Webhooks и пр.

📌 Асинхронность/синхронность
Когда использовать синхронное, а когда асинхронное взаимодействие? Часто дают кейсы, а вам нужно выбрать способ взаимодействия.

📌 Архитектура
Микросервисы, монолитная архитектура, SOA и пр.

📌 Брокеры
Брокеры сообщений. Чем отличаются RabbitMQ и Kafka? В каких случаях какой инструмент лучше использовать? Спойлер: не просто выучите ответ, а правда постарайтесь понять, как работают эти брокеры.

📌 Безопасность
Авторизация, токены. Был ли опыт, что ходили к безопасникам? По каким вопросам?

📌 Базы данных
Реляционные и нереляционные БД. Что такое шардирование, хранимые процедуры, триггеры, вьюхи? Был ли на работе доступ к базе?

📌 SQL
Повторите базовые запросы. На собесах часто гоняют по SELECT, JOIN (проверяют, понимаете ли вы разницу между LEFT, RIGHT и тд). Повторите агрегатные функции, группировку, сортировку.

💡 Совет

Подготовьте свои практические примеры. Они на собеседованиях всегда играют на руку!

Вы справитесь, главное — уверенность и системный подход. 💪
У вас всё получится!

А если хотите закрыть пробелы в знаниях, у меня есть курс по базовым знаниям и навыкам СА. Переходите по ссылке 👉 Системный аналитик с нуля до старта

#sa_dev

Системному аналитику важны не только хард, но и софт скиллы 💡

Мы часто говорим о хард скиллах — уметь писать ТЗ, строить модели данных, разбираться в интеграциях и т.д. Но без софтов в этой профессии далеко не уехать. Ведь системный аналитик — это и про коммуникацию.

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

5 ключевых софтов, которые особенно важны:

1️⃣ Умение задавать вопросы
Казалось бы, простое умение. Но именно от точности вопросов зависит, насколько вы поймёте потребности заказчика и соберёте требования.

2️⃣ Навык доходить до истины
Часто информацию приходится собирать по крупицам, подключая коллег из разных отделов. Иногда нужно буквально «достать человека из-под земли», чтобы получить ответ.

3️⃣ Активное слушание
Важно не просто задавать вопросы, но и слышать, что вам говорят. Переспрашивайте, уточняйте. Это убережёт от множества ошибок.

4️⃣ Навык упрощать сложное
Аналитик должен объяснить разработчикам сложные бизнес-процессы и, наоборот, заказчику — технические детали простыми словами.

5️⃣ Способность работать с конфликтами
Бывает, что разные стороны хотят противоположного. Ваша задача — найти компромисс и договориться.

💡 Развивайте свои софт скиллы.

#softskills

Боитесь встреч с заказчиками? Вы не одни!

Начинающие аналитики часто боятся общаться с заказчиками и самостоятельно ходить на встречи.
Это нормально. Особенно в заказной разработки. Заказчикам многое не нравится и надо защищаться))) Чтобы научиться — следует развивать софт скиллы! На это уйдёт время, но с чего-то начать можно уже после праздников.🎄

Чтобы встречи проходили спокойнее:

1️⃣ Продумайте вопросы заранее
Что заказчик может спросить, глядя на ваши документы?
А что будет при нажатии сюда?
Откуда берутся эти данные?

2️⃣ Вы не обязаны знать всё
Вы не эксперт в их бизнесе. Пусть заказчик расскажет, как устроена их предметная область. Он наоборот будет рад показаться экспертом. Вам же останется только слушать и переформулировать услышанное своими словами, чтобы прояснить детали.

3️⃣ Вы только учитесь и это не стыдно
Вы не можете знать всего. Если кто-то пытается вас пристыдить за недостаток знаний, помните, что вы развиваетесь и с каждым проектом становитесь лучше.

#softskills