🏗️ Темы по архитектуре для инженеров ПО💪

🏗️ Темы по архитектуре для инженеров ПО💪

Уровень материала: 🐓 #senior
Разгребая бэклог, добрался до поста канала S0ER с «темами по архитектуре, которые должны входить в архитектурный минимум каждого инженера». Структуризация, возможно, спорная, но это авторское видение, и если «душность» оставить за скобками, то ещё и очень хорошая система тегов для профессионального развития.

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

☝ Пользуясь случаем, напомню, что игры — это тоже ПО. А разработка ПО — инженерная дисциплина. У игр, несомненно, есть своя специфика, но она никак не отменяет всего остального инженерного бэкграунда. Особенно, когда работаешь не только на клиентской части.

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

🎥 Можно ещё побродить по YouTube-каналу S0ER'а. Видео не выходили давно, но контента там уже накопилось много. Например, я недавно пересматривал видео по KISS, чтобы освежить в памяти некоторые красноречивые пункты.

🕸 Схема в текстовом виде:

Архитектура:

|- Требования:

|---- Функциональные

|---- Нефункциональные

|---- Производные

|---- Пользовательские истории

|- Принципы:

|---- Границы: толстые, тонкие

|---- YAGNI

|---- KISS

|---- DRY

|- Подходы:

|---- Проектные

|---- Продуктовые

|- Методология:

|---- DDD: тактика, стратегия

|---- Agile: SCRUM, экстремальное программирование

|---- Waterfall: сверху вниз, снизу вверх

|- Процессы:

|---- Документирование: BPMN, UML

|---- Проектирование: ADR, C4

|---- Выпуск: версионирование, CI/CD

|- Уровень предприятия:

|---- ITIL

|---- PRINCE2

|- Облачная архитектура

|- Проектирование и разработка:

|---- Уровень кода:

|------- Шаблоны проектирования (GoF)

|------- Парадигмы:

|---------- ООП: SOLID, GRASP, DI

|---------- ФП

|---- Уровень приложения:

|------- Концепции:

|---------- Реактивная архитектура

|---------- Чистая архитектура

|---------- Порты и адаптеры

|---------- Feature Sliced

|------- Структура:

|---------- Монолит

|---------- Сервис

|---------- Микросервис

|---------- Микроядро/плагин

|------- Данные:

|---------- Потоки данных: CQRS, Конвейер/pipe, pub/sub, SAGA

|---------- Целостность: BASE, ACID

|---- Системный уровень:

|------- Данные: Data Lake, Data Mesh

————————————

1010
13 комментариев

Как синьер пользуюсь 1 системой - делой нормально - будет нормально

1
1

Для клиентской части ещё рекомендую использовать кнопку "сделать красиво" 🙂

какая-то сферическая в вакууме диаграмма про самые банальные вещи. Вообще ничего специфичного для геймдева нет

2

про то и пост, что для геймдева ничего специфичного нет – спасибо за суммаризацию 🙂

Напиши мне бот, когда бывшая мне пишет, ... Привет как дела...
Что бы он ей что-нибудь отвечал

К сожалению, я больше специализируюсь на накручивании рейтинга во Вконтакте 👉👈

Почему среди парадигм не указана процедурная? Подавляющее большинство enterprise систем написанных на фреймворках вроде Spring используют архитектурный подход simple domain model. А это ничто иное, как процедурный подход.