tgindex

Системный Аналитик

описание

Канал для системных аналитиков и не только: подборки полезных материалов на все случаи жизни. Реклама и сотрудничество @radale https://gosuslugi.ru/snet/67b0613c6411ff785396754a

← к каналу@sys_sa
19 091
подписчиков
Охват к подписчикам
58,5%
ERR
Реакции к просмотрам
0,36%
1 241 на 29 постов
Пересылки к просмотрам
1,62%
5 560
Постов в день
0,0
всего 30

Где отзываются чаще

доля реакций к просмотрам
  • 24 янв.без подписи1,29%
  • 28 дек. 2024 г.Жемчужины разработки. Чему мы научились за 50 лет создания ПО ✍️ Автор: Карл Вигерс 🗓 Год издания: 2024 🔤 Язык: русский 📚 Объём: 368 стр. Книга «Жемчужины разработки» от классика Карла Вигерса — это очень полезная для системных аналитиков, стремящихся улучшить свои навыки и избежать распространенных ошибок. Вигерс собрал 60 практических уроков, которые помогут научиться на чужом опыте и не наступать на грабли лишний раз. Ключевые темы книги охватывают шесть основных аспектов успешной разработки: 1. Требования 2. Дизайн 3. Управление проектами 4. Культура и командная работа 5. Качество 6. Улучшение процессов Для каждого из этих направлений автор предлагает: 🔘«Первые шаги», которые помогут вам проанализировать свой опыт 🔘Конкретные идеи и примеры, которые можно сразу же применить на практике Кроме того, Вигерс предлагает «следующие шаги» для внедрения полученных знаний в ваши проекты и команды. Эти уроки основаны на реальном опыте и не могут быть получены в учебных заведениях, что делает их особенно ценными. Если вы хотите развиваться и повышать эффективность своей работы, эта книга станет отличным помощником. Обзор книги на Хабре За книгу спасибо нашему подписчику, который пожелал остаться анонимным. #проектирование #требования0,66%
  • 14 июл.🔼 Server Driven UI (SDUI) Server Driven UI (SDUI) — архитектурный подход, при котором сервер определяет не только данные, но и структуру пользовательского интерфейса (какие компоненты, в каком порядке и с какими параметрами отрисовать на клиенте) 🍃В обычном приложении клиент «знает», как показать экран 🍃В SDUI клиент превращается в «движок рендеринга» — он просто отрисовывает то, что пришло с сервера в виде декларативного описания (обычно JSON) Подход также называют BDUI (Backend-Driven UI) ⭕️В традиционной (client-driven) модели сервер отдаёт только данные, а клиент решает, как их показать: Сервер ➡️ отправляет данные ({"price": 1990, "currency": "RUB"}) Клиент ➡️ знает, как отобразить эти данные на конкретной платформе 🟠В SDUI сервер отдаёт описание интерфейса: Сервер ➡️ отправляет компоненты и их свойства ({"type": "price_label", "props": {"text": "1 990 ₽"}}) Клиент ➡️ по описанию собирает экран из готовых нативных компонентов ❗️Ключевое отличие: логика «что и где показать» переезжает с клиента на сервер Как работает Система состоит из трёх частей: 1⃣ UI-кит (компонентная база) — набор реализованных на каждой платформе нативных компонентов (кнопка, карточка, баннер, список). Это «общий язык» между сервером и клиентом. 2⃣ Движок рендеринга — клиентский механизм, который по описанию из JSON собирает экран: находит нужный компонент в UI-ките и передаёт ему свойства. 3⃣ Контракт (директивы) — описание экрана, которое сервер отдаёт клиенту. Типовой поток 1. На сервере формируется описание экрана (какие компоненты, порядок, свойства, действия). 2. Клиент запрашивает конфигурацию и получает JSON 3. Движок рендеринга разбирает JSON, по type находит компоненты в реестре и отрисовывает их 4. Пользователь взаимодействует (например, нажимает кнопку) — клиент выполняет действие (action), пришедшее вместе с компонентом 5. Нужно поменять экран — правка конфигурации на сервере, при следующем открытии приложения пользователи видят новый UI без обновления из стора Принципы SDUI ⭕️ Начинать с экрана, а не с данных. API проектируется под то, что нужно показать, а не под структуру БД (demand-driven подход). ⭕️ Минимум логики на клиенте. Любой if/else про «что показать» — кандидат на переезд на сервер. Иначе логика дублируется на каждой платформе. ⭕️ Отдавать продуктную информацию, а не доменные данные. Вместо price: 1990 + currency сервер сразу отдаёт готовую строку "1 990 ₽". Форматирование, локализация, скругления — на сервере. ⭕️ Единая дизайн-система. Все клиенты используют общий UI-кит, тогда серверная инструкция «отрисуй primary-кнопку» даст одинаковый результат везде. ⭕️ Внедрять инкрементально. Не переписывать всё приложение сразу, а начать с одного экрана или компонента (например, баннера на главной). Плюсы и минусы ✅ мгновенные обновления UI — без релизов в сторах и ожидания обновления у пользователей ✅ кроссплатформенность из коробки — один JSON рендерится на iOS, Android, Web ✅ простой A/B-тестинг и персонализация — разный UI разным сегментам одним изменением на сервере ✅ единообразие платформ — все клиенты синхронны, расхождений почти нет ✅ снижение нагрузки на мобильную разработку — фронт не верстает каждый экран с нуля ➖ без интернета UI не загрузится; нужны кэширование и фолбэки, иначе пустые экраны ➖ сложность старта — нужен UI-кит, движок рендеринга и серверная часть под это ➖ двойная поддержка компонентов — компоненты живут и на клиенте (реализация), и на сервере (описание) ➖сложнее отладка — труднее понять, почему экран выглядит именно так (собрался динамически) ➖ риск «зашить» бизнес-логику в UI — границы между слоями легко размыть Где используется Когда много платформ, а интерфейс меняется часто и под разные сегменты пользователей: 🟠 Travel- и маркетплейс-платформы — быстрые итерации UI в разделах с динамическим контентом 🟠 соцсети и стриминговые сервисы — мгновенный rollout изменений и экспериментов 🟠 e-commerce и маркетплейсы — разные раскладки витрин для разных продавцов (например, блок «Бестселлеры» только для крупных магазинов) 🟠когда нужно обновлять интерфейс с сервера, не зависеть от сторов 📎 Материалы 1. Чем полезен Server Driven UI 2. Яндекс выпускает DivKit — фреймворк для server-driven UI с открытым кодом 3. Server Driven UI в Альфа-Банке 4. Server-Driven UI архитектура: server-driven vs content-driven 5. Как работает Server-Driven UI и зачем он фронтендеру #архитектура ➿➿➿➿➿➿➿➿➿➿ 🧑‍🎓 Более поробное сравнение в базе знаний по системному анализу0,51%
  • 22 мая 2024 г.✔️ Критерии приемки (Acceptance Criteria): краткий обзор Критерии приемки (Acceptance Criteria, AC) — это набор условий, которым должна удовлетворять пользовательская история (User Story), чтобы её считали выполненной. Критерии приёмки уникальны для каждой User Story (US) и являются основой для тестирования. ❓Для чего нужны 💩позволяют понять, выполнена ли US и работает ли, как ожидалось 💩определяют негативные сценарии и объясняют, как система должна реагировать на них 💩создают у клиента и команды разработки единое видение как должна быть реализована функциональность 💩помогают выявить проблемы на ранних этапах разработки Критерии приемки должны: ➖быть определены до того, как начнется разработка US ➖иметь четкие формулировки для проверки их выполнения: «принято» или «не принято». AC должны описывать конкретное поведение или результат, который ожидается от функции ➖иметь четкие формулировки для проверки их выполнения. ➖соответствовать ценности и цели пользователя и продукта ✔️ Подходы к составлению критериев приемки 1. Сценарно-ориентированный подход (Scenario-based acceptance criteria) 2. Свод правил или чек-лист (Rule-based acceptance criteria) 1️⃣ Сценарно-ориентированный подход Соответствует формату Дано/Когда/Тогда (Given/When/Then): 💩Given (Дано): чёткое описание контекста, состояние системы в начальный момент времени 💩When (Когда): действие, которое выполняет пользователь или система 💩Then (Тогда): ожидаемый результат Также можно дополнительно использовать: 💩Сценарий — название поведения, которое будет описано 💩И / ИЛИ — для продолжения любого из трех предыдущих утверждений Пример US: Как пользователь, я хочу иметь возможность восстановить пароль от своей учетной записи, чтобы если я забыл пароль, мог получить доступ к своей учетной записи. 💩Сценарий: Забыт пароль 💩Дано: пользователь переходит на страницу входа 💩Когда: пользователь выбирает опцию <забыл пароль> 💩И: вводит действительный адрес эл. почты для получения ссылки на восстановление пароля 💩Тогда: Система отправляет ссылку на указанный адрес электронной почты 2️⃣ Свод правил (чек-листы) Это простой список правил о том, как всё должно работать после реализации требования. Например: 1. Все кнопки должны иметь скругленные углы радиуса 10 2. Пользователь может выбирать способ авторизации с паролем или через получение OTP 3. В случае неправильного ввода пароля два раза подряд система отображает пользователю капчу AC 🆚 DoR 🆚 DoD 💩DoR (Definition of Ready) — это набор условий, которые должны быть выполнены, прежде чем командой может взять US в работу. Например, задача описана и декомпозирована, подготовлены CJ, HLD, прикреплены макеты дизайна, прописаны AC и т.д. 💩DoD (Definition of Done) — набор условий, которые должны быть выполнены, чтобы пользовательская история считалась завершенной. Например, реализация соответствует ТЗ, выполнены AC, пройдены все тест-кейсы, составлена документация, одобрения получены и т.д Главная разница 💩DoD & DoR одинаковые для всех US 💩AC уникальны для каждой US ⚒️ Использование Gherkin Gherkin — сценарно-ориентированный язык, который легко читается бизнесом и используется для описания функциональности программного обеспечения. Пример (картинка) Применяется для: ➖ Документирования пользовательских сценариев ➖ Написания автоматизированных тестов ⭐️ Подборки материалов по этой и другим темам доступны в базе знаний по системному анализу #требования0,47%
  • 28 мая 2024 г.✍️ Постановка задачи на разработку: этапы, отличие от ТЗ Понятия постановки задачи на разработку и техническое задание часто путают меду собой, но это разные вещи. 🔸Техническое задание — это документ, который определяет, что должно быть реализовано и как это должно работать (функциональные требования) и насколько это должно быть быстро/безопасно/отказоустойчиво/дружелюбно/отслеживаемо (нефункциональные требования). ТЗ возникает как результат обработки бизнес-требований, и их перевода на системный уровень. 🔹Постановка задачи на разработку — описание конкретных задач, которые должны быть выполнены разработчиками для реализации ТЗ. Когда постановка задачи должна быть представлена как отдельный артефакт Постановка задачи на разработку нужна всегда, но не всегда должна быть оформлена как отдельный артефакт. Иногда достаточно ТЗ, если оно содержит нужные детали для разработки. Случаи, когда необходимо описать постановку задачи отдельно: 💩Когда задача на доработку, а не на разработку с нуля. Есть одна большая спецификация на кусок функционала, и в это ТЗ дописываются требования по доработкам. ПЗ помогает выделить и описать конкретные изменения, которые нужно внести в существующую систему. 💩Когда задача составная и требует декомпозиции. В постановке можно разбить задачу на более простые подзадачи, тогда как ТЗ описывает реализацию функционала в целом без привязки на то, в рамках каких конкретных задач на разработку это будет реализовываться, сколько будет таких задач, кто их будет делать, какова оценка трудозатрат и т.д. Постановка задачи на разработку может содержать следующие пункты: 💩Введение, цель: Необходимо описать бизнес-контекст, почему задача возникла. Например, компания столкнулась с проблемой неэффективного учета заказов и хочет улучшить этот процесс. 💩Описание решения: способ и границы реализации (ТЗ, Use Case, статусные модели, макеты UX/UI, описание интеграций) 💩Ключевые источники информации: спецификации API, HLD, глоссарий, стандарты и т.д. 💩Диаграммы: например, UML sequence, activity, бизнес-процесс в BPMN, схемы данных 💩Заинтересованные стороны: перечень людей, влияющие на принятие решений 💩 Критерии приемки: критерии, по которым будет оцениваться успешное завершение проекта. 💩НФТ и ограничения решения: производительность, масштабируемость, доступность и т.д. 🆚 Отличие постановки задачи на разработку (ПЗ) от ТЗ 💩(утрируя) ТЗ — это текст в Confluence, ПЗ — описание в Jira 💩ТЗ описывает требования к функциональности в целом, а постановка направлена на реализацию функционала в рамках конкретных задач 💩Одно ТЗ может быть декомпозировано на несколько задач, при этом каждая может иметь свою постановку на разработку 💩Иногда в ТЗ уже содержится и постановка задачи, но лучше понятия не смешивать и всё равно прописывать постановку задачи отдельно ⭐️ Подборки материалов по этой и другим темам доступны в базе знаний по системному анализу #требования0,47%
  • 23 янв.🟢 Стратегии деплоя Деплой (deployment) / развертывание — процесс доставки новой версии приложения в продакшн и её ввода в эксплуатацию. Стратегия деплоя определяет - как именно новая версия попадает в прод, - какая часть пользователей её увидит - что произойдёт в случае ошибки 🔵 Big Bang / Replace/ Recreate Deployment (полная замена) Как работает 1. Старая версия приложения полностью останавливается 2. Обновляется код и конфигурации 3. Запуск новой версии Плюсы и минусы ➕ просто реализовать ➕ минимальные требования к инфраструктуре ➖ длительный простой ➖ изменения затрагивают пользователей полностью ➖ откат требует повторного деплоя старой версии Где применяется 🔹 внутренние системы, где простой допустим 🔹 низкокритичные сервисы 🔹 редкие релизы 🔹 на ранних этапах проекта / в условиях ограниченных ресурсов 🟢 Rolling Deployment (постепенное обновление) Как работает - новая версия разворачивается постепенно, по экземплярам (ноды, поды, контейнеры) приложения - балансировщик исключает обновляемые узлы из трафика - без полной остановки сервиса ➕ нет полного простоя ➕ не требует дублирования окружений ➖ старая и новая версии работают одновременно (получение неактуальных данных) ➖ требуется обратная совместимость ➖ откат происходит постепенно, занимает время Где применяется 🔹 микросервисная архитектура 🔹контейнеризированные приложения (Kubernetes, облачные платформы) 🔵 Blue-Green Deployment (Сине-зеленое развертывание) Используются идентичные production-окружения: - Blue — текущая версия - Green — новая версия Процесс деплоя: 1. Разворачивание новой версии в Green 2. Проверка работоспособности 3. Переключение всего трафика с Blue на Green 4. Среда Blue становится standby ➕ мгновенный откат. При обнаружении проблем после переключения трафик возвращается на Blue ➕ нет простоя. Релиз — перенаправление трафика ➕ чёткий контроль версии. Новую версию можно проверить в проде под реальной нагрузкой перед переключением ➖ удвоенные ресурсы ➖ сложность работы с БД , кэшами, файловыми хранилищами, чтобы обе версии могли работать с общим состоянием или его миграция была управляемой Где применяется 🔹критичные пользовательские системы 🔹сервисы с высокими SLA 🟢 Canary Release (канареечное развертывание) - новая версия выкатывается на небольшую часть пользователей - доля увеличивается поэтапно Применяется для высоконагруженных / критически важных приложений ➕ минимизация рисков ➕ раннее обнаружение проблем ➖ сложность настройки ➖ повышенные требования к наблюдаемости 🔵 Shadow Deployment (теневое развертывание) - новая версия развертывается параллельно со старой - пользовательские запросы дублируются и отправляются в новую версию, но ответы от новой версии игнорируются Применение Тестирование новой версии под реальной нагрузкой, но без риска для пользователей После анализа логов и метрик теневой версии выбирается одна из стратегий (Blue-Green, Canary) 👉 Feature Toggles (флаги) Это не стратегия деплоя, а техника, которая усиливает другие стратегии Новая функциональность «завернута» в оператор (флаг), который можно включать/выключать без деплоя (также только для группы пользователей) 👉 A/B-тестирование Цель — не безопасный деплой, а валидация бизнес-гипотез (какой вариант интерфейса дает большую конверсию) Часто это следующий шаг после успешного Canary-релиза, когда нужно принять решение оставить новую версию или откатить 📎 Материалы 1. Стратегии деплоя в Kubernetes 2. Стратегии развертывания (деплоя) и стратегии кэширования 3. 6 способов деплоя веб-приложений 4. Deploy (деплой) 5. Стратегии деплоя: как мы пришли к использованию Argo CD 📚 Книги 1. Грокаем Continuous Delivery - У. Кристи 2. Continuous delivery. Практика непрерывных апдейтов - Э.Вольф 3. Руководство по DevOps - Д. Ким, П. Дебус, Д.Уиллис, Д.Хамбл С.Д. #инфраструктура ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу0,46%
  • 6 авг.Что делать если все скиллы обесценятся через пару лет? Раньше аналитику хватало умения писать пользовательские сценарии и собирать шаблонное ТЗ. Сегодня простые задачи забирает ИИ, а требования к спецам растут каждый месяц Мы прошерстили рынок и выделили главный навык, который лишь растет в актуальности на фоне событий - АРХИТЕКТУРА. Но глубоко разбираться в ней хотят далеко не все А ведь именно эти знания дают: — Понимание, как устроены микросервисы, REST API и Kafka — Уверенность на технических собеседованиях и выход на архитектурный чек — Защиту от сбоев на проде из-за ошибок в логике — Быстрый рост от СА/БА до фуллстек и арх-уровня Приходи 13 августа в 19:00 (МСК) на бесплатный онлайн-практикум «Архитектура без кода: как стать аналитиком, которого слушают разработчики и бизнес» Разберем связку сервисов, базы данных и построение сценариев на чистом инженерном мышлении. Веб будет полезен джунам и мидлам в аналитике (СА, БА, дата- и фуллстек), а также QA, специалистам поддержки и разработчикам. Регистрируйся по ссылке Erid: 2SDnjeTZDxf Название: ООО "СТЕП БАЙ СТЕП" ИНН: 08000132170,45%
  • 25 июн.✏️ Принципы разработки KISS, Бритва Оккама, SSOT, DRY, YAGNI, SOLID Зачем нужны Инженерные принципы это не строгие правила, а ориентир Помогают: 🔸 уменьшать стоимость изменений 🔸 снижать количество ошибок 🔸 упрощать сопровождение 🔸 делать требования понятнее 🔸 избегать избыточных решений 💡 Для системного аналитика принципы служат фильтром при сборе требований, позволяют снизить затраты ещё до написания кода KISS (Keep It Simple, Stupid) Решение должно быть максимально простым Чем сложнее система, тем дороже изменения, тестирование и поддержка KISS не означает примитивные решения ✅ А отказ от ненужного усложнения Как применять СА 🔵не добавлять лишние сущности и процессы 🔵избегать универсальных решений без необходимости 🔵описывать требования максимально понятно 🔵сокращать количество исключений и специальных сценариев Пример ❌ Спроектировать универсальный механизм уведомлений с 15 каналами доставки, шаблонизацией и правилами маршрутизации ✔️ Сначала реализовать email и push-уведомления, если нужны бизнесу ❌ Описывать 15 вариантов исключений для одного процесса ✔️ Описать общее правило обработки ошибок (fallback), покрывающее 95 % случае Признаки нарушения KISS ▪️слишком много сущностей ▪️чрезмерная параметризация ▪️большое количество условий и исключений ▪️ сложность объяснения решения Бритва Оккама Не надо умножать сущности без необходимости Если два решения равнозначно покрывают требования, выбирается то, у которого меньше сущностей и допущений Отличие от KISS 🔸KISS говорит «делай просто» 🔸Бритва Оккама — «выбирай простое среди равных» Примеры для СА 🟠Есть проблема производительности. Необязательно сразу проектировать новый сервис или менять архитектуру. Возможно, достаточно оптимизировать запрос или индекс 🟠При выборе интеграции: если данные можно получить через REST-агрегацию, не стоит предлагать внедрение ESB или CDC только из соображений «это современно». SSOT (Single Source of Truth) Для каждой информации должен существовать один источник истины Если одинаковые данные существуют в нескольких местах, со временем они начинают расходиться Где применяется 🔵требования 🔵схемы данных 🔵справочники 🔵бизнес-правила 🔵интеграционные контракты Примеры в СА 🔵создавать единый глоссарий; в тексте требований использовать ссылки на термины, а не их определения 🔵справочные данные (списки валют, стран) выносить в общий раздел и ссылаться на него 🔵маппинг полей между системами хранить в едином файле (Swagger/OpenAPI или отдельной таблице), а не дублировать в сценариях ❌ Пример нарушения: правило «комиссия для клиентов из ЕС = 20 %» прописано в ТЗ, в UI-макете, в описании интеграции и в тест-кейсах. При изменении ставки до 22 % три источника не обновляются → баг на релизе DRY (Don’t Repeat Yourself) Не повторять знания, логику или описание без необходимости Дублирование приводит к изменениям во многих местах одновременно: 🟠одинаковые бизнес-правила 🟠повторяющиеся требования 🟠копирование схем данных 🟠одинаковая логика в нескольких процессах и тд Примеры для СА 🔸одинаковые структуры API вручную описываются в нескольких документах Лучше использовать единое описание и переиспользовать его 🔸в Use Cases применять include-сценарии для повторяющихся процедур (например, аутентификация описывается один раз) Когда дублирование допустимо Ради производительности (денормализация БД) или изоляции микросервисов (копирование DTO), но такое решение должно быть явно зафиксировано как исключение ❗️DRY не должен создавать избыточную сложность Отличие DRY от SSOT 🔸SSOT — про данные: одна сущность (справочник, атрибут, значение) хранится в одном месте. «где лежит истина?» (хранение) 🔸DRY — про логику: один алгоритм, правило или описание процесса не повторяется в разных местах. «где выполняется действие?» (поведение) YAGNI (You Aren’t Gonna Need It) Не создавать функциональность заранее Если функция не нужна сейчас — вероятно, её не нужно делать сейчас Примеры для СА 🔵 вместо проектирования 20 возможных статусов процесса «на будущее» лучше реализовать только реально используемые статусы. 🔵на этапе уточнения задавать вопрос: «Если не сделать это сейчас, сможет ли бизнес работать?» Если да — требование переносится в бэклог. ❌ Типичная ошибка: путать гибкость системы и проектирование гипотетических сценариев SOLID SOLID — набор принципов проектирования, направленных на создание изменяемых и поддерживаемых решений Интерпретация для СА 🔸SRP (Single Responsibility) Требование должно иметь одну причину для изменения. Не следует смешивать в одном разделе расчёт зарплаты и отправку уведомлений — их нужно разделять 🔸 OCP (Open/Closed) В требованиях новый сценарий должен дополнять, а не переписывать старый. Вместо «если тип A, то скидка 10 %» лучше описать механизм правил, где для типа A задаётся правило, а для типа B можно добавить новое правило 🔸 LSP (Liskov Substitution) Если в требованиях есть родительская роль («Клиент»), то её подтип («VIP-клиент») не должен нарушать предусловия системы (например, не требовать обязательный номер телефона, если у VIP его нет) 🔸 ISP (Interface Segregation) Лучше иметь несколько специализированных эндпоинтов, чем один универсальный с множеством обязательных полей 🔸 DIP (Dependency Inversion) Требования к модулям верхнего уровня не должны зависеть от деталей нижнего уровня. Вместо «сохранять в таблицу Oracle INSERT'ом» следует писать «система сохраняет данные» — абстрагироваться от реализации ❗️SOLID помогает управлять сложностью, но избыточное применение может привести к переусложнению 📎 Материалы 1. Принципы для разработки: KISS, DRY, YAGNI, BDUF, SOLID, APO и бритва Оккама 2. Принципы разработки в системном анализе 3. 5 принципов читаемого кода: KISS, YAGNI, DRY, BDUF и Бритва Оккама 4. SOLID, DRY, KISS, YAGNI и др. принципы разработки, пугающие новичка в IT #проектирование ➿➿➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу0,42%
  • 7 июл.📊 Сравнение Баз данных и Хранилищ данных ▫️База данных – оперативное хранилище, где содержится "текущее состояние" бизнес-процессов: активные заказы, остатки на складе, профили пользователей и тд ▫️ OLTP (Online Transaction Processing) — обработка транзакций онлайн, способ эксплуатации этой базы 💙Хранилище данных (DWH)— информационная система, в которой хранятся данные из разных источников. Используется для анализа, составления отчетов и интеграции данных транзакций. 💙OLAP (Online Analytical Processing) — способ доступа и анализа этих данных 🔹 Наши посты ▫️Основные понятия баз данных ▫️Нормальные формы баз данных ▫️Типы связей в БД. Нормализация ▫️Денормализация в БД ▫️Колоночные БД, Cassandra vs PostreSQL ▫️Требования ACID: Краткий обзор ▫️Масштабирование БД. Партиционирование, шардирование и репликация ▫️Требования ACID: Краткий обзор 💙Data Warehouse (DWH) 💙OLTP и OLAP #инфраструктура #бд ➿➿➿➿➿➿➿➿➿➿ 🧑‍🎓 Более поробное сравнение в базе знаний по системному анализу0,42%
  • 27 мая 2025 г.🙂 Docs as Code Docs as Code – подход к созданию и сопровождению документации. 🟢для работы с документами используются те же инструменты и процессы, что и для программного кода. 🟢текст пишут на языке разметки (Markdown, AsciiDoc), хранят в Git-репозитории и собирают с помощью генераторов сайтов (например, GitLab Pages, Docusaurus, Antora) 🟢публикуемая версия всегда синхронизирована с кодом и доступна потребителям 💡Идея: документация разрабатывается как код Ообращение с текстом документации, как с исходным кодом приложения: 💠хранится в системе контроля версий 💠проверка изменений через pull request’ы 💠автоматизированно собирать и публиковать и т.д. ❕ Документация может храниться как в одном репозитории с кодом, так и в отдельном Но всегда должна быть актуальной и согласованной с кодом (как и наоборот) Суть подхода Документация: 🔵хранится в репозитории Git 🔵пишется в IDE (VS Code или IDEA) с настроенными плагинами 🔵пишется на выбранном языке разметки, диаграммы описываются в формате кода (PlantUML, mermaid и др.) 🔵собирается при помощи генератора сайтов (например, Docusaurus) Принципы написания документации Написание спецификаций следует принципам написания кода, но имеет свои специфичные принципы 〰 Принципы из разработки 🟢DRY (Don’t Repeat Yourself) Не дублируем информацию: один факт — один источник, остальные ссылаются 🟢KISS (Keep It Simple, Stupid) Держим форму и язык простыми, без лишних деталей. 🟢YAGNI (You Aren’t Gonna Need It) Пишем только то, что нужно прямо сейчас; гипотезы и «на будущее» убираем 🟢SRP (Single Responsibility Principle) Один раздел — одна тема или функция 🟢SLAP (Single Level of Abstraction Principle) Уровни абстракции не смешиваем: обзор и детали храним раздельно 🟢LoD (Law of Demeter) Ссылаемся только на ближайший нужный контекст, избегаем дальних зависимостей 〰 Принципы, относящиеся к спецификациям 🟢читабельность — короткие абзацы, активные глаголы, минимум терминов 🟢единый стиль кодирования (структура текста, отступы, пробелы и т.д.) для облегчения понимания. Разрабатываются единые шаблоны документации и готовые блоки кода 🟢диаграммы как код — PlantUML, Mermaid, LikeC4: диаграммы генерируются из текста 🟢автоматизация пайплайна — CI проверяет орфографию, битые ссылки, формат 🟢отслеживание изменений, обновлений и исправлений в документах при помощи Changelog 🟢опубликованная версия документации является актуальной проду 🟢Merge Request, вливаемые в master, проходят ревью - без получения аппрува сделать mr нельзя 🟢Merge Request с изменениями в документации привязываются к задачам в Jira Хранение документации ✳️ Рядом с кодом Документация лежит в том же репозитории, что и сервис. Обычно в каталоге /docs. Каждая ветка и тег кода несут свою версию текстов. ➡️ пример: GitLab хранит руководство пользователя в том же репозитории, чтобы изменения в продукте и тексте шли синхронно. ✳️ В отдельном репозитории Документация развивается в своём проекте (или нескольких), независимом от исходников сервисов Когда подходит: 🔵 доков много, обслуживают сразу несколько продуктов 🔵 требуется выпускать или править тексты без привязки к релизам кода 📎 Материалы 1. Docs as Code: введение в предмет 2. Опыт аналитиков Альфы про доку в коде 3. Docs as Code: как вести фронтовую документацию рядом с кодом, чтобы репозиторий не раздуло — опыт Альфы 4. Documentation as code: практики и инструменты документирования в сфере финансовых технологий 5. Статья о Docs as code от техписов - сайт собран как код на Rst 6. Инструменты подхода Docs-as-code #инфраструктура #документация ➿➿➿➿➿➿➿➿ 🧑‍🎓 Глубже по теме Docs as Code смотрите в Базе знаний по системному анализу : ⏺преимущества и недостатки Docs as Code ⏺сравнение с Confluence и другими подходами ⏺как понять, что Docs as Code действительно работает ⏺обзор инструментов ⏺пошаговое руководство, как внедрить Docs as Code ⏺как выбрать подход к документации А ещё там 140+ статей и 2500+ ссылок на материалы -- и всё разложено по полочкам, как мы любим.0,40%
  • 24 июл. 2024 г.Формализация требований на практике ✍️ Авторы: В. В. Кулямин, Н. В. Пакулин, О. Л. Петренко, А. А. Сортов, А. В. Хорошилов 🗓 Год издания: 2006 🔤 Язык: русский 📚 Объём: 69 стр. Подробное руководство по методам обеспечения адекватного понимания потребностей пользователей и их отражения в формальных моделях. Авторы рассматривают ключевые аспекты работы с требованиями и предлагают эффективные методы их формализации. О чём книга ✔️ Улучшение процесса сбора требований: Методы и техники для точного выявления и описания задач, которые должно решать программное обеспечение. Книга поможет лучше понимать потребности пользователей и формализовать их. 🚫 Анализ и сравнение методов работы с требованиями: Обзор и сравнение различных подходов, таких как RUP, DOORS, CORE, SSM, RAISE. 📐 Формальные модели: Примеры использования формальных моделей для представления требований и методов их решения. ✏️ Как использовать формальные модели для улучшения взаимодействия между командами разработчиков и заказчиками. 📝 Процесс формализации требований FOREST: Детальное описание процесса формализации требований, включая этапы и техники. #требования0,38%
  • 6 апр. 2025 г.⏯ Подборка новых тестовых собеседований системных аналитиков 1. Мок-интервью Бизнес Системного Аналитика на уровень Senior 2. Тестовое собеседование на позицию сеньора аналитика. Решение задач 3. Топ-10 вопросов по Системному анализу / Собеседование с разбором ответов и материалами 4. Техническое собеседование системного аналитика 5. Тестовое собеседование на позицию Middle аналитика 6. Моковое собеседование на Middle системного аналитика | Solvery & На собесе как на танцполе 7. Тестовое собеседование на младшего системного аналитика P.S. по ссылкам выше видео с ютуба Бонус: 1. Топ-100 вопросов на собеседовании по системному анализу 2. 120 вопросов #собеседования0,38%