Шпаргалка по выбору правильной СУБД в продолжение к посту про типы нереляционных БД.

Источник

#бд

От монолита к микросервисам. Эволюционные шаблоны для трансформации монолитной системы

✍️ Автор: Сэм Ньюмен
📅 Год: 2021
🔤 Язык: русский

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

Обзор книги

#архитектура #микросервисы #проектирование

🎙 Бесплатные подкасты из Радио "Аналитик"

Скачать любой из подкастов или весь сборник целиком можно по ссылке (Яндекс Диск).

Список подкастов

1. О развитии навыков ИТ-аналитика с Александром Чавалах

2. О работе с изменениями с Алёной Ивахновой

3. О необходимых для аналитика hard skills с Дмитрием Летяго

4. О работе с задачами по адаптации типового решения под требования заказчика с Татьяной Рыловниковой

5. Об основах работы с данными с Владимиром Ловцовым

6. О мышлении и коммуникативных навыках с Гюльнарой Антроповой

7. Об управлении обеспечением предприятий с Дмитрием Кучмой

8. Об обратной связи и её месте в развитии аналитика с Артёмом Пластининым

9. О ванильном мороженом и обучении аналитиков 1С с Анастасией Штей

10. О консалтинге в сфере 1С с Алексеем Бояршиновым

11. О создании продуктов с Сергеем Колосковым

12. О командной работе и построении эффективных коммуникаций с Маргаритой Маковеевой

13. О книге Карла Вигерса "Разработка требований к программному обеспечению" с Александром Байкиным

14. О когнитивных искажениях, сервисе UX CORE и проекте KeepSimple c Вольфом Алексаняном

15. О текстах в интерфейсах с Александром Марфициным

16. Об ожиданиях предпринимателей от автоматизации с Артёмом Вахрушевым

17. Об ожиданиях от автоматизации в сферах foodtech и e-com с Павлом Вепревым

18. О мифах, которые рождаются вокруг продуктов с Алексеем Чернышовым

19. О возможностях 1С для создания полезных отчетов с Матвеем Серёгиным

20. Про первый опыт публичного выступления с Ольгой Зубковой

21. Про путь от первого выступления до первого места в топе лучших докладов с Павлом Громовым

22. Про ожидания и реальность офлайн выступлений с Дмитрием Макаровым

23. О планировании с Владимиром Завертайловым и Екатериной Мамонтовой

24. Про интеграции с Артуром Белопольских

25. О пробелах в знаниях, недостающем опыте и новых вызовах для аналитиков из сферы 1С с Еленой Ивановой

26. Про решение проблем с Анастасией Московкиной

27. Про фасилитацию и фасилитирующее лидерство в ИТ с Алексеем Таченковым

#подборка

📝 Задачи для системных аналитиков из конкурса IT_One Cup 2022 с решениями

По ссылкам ниже можно собственноручно прорешать задания и загрузить решение — проверка автоматическая. Требуется зарегистрировать аккаунт на all cups.

Ознакомительный раунд.
1. Задача А (Камни) — решение
2. Задача B (Почта) — решение

Квалификационный раунд
1. Задача А (Авария)
2. Задача B (Кредиты)
3. Задача C (Интеграция)

Заключительный раунд: ссылка на задачу и решение от победителя конкурса прикрепляем (.pdf)

➕ Ещё соревнования:
1. IT’s Tinkoff Solution Cup (с решениями)
2. Sovcombank Challenge 2021 (Системный анализ)

Если вы знаете, какие ещё весёлые конкурсы есть для системных аналитиков, пожалуйста, напишите в комментариях ⬇️

#развитие

Agile и Waterfall: главное о методологиях разработки ПО

Разделение всех методологий на Agile и Waterfall — это общепринятый способ классифицировать подходы к организации процесса разработки ПО.

🌊 Waterfall (водопадная/каскадная модель) — это классическая методология, при которой проект делится на последовательные этапы, которые выполняются один за другим. Переход к следующему этапу возможен только после завершения предыдущего. Клиент видит результат только в конце проекта.

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

✅ Преимущества Waterfall

1. Фиксированный бюджет и сроки, так как всё фиксируется на этапе составления ТЗ

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

❌ Недостатки Waterfall

1. Отсутствие гибкости. В проект нельзя вносить изменения. Если на каком-то из этапов возникнут проблемы, изменятся требования или станет ясно, что что-то не учли, придётся начинать сначала.

2. Риски. Если на каком-то этапе возникнут ошибки или недочеты, они могут быть обнаружены только в конце проекта, когда будет поздно

3. Отсутствие обратной связи. Меньше обратной связи – меньше уверенности, что мы делаем то, что действительно нужно

Где можно применять водопадную модель

● Несложные проекты, где объём работ можно легко определить и сформулировать в ТЗ.
● Проекты с очень строгими требованиями к бюджетам и срокам.

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


🔁 Agile — это семейство гибких методологий управления проектами.

Вся суть Agile содержится в четырёх пунктах его манифеста:

1️⃣ Люди и их взаимодействие важнее процессов и инструментов проектного управления.
2️⃣ Рабочее программное обеспечение (результат проекта) важнее всеобъемлющей документации.
3️⃣ Сотрудничество с клиентами важнее переговоров по контракту.
4️⃣ Реагирование на изменения важнее следования плану.

К Agile относят Scrum, Kanban, Lean, XP, FDD, TDD, SoS, LeSS, SAFe, AgilePM.

В Agile проект делится на небольшие итерации или спринты (примерно 2 недели). Каждая итерация имеет какой-либо результат – готовую функциональность. Клиент участвует в процессе разработки и может давать свою обратную связь по каждой итерации. Продукт постоянно улучшается и адаптируется к изменяющимся требованиям.

✅ Преимущества Agile

1. Гибкость к изменениям и скорость. Например, если конкуренты выпустили новую функцию, её можно быстро разработать в уже начатом проекте.

2. Риски ниже — прямо в процессе команда получает обратную связь от пользователей. А если какая-то итерация растянется, следующую можно будет адаптировать под изменившиеся сроки и условия.

3. Ориентация на людей и команду даёт большую вовлечённость в проект.

❌ Недостатки Agile

1. Сложность внедрения. Его нужно уметь использовать. С умом. К тому же, люди часто привыкают к текущему способу работы и не всегда приветствуют изменения

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

3. Заспамленность созвонами. Вытекает из первого пункта в случае ошибок при внедрении. Однако забитый бессмысленными встречами календарь – это бич не только аджайла. Проблема шире, чем просто подход к разработке ПО.

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

📎 Материалы
1. Битва титанов: Waterfall VS Agile
2. Agile и «водопад». Сравнение подходов
3. Управление проектом по Agile методике
4. Об оценках сроков в разработке ПО
5. Гибридное управление проектами: как смешать модный Agile с традиционным проектным менеджментом

О минусах Agile
1. Scrum ужасен
2. Обратная сторона Agile
3. Как правильно имитировать Agile?

#управление_проектами

Инженерия требований

✍️ Авторы: Халл Элизабет, Джексон Кен, Дик Джереми
📅 Год: 2005
🔤 Язык: русский
📚 Объём: 240 стр.

Авторы подробно объясняют роль системной инженерии в решении разного рода задач по созданию систем. Вот главные моменты:

▪️ внимание к разъяснению важности системной инженерии для эффективного решения проблем создания систем
▪️ описание основных представлений, используемых при моделировании систем, включающее краткое описание языка UML
▪️ анализ взаимосвязи между требованиями и моделированием
▪️ описание многоуровневого процесса инженерии требований, включая особенности этого процесса в области проблем и решений
▪️ подробное разъяснение важной концепции глубокой прослеживаемости
▪️ актуализация обзора инструмента управления требованиями DOORS

✅ Плюсы книги:

1. практически нет «воды», всё изложено чётко и понятно
2. информации много, практически вся она полезная

➖ Минусы книги:

1. для неискушённого читателя и начинающего разработчика книга может показаться сложной

#требования

А у вас какие попугаи обитают?

🐞🔍 Тестирование. Основные понятия

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

💠 Основные виды тестирования

По запуску кода
● Статическое тестирование — тестирование без фактического выполнения кода
● Динамическое тестирование — не может быть осуществлено без запуска программного кода приложения.

По доступу к коду
● Белый ящик – с использованием доступа к исходному коду
● Чёрный ящик – без использования доступа к исходному коду

По уровню тестирования
● Модульное – проводится над отдельным компонентом системы
● Интеграционное – проверка взаимодействия нескольких компонентов или систем
● Системное – показывает, соответствует ли готовая система функциональным и нефункциональным требованиям
● Приёмочное (UAT) – выполняется самим заказчиком

По степени автоматизации
● Ручное
● Автоматизированное

По целям тестирования различают функциональное и нефункциональное тестирование. К нефункциональному тестированию относят:
● Нагрузочное тестирование – проверка поведения системы при плановой повышенной и пиковой нагрузке
● Стрессовое тестирование – проверка работы системы в критических условиях
● Тестирование удобства использования (usability testing)
● Тестирование безопасности
● Регрессионное тестирование — повторное тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.

Тестовые стенды
➖ Среда разработки (Dev) – за данную среду отвечают разработчики, в ней они пишут код, проводят отладку, исправляют ошибки
➖ Среда тестирования (Test) – среда, в которой работают тестировщики
➖ Интеграционная среда (Integration Env) – среда, в которой проводят тестирование взаимодействующих друг с другом систем
➖ Предпрод (Preprod Env) – среда, которая максимально приближена к продакшену. Здесь проводится заключительное тестирование функционала.
➖ Продакшн среда (Prod Env) – среда, в которой работают пользователи.

Этапы тестирования
1️⃣ Анализ требований – позволяет выяснить, какие возможные сложности могут возникнуть при тестировании. Также на этом этапе можно выявить возможные несоответствия или недостаточно ясные требования, которые требуют уточнения у разработчиков или заказчика
2️⃣ Планирование тестирования – выбор методов тестирования, определение ресурсов, сроков
3️⃣ Тест-дизайн – разработка тест-кейсов. Тест-кейс — это алгоритм действий, которые требуется совершить для проверки работы системы. Может иметь следующие атрибуты: ID, название, предусловия, шаги, ожидаемый результат, фактический результат, статус
4️⃣ Подготовка к тестированию – включает создание тестового окружения, подготовку тестовых данных, написание автотестов, деплой приложения на тестовом стенде
5️⃣ Выполнение тестирования – Сначала выполняется интеграционное или даже сразу системное тестирование, зависит от специфики тестирования в конкретной компании. Модульное тестирование обычно выполняется разработчиком при написании кода с помощью unit-тестов
6️⃣ Формирование результатов – подготовка отчёта о тестировании, содержащего информацию о результатах выполнения тест-кейсов и о выявленных дефектах

📎 Материалы
1. Фундаментальная теория тестирования
2. Как устроен процесс тестирования
3. Какие бывают этапы и виды тестирования
4. Как писать тест-кейсы
5. Большой учебник по тестированию
6. Курс по тестированию The 100-Year QA-Textbook — полезно и для аналитиков
7. Видео по видам тестирования

#тестирование #развитие

🚆 Релизный процесс. Кратко

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

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

Артефакты релиза можно условно разделить на две категории:

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

🔸 Документация релиза – это документы, которые описывают релиз. Сюда входят: Release Notes (описание того, что изменилось), план релиза протокол тестирования, отчёт о релизе и т.д.

Управление релизами охватывает все этапы от разработки и тестирования до развертывания.

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

1️⃣ Планирование релиза. На этом этапе определяются цели, сроки, приоритеты, ресурсы и ограничения релиза. Также формируется документация, в которой фиксируется список функций, задач, ответственных, рисков и критериев качества релиза. План релиза должен быть согласован с заинтересованными сторонами. Новые фичи полезно оборачивать в тоглы – это специальные механизмы, которые позволяют включать или отключать определенные функции или части релиза без необходимости изменять код или перезапускать приложение.

2️⃣ Сборка релиза. На этом этапе происходит создание и упаковка релизных объектов, таких как исходный код, исполняемые файлы, конфигурационные файлы, базы данных и т.д.

3️⃣ Приемочное пользовательское тестирование (UAT). Финальное тестирование, выполняемое перед выпуском в продуктив. После проведения тестирования руководство вместе с разработчиками принимают окончательное решение о выпуске продукта.

4️⃣ Развертывание релиза. На этом этапе код собирается в исполняемый файл или пакет, который может быть развернут на сервере или облачной платформе. Для этого могут использоваться различные инструменты и методы, такие как непрерывная доставка, контейнеризация, автоматизация и т.д. Цель этого этапа — упростить и ускорить процесс развертывания и обеспечить его надежность и безопасность.

5️⃣ Мониторинг и обратная связь. На этом этапе разработчики и операторы отслеживают работу веб-приложения, собирают данные о его производительности, доступности, ошибках и поведении пользователей. Для этого могут использоваться различные инструменты и сервисы, такие как системы логирования, аналитики, оповещения и т.д. Цель этого этапа — улучшить качество и удовлетворенность веб-приложения, а также выявить и исправить возможные проблемы.

📎 Материалы
1. Всë, что вам нужно знать об управлении релизами
2. Релизный цикл ПО для самых маленьких
3. Автоматизация процесса релиза (+ видео)
4. От пул-реквеста до релиза. Доклад Яндекс.Такси
5. Рецепт гладкого релиза: PMy на заметку
6. Управление релизами, когда и зачем нужно?
7. Как мы автоматизировали процесс генерации Release Notes — опыт МТС
8. Чек-лист: что нужно было делать до того, как запускать микросервисы в prod
9. Релизный поезд. Доклад Яндекса

#devops #управление_релизами

🟦 Нотация C4. Подборка материалов

С4 – простая нотация для описания архитектуры. Модель объединяет 4 иерархических уровня: Context, Container, Component, Code – отсюда и название.

1️⃣ Диаграммы контекста (Context) – показывают систему в масштабе ее взаимодействия с пользователями и другими системами. Детали здесь не важны, так как это уменьшенное изображение, показывающее общую картину системного ландшафта. В центре внимания не технологии, протоколы и другие низкоуровневые детали, а люди и системы. С диаграммой этого уровня могут работать “люди из бизнеса”.

2️⃣ Диаграммы контейнеров (Container) – показывают, как система разделена на отдельные контейнеры, которые работают в своих средах выполнения и взаимодействуют друг с другом и с внешним миром. Контейнеры могут быть приложениями, базами данных, файловыми системами, скриптами и другими элементами, необходимыми для работы системы. Диаграмма контейнеров помогает понять, какие технологии используются в системе, как она устроена и как она обслуживает пользователей и другие системы.

3️⃣ Диаграммы компонентов (Component) – показывает устройство контейнера. Здесь компонент – это группа связанных функций, объединённых четко определенным интерфейсом. Все компоненты не являются отдельно развертываемыми единицами и обычно выполняются внутри контейнера в одном и том же пространстве процесса. Целевая аудитория диаграмм уровня Component – разработчики и системные архитекторы.

4️⃣ Диаграммы кода (Code) – создаются по запросу и показывают низкоуровневую реализацию компонентов. Рекомендовано использовать UML Class diagram/Entity relationship diagram и генерировать эти диаграммы автоматически.
Пример используемых инструментов для уровня Code:
▫️ PlantUML – позволяет генерировать UML-диаграммы из текста;
▫️ C4Builder – обеспечивает экспорт в PDF и прочие форматы;
▫️ C4-PlantUML — плагин для IDEA.

Главные преимущества C4

✅ Унифицированный способ рисовать архитектурные схемы. В отличие от “нотации” boxes and lines, когда каждый рисует, как хочет и непонятно что, модель C4 позволяет улучшить читаемость диаграмм благодаря формализации использования элементов и связей.

✅ Нужная степень детализации. Модель позволяет выбрать нужный уровень детализации вместо того, чтобы попытаться запихнуть все системы и сервисы в одну схему. Это похоже на Google Maps, где можно увидеть целые страны, прежде чем опуститься до области, города и отдельного дома.

⛔️ Недостатки C4

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

➖ Модель не даёт чётких критериев по выделению контейнеров и компонентов. Могут возникать споры, например, по поводу отнесения базы данных к уровню Context или к уровню Component.

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

➖ Модель не учитывает изменения в архитектуре во времени и не позволяет отображать различные варианты и сценарии.

📎 Материалы

🌐 Официальный сайт

📄 Статьи
1. Как описать архитектуру продукта по нотации C4 — теория (вариант 1)
2. Как описать большую систему в нотации С4 — теория (вариант 2)
3. Аналитик и архитектура: UML-диаграммы для модели C4 — статья от Babok School
4. Описание архитектуры системы с помощью C4 model — взгляд разработчика
5. Опыт составления HLD-документации по нотации C4

⏯️ Видео
1. Визуализация архитектуры C4 model / Максим Пальчиков
2. Архитектурный репозиторий на базе GitLab и C4 Model для большой компании. Кирилл Ветчинкин
3. C4 models as code — Simon Brown

🎓 Бесплатный курс

#проектирование #архитектура #подборка

P of EAA: Patterns of Enterprise Application Architecture
(Шаблоны корпоративных приложений)

✍️ Автор: Мартин Фаулер
📅 Год: 2016
🔤 Язык: русский
📚 Объём: 548 стр.

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

#проектирование