Архитектура ПО. Введение
Summary
TLDRВ этом видео автор начинает серию об архитектуре программного обеспечения, обсуждая её значение, различные подходы и принципы. Рассматриваются слоеная, луковая, чистая архитектуры, MVC, MVVM, реактивные подходы и архитектура фронтенд приложений. Освещаются проблемы, возникающие при отсутствии четкой архитектуры, такие как сложность удаления или изменения модулей и увеличение стоимости разработки. Подчеркивается важность сильной связанности внутри модулей и слабой между ними для упрощения поддержки и развития проекта.
Takeaways
- 🏗 Архитектура в программировании - это не просто файловая структура проекта, но и набор модулей, компонентов и описаний их взаимодействий.
- 🔍 Соблюдение принципов архитектуры помогает решать проблемы с расширяемостью и поддержкой кода, а также упрощает внесение изменений.
- 🛠 Важность сильной связанности внутри модулей и слабой - между ними для обеспечения модульности и удобства поддержки.
- 🔗 Хаотичные связи между модулями приводят к усложнению поддержки и развития проекта, увеличивая стоимость и время разработки.
- 💡 Принципы SOLID и паттерны проектирования - ключевые инструменты для построения эффективной архитектуры.
- 📦 Примеры архитектур: MVC, MVVM, слоенная (луковая), реактивная и фронтенд архитектуры.
- 🔄 Возможность безболезненного удаления модулей - индикатор хорошей архитектуры.
- 📚 Строгое описание архитектуры улучшает командную работу, делая код единообразным и облегчая введение новых разработчиков.
- 🏢 Архитектура может быть микросервисной или монолитной, что определяет структуру и способ взаимодействия компонентов на разных уровнях.
- 🤝 Теория и практика должны идти рука об руку для эффективного обучения и применения архитектурных принципов.
Q & A
Что такое архитектура в контексте разработки программного обеспечения?
-Архитектура в контексте разработки программного обеспечения - это набор модулей, компонентов системы, описание того, как эти компоненты и модули должны разрабатываться, и описание связей между этими модулями, а также создание интерфейсов, которые четко описывают предназначение каждого модуля.
Почему соблюдение архитектуры важно при разработке ПО?
-Соблюдение архитектуры важно, потому что помогает решать проблемы масштабируемости и поддержки кода, упрощает добавление новых функций и модулей, а также обеспечивает возможность легкого удаления или модификации существующих элементов без вреда для всей системы.
Какие проблемы решает архитектура программного обеспечения?
-Архитектура помогает управлять сложностью системы, упрощает поддержку и рефакторинг кода, способствует масштабированию проекта и уменьшает его стоимость и время на разработку за счет предотвращения хаотичных связей и повторения кода.
Что такое сильная и слабая связанность в контексте архитектуры ПО?
-Сильная связанность означает, что компоненты внутри модуля тесно связаны и направлены на решение одной задачи, в то время как слабая связанность означает, что зависимость между различными модулями минимальна, что упрощает модификацию и масштабирование системы.
Что представляет собой файловая структура в контексте архитектуры ПО?
-Файловая структура - это организация файлов и папок в проекте, которая, хоть и является частью архитектуры, не следует путать её с самой архитектурой, которая включает в себя принципы организации и взаимодействия компонентов системы.
Какое значение имеет четкое определение архитектуры для командной работы?
-Четкое определение архитектуры улучшает качество командной работы, поскольку все участники проекта понимают общие принципы и структуру, что облегчает код-ревью, создание новых модулей и обеспечивает единообразие кода.
Чем отличаются микросервисная и монолитная архитектуры?
-Микросервисная архитектура подразумевает разделение приложения на набор маленьких, независимо работающих сервисов, каждый из которых выполняет конкретную функцию. Монолитная архитектура, напротив, предполагает единую и неделимую структуру приложения, где все компоненты тесно связаны и работают в рамках одного процесса.
Какие виды архитектур будут рассмотрены в серии роликов?
-В серии роликов будут рассмотрены различные подходы к архитектуре, включая слоеную (луковую) архитектуру, чистую архитектуру, MVC, MVVM, реактивную архитектуру и архитектуру фронтенд приложений.
Какие принципы должны соблюдаться при разработке архитектуры?
-При разработке архитектуры должны соблюдаться принципы, направленные на минимизацию повторения кода, обеспечение модульности и легкости внесения изменений, включая принципы SOLID, и стремление к сильной связанности внутри модулей и слабой связанности между ними.
Почему важно совмещение теории и практики при изучении архитектуры ПО?
-Совмещение теории и практики важно для глубокого понимания принципов архитектуры ПО, так как позволяет не только усвоить теоретические основы, но и научиться применять их на практике, что способствует разработке более качественного и устойчивого к изменениям ПО.
Outlines
🏛 Введение в архитектуру программного обеспечения
Этот раздел представляет собой вступление в серию видеороликов об архитектуре программного обеспечения, охватывающих различные подходы и практики. Автор объясняет необходимость архитектуры для решения проблем, связанных с разработкой и поддержкой программного обеспечения. Рассматривается важность обдуманной архитектуры для предотвращения хаотичного кода и сложности в управлении зависимостями между модулями. Обсуждаются основные концепции, такие как слоеная, луковая архитектура, MVC, MVVM, и реактивные подходы, с акцентом на то, как эти стратегии помогают упростить разработку и обслуживание.
🔍 Проблемы хаотичной архитектуры
Во втором разделе подробно анализируются проблемы, возникающие из-за отсутствия четкой архитектурной структуры в проекте. Описывается, как беспорядочные и тесно связанные модули могут привести к сложности в управлении кодом, усложняя его рефакторинг, расширение и поддержку. Автор подчеркивает, как важно иметь модули с сильной внутренней связанностью, но слабыми внешними зависимостями, для облегчения модификации и обновления системы без значительного влияния на остальные части.
📐 Определение идеальной архитектуры
Третий раздел описывает идеал архитектурного подхода, где стремление к модулям с сильной внутренней связанностью и слабой внешней зацепленностью представлено как ключ к эффективной разработке и поддержке. Автор обсуждает различные примеры архитектурных структур, от плохо спроектированных с высокой зацепленностью до идеальных с балансом между сильной внутренней связанностью и слабой внешней. Рассматривается важность четкого определения модулей, их ролей и взаимодействий для создания структурированного и управляемого проекта.
Mindmap
Keywords
💡Архитектура
💡Модуль
💡MVC
💡Реактивная архитектура
💡Слоенная (луковая) архитектура
💡Принципы SOLID
💡Компонент
💡Фронтенд архитектура
💡Рефакторинг
💡Микросервисная архитектура
Highlights
Открытие серии роликов по архитектуре
Обзор различных подходов и видов архитектуры
Значимость и необходимость правильной архитектуры
Проблемы отсутствия продуманной архитектуры
Объяснение связей между модулями и их влияние
Важность принципа открытости для расширения, но закрытости для модификации
Последствия неправильной архитектуры: увеличение стоимости и сложности
Концепция сильной и слабой связанности между модулями
Определение архитектуры: модули, компоненты, связи
Различие между файловой структурой и архитектурой
Примеры плохих и хороших архитектурных практик
Антипаттерн 'Божественный объект'
Пример идеальной архитектуры: сильная внутренняя связность, слабая внешняя
Стратегии улучшения архитектуры для долгосрочной поддержки
Важность единообразия в командной работе и архитектуре
Различия между микросервисной и монолитной архитектурой
План серии роликов по архитектуре приложений
Transcripts
[музыка]
Приветствую вас друзья и этим видео Я
открываю серию роликов по архитектуре
будем рассматривать Различные подходы
практики поговорим про разные виды
архитектуры применимы как ко всем видам
по так и например к фронтенду поговорим
про слоенную луковую архитектуру про
чистую архитектуру mvc mvm поговорим про
реактивную архитектуру архитектуру
фронтенд приложений и другие виды
архитектур этот ролик будет водный в
целом расскажу Для чего нужна
архитектура Какие проблемы Она решает и
почему соблюдение архитектуры это важно
но и как обычно меньше слов больше дела
начинаем
начинающих очень размытое понимание того
что такое архитектура Я предлагаю начать
проблематики мы начинаем разрабатывать
приложение архитектуру мы никакую не
продумали просто пишем код у нас
появляется первый модуль внутри этого
модуля уже есть какие-то связи между под
модулями между какими-то компонентами
потом у нас появляется другой модуль и
связями обрастает не только внутренность
этого модуля но и связи появляются уже
между первым и вторым модулем Ну и как
нетрудно догадаться потом появляется
третий четвертый модуль связи становится
еще больше И вот в такой вот прогрессии
становится больше больше больше и больше
и вот проблема в том что безболезненно
удалить Один из таких модулей уже не
получается на него завязаны другие
модули То есть у нас все обросло
какими-то явными связями хоть и
openclose принципе солит говорить нам о
том что программные сущности должны быть
открыты для расширения но закрыты для
модификации Все мы все равно понимаем
что бизнес такая что и старый код
приходит моментами как-то изменять И
опять же здесь мы благодаря этим связям
из меня один модуль затрагиваем и другие
модули и соответственно чем больше такая
система тем больше этих связей и
компонентов в ней находится И
поддерживать систему с неявными связями
становится сложнее опять же в прогрессии
По мере того как эта система
разрастается и из этого вытекает очень
очевидная умозаключение Если
разрабатывать становится сложнее значит
это будет стоить дороже и дороже с
каждым днем грубо говоря причем Проблема
не только в удалении или изменении
старых модулей такие хаотичные связи с
ростом проекта усложняют также и
поддержку рефакторинг и добавление новых
печей то есть новые фичи в принципе
добавлять будет тоже сложнее потому что
хаотичные связи непонятно что куда
добавлять Как сделать Это лучше Ну и как
я уже сказал Вот это сложность она
эквивалентна деньгам и эквивалентна
времени затраченному на разработку из
этого можно сделать такой вывод что вот
эти модули которыми мы оперируем должны
обладать сильной связанностью это когда
внутренний компоненты модуля направлены
на решение одной четкой задачи то есть
Они между собой связаны сильно но при
этом с другими модулями должна эта связь
быть слабой обычно открывают слабые
зацепленностью то есть зависимость от
других модулей должна быть наименьшая об
этом мы еще на конкретных примерах чуть
позже поговорим с проблематикой
более-менее мы разобрались А теперь
давайте введем определение архитектуры
по архитектура это набор модулей
кирпичиков компонентов системы описания
того как эти компоненты модули должны
разрабатываться и описание связей между
этими модулями и также создание
интерфейсов который четко описывают для
чего этот модуль предназначен все вот
это в принципе такое краткое понятное
определение архитектуры еще начинающие
часто думают что архитектура это набор
папочек и файликов вашим компоненте и
вот здесь можно однозначно ответить Нет
это не так это всего лишь файловая
структура вашего проекта хотя и она в
том числе является частью архитектуры
теперь вернемся к той самой сильной
связанности и слабой зацеп и прям на
конкретных примерах посмотрим как это
должно работать Какие примеры У нас есть
плохие и Какие примеры есть хорошие
посмотрим на эту ось координат в которой
представлено 4 варианта различных связей
между модулями и компонентами им здесь
сразу можно заметить что идеальный
вариант это правый нижний угол где у нас
сильная связанность и слабая
зацепленность и давайте сейчас по
каждому из примеров пройдемся и
обговорим что в них не так самый простой
для объяснения пример это так называемый
Анти паттерн год object когда у нас есть
классы модули компоненты любые функции
которые выполняют сразу все я думаю
каждый из вас сталкивался с такими
классами которые на несколько тысяч
строк кода и которые решают сразу
миллион задач нарушая все принципы соли
причем в данном случае речь идет не о
классе а целом проекте Когда у нас нет
четкой выделенных модулей Когда у нас
нет четко выделенных компонентов и все
это обрастает такими вот непонятными
связями и получается один такой большой
кусок который вроде бы и решает какую-то
задачу но распутать этот клубок уже
практически невозможно и если взглянуть
опять же на ось координат то глоток у
нас обладает и высокой связанностью и
высокой зацепленностью что они есть
Хорошо теперь рассмотрим пример в
котором и слабая зацепленность и слабая
связанность то здесь можно заметить что
вроде как какие-то модули здесь
выделяются но при этом кирпичики из
которых этот модуль строится Они вроде
как решают разные задачи Как видите
здесь они покрашены в разные цвета то
есть тоже внутри модуля есть какая-то
хаотичность и слабая связанность вот
этих вот кирпичиков но и при этом здесь
можно заметить что между модулями тоже
как таковые связи не явные это еще раз
был пример из Нижнего левого угла Когда
у нас и слабая зацепленность и слабая
связанность теперь рассмотрим почти
хороший пример здесь уже можно заметить
что модуль нас выделены четко и связи
между этими модулями Тоже хорош три
модулей должна быть сильная связанность
А тут как видите она слабая то есть
кирпичики вот эти у нас разных цветов и
они подразумеваются что они не решают
конкретную задачу они как-то хаотично
перемешаны и такое тоже часто
встречается вроде бы человек создает
отдельный модуль но при этом в этом
модуле вот как-то непонятно все сделано
вроде бы можно что-то вынести в
переиспользуемое что-то можно отнести к
другому модулю что-то где-то дублируется
но этот пример уже гораздо лучше чем
предыдущие два поскольку здесь
безболезненно можно удалить целый модуль
и прям как-то кардинально на приложение
это Не скажется и остается у нас
последний вариант это идеальный вариант
правый нижний угол и вот здесь вот уже
все по канону во-первых связи между
модулями у нас слабые то есть один
модуль легко можно удалить и кардинально
на приложение это Не скажется но и
внутри модуля у нас компоненты которые
решают одну задачу они сильно связаны
друг с другом и нету вот этой вот
перемешанности которая была в предыдущем
примере Понятное дело что это идеальный
вариант и в реальном мире такое
встречается крайне редко хочешь не
хочешь появляются лишние связи
появляется слабая связанность между теми
же компонентами модуля Но к такому надо
стремиться и стремление к этому в любом
случае в долгосрочной перспективе
улучшит разработку и поддержку вашего
проекта и того еще раз подытожим
архитектура это именно набор модулей
компонентов и связей между этими
компонентами в первую очередь и основная
суть чтобы вот те самые принципы драй
чтобы вы не повторяли свой код который
уже где-то был написан кейс чтобы все
было как можно проще солит паттерны это
все должно работать и самое главное что
удаление и изменения модуля должно быть
простым даже не изменение а именно
удаление то есть первую очередь акцент
стоит делать на удалении модулей То есть
вы безболезненно можете взять один из
модулей выпилить его Исхода и в целом
это как-то затронуть приложение
глобально не должно может быть в двух
трех местах что-то поправить и В целом
все еще важно понимать что если вы
разрабатываете проект не один Если у вас
есть команда то строгое описание вот
этой архитектуры помогает улучшить
качество потому что во-первых все делают
примерно единообразно пишет похожий код
переиспользуют похожие модули и таким
образом легче проводить коды review
легче создавать новые модули потому что
уже есть похожие примеры в коде и в
целом легче разрабатывать потому что не
каждый придумывает какие-то свои
велосипеды а все действуют по четко
обозначенным правилам и даже если в
команду приходит Новый человек можно
скинуть ему документацию на вашу
архитектуру он почитает и в целом уже
будет примерно понимать что у вас
происходит
что мы здесь происходит также
архитектура бывает на разных уровнях
бывает уровень повыше бывает уровень
пониже уровень повышен например
микросервис на архитектура монолитно
архитектура и вот например микросервис
на архитектура если кратко подразумевает
что у нас есть какой-то шлюз есть
какой-то набор микросервисов и с этими
сервисами через шлюз мы можем
взаимодействовать То есть это такая
архитектура более верхнееуровневая и уже
в свою очередь каждый из этих сервисов
обладает какой-то своей уже более
низкоуровневой архитектурой выстраивает
те самые модули связи между этими
модулями и вот в серии роликов которую я
запланировал мы будем рассматривать
именно архитектуру приложений Хотя
микросервис но возможно мы рассмотрим
тоже если будет много желающих в
комментариях Если в целом поддержите
этот ролик то есть будем рассматривать
такие архитектуры и подходы как nvc и
чисто архитектура лукова или
многослойная архитектуры архитектуру
фронтенд приложений реактивный
архитектура этот список не отражает
последовательность роликов не отражает
их тематику Я пока еще Думаю над тем
Какие архитектурные подходы Я хочу
записать и соответственно Вот такая вот
серия роликов у нас получится начнем с
более простых вариантов например mvc или
многослойная архитектура чтобы даже
новички смогли погрузиться и затем
постепенно Постепенно будем переходить к
более сложным вариантам Ну и самое
главное я планирую давать не только
сухую теорию но и какие-то практические
варианты реализации чтобы лучше было
понятно как говорится теория без
практики мертва на практика без теории
слепа они должны идти всегда в тандеме и
на этом сводным роликом мы заканчиваем
Надеюсь было Хоть кому-то Полезно если
это так Оставь комментарий Поставь лайк
это во-первых и поддержка меня и
продвижение ролика по алгоритмам YouTube
Ну а я свою очередь пойду делать
следующий ролик
5.0 / 5 (0 votes)
Alexander Björling, DLSR7 conference
Искусственный Интеллект в Юриспруденции: Как нейросети применяют юристы
Основы ЭКГ за 100 минут | Проводящая Система Сердца | Зубцы, интервалы, сегменты на ЭКГ
7 ПОЛЕЗНЫХ устройств на АРДУИНО, которые можно собрать за 15 минут.
Алексей Романов. "Конфликт поколений"
Гайд. ЗАБЫТАЯ ИМБА! ЛОВУШКА ДЛЯ КАЛАШИСТА в раст раст строительство как построить