Архитектура ПО. Введение

Ulbi TV
17 Oct 202211:03

Summary

TLDRВ этом видео автор начинает серию об архитектуре программного обеспечения, обсуждая её значение, различные подходы и принципы. Рассматриваются слоеная, луковая, чистая архитектуры, MVC, MVVM, реактивные подходы и архитектура фронтенд приложений. Освещаются проблемы, возникающие при отсутствии четкой архитектуры, такие как сложность удаления или изменения модулей и увеличение стоимости разработки. Подчеркивается важность сильной связанности внутри модулей и слабой между ними для упрощения поддержки и развития проекта.

Takeaways

  • 🏗 Архитектура в программировании - это не просто файловая структура проекта, но и набор модулей, компонентов и описаний их взаимодействий.
  • 🔍 Соблюдение принципов архитектуры помогает решать проблемы с расширяемостью и поддержкой кода, а также упрощает внесение изменений.
  • 🛠 Важность сильной связанности внутри модулей и слабой - между ними для обеспечения модульности и удобства поддержки.
  • 🔗 Хаотичные связи между модулями приводят к усложнению поддержки и развития проекта, увеличивая стоимость и время разработки.
  • 💡 Принципы SOLID и паттерны проектирования - ключевые инструменты для построения эффективной архитектуры.
  • 📦 Примеры архитектур: MVC, MVVM, слоенная (луковая), реактивная и фронтенд архитектуры.
  • 🔄 Возможность безболезненного удаления модулей - индикатор хорошей архитектуры.
  • 📚 Строгое описание архитектуры улучшает командную работу, делая код единообразным и облегчая введение новых разработчиков.
  • 🏢 Архитектура может быть микросервисной или монолитной, что определяет структуру и способ взаимодействия компонентов на разных уровнях.
  • 🤝 Теория и практика должны идти рука об руку для эффективного обучения и применения архитектурных принципов.

Q & A

  • Что такое архитектура в контексте разработки программного обеспечения?

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

  • Почему соблюдение архитектуры важно при разработке ПО?

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

  • Какие проблемы решает архитектура программного обеспечения?

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

  • Что такое сильная и слабая связанность в контексте архитектуры ПО?

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

  • Что представляет собой файловая структура в контексте архитектуры ПО?

    -Файловая структура - это организация файлов и папок в проекте, которая, хоть и является частью архитектуры, не следует путать её с самой архитектурой, которая включает в себя принципы организации и взаимодействия компонентов системы.

  • Какое значение имеет четкое определение архитектуры для командной работы?

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

  • Чем отличаются микросервисная и монолитная архитектуры?

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

  • Какие виды архитектур будут рассмотрены в серии роликов?

    -В серии роликов будут рассмотрены различные подходы к архитектуре, включая слоеную (луковую) архитектуру, чистую архитектуру, MVC, MVVM, реактивную архитектуру и архитектуру фронтенд приложений.

  • Какие принципы должны соблюдаться при разработке архитектуры?

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

  • Почему важно совмещение теории и практики при изучении архитектуры ПО?

    -Совмещение теории и практики важно для глубокого понимания принципов архитектуры ПО, так как позволяет не только усвоить теоретические основы, но и научиться применять их на практике, что способствует разработке более качественного и устойчивого к изменениям ПО.

Outlines

00:00

🏛 Введение в архитектуру программного обеспечения

Этот раздел представляет собой вступление в серию видеороликов об архитектуре программного обеспечения, охватывающих различные подходы и практики. Автор объясняет необходимость архитектуры для решения проблем, связанных с разработкой и поддержкой программного обеспечения. Рассматривается важность обдуманной архитектуры для предотвращения хаотичного кода и сложности в управлении зависимостями между модулями. Обсуждаются основные концепции, такие как слоеная, луковая архитектура, MVC, MVVM, и реактивные подходы, с акцентом на то, как эти стратегии помогают упростить разработку и обслуживание.

05:02

🔍 Проблемы хаотичной архитектуры

Во втором разделе подробно анализируются проблемы, возникающие из-за отсутствия четкой архитектурной структуры в проекте. Описывается, как беспорядочные и тесно связанные модули могут привести к сложности в управлении кодом, усложняя его рефакторинг, расширение и поддержку. Автор подчеркивает, как важно иметь модули с сильной внутренней связанностью, но слабыми внешними зависимостями, для облегчения модификации и обновления системы без значительного влияния на остальные части.

10:02

📐 Определение идеальной архитектуры

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

Mindmap

Keywords

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

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

💡Модуль

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

💡MVC

MVC (Model-View-Controller) - это архитектурный паттерн, который разделяет программу на три основных компонента: модель (данные), представление (интерфейс пользователя) и контроллер (логика управления). В видео упоминается, что MVC будет рассматриваться как один из подходов в архитектуре программного обеспечения.

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

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

💡Слоенная (луковая) архитектура

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

💡Принципы SOLID

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

💡Компонент

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

💡Фронтенд архитектура

Фронтенд архитектура относится к структуре и дизайну клиентской части веб-приложений. Это включает в себя организацию кода, управление состоянием и оптимизацию взаимодействия с пользователем. Видео упоминает, что фронтенд архитектура будет одной из тем серии роликов.

💡Рефакторинг

Рефакторинг - это процесс изменения внутренней структуры программного обеспечения без изменения его внешнего поведения. Видео подчеркивает, что хорошая архитектура упрощает рефакторинг, делая его менее рискованным и более эффективным.

💡Микросервисная архитектура

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

Highlights

Открытие серии роликов по архитектуре

Обзор различных подходов и видов архитектуры

Значимость и необходимость правильной архитектуры

Проблемы отсутствия продуманной архитектуры

Объяснение связей между модулями и их влияние

Важность принципа открытости для расширения, но закрытости для модификации

Последствия неправильной архитектуры: увеличение стоимости и сложности

Концепция сильной и слабой связанности между модулями

Определение архитектуры: модули, компоненты, связи

Различие между файловой структурой и архитектурой

Примеры плохих и хороших архитектурных практик

Антипаттерн 'Божественный объект'

Пример идеальной архитектуры: сильная внутренняя связность, слабая внешняя

Стратегии улучшения архитектуры для долгосрочной поддержки

Важность единообразия в командной работе и архитектуре

Различия между микросервисной и монолитной архитектурой

План серии роликов по архитектуре приложений

Transcripts

00:08

[музыка]

00:09

Приветствую вас друзья и этим видео Я

00:12

открываю серию роликов по архитектуре

00:15

будем рассматривать Различные подходы

00:17

практики поговорим про разные виды

00:20

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

00:22

по так и например к фронтенду поговорим

00:25

про слоенную луковую архитектуру про

00:28

чистую архитектуру mvc mvm поговорим про

00:32

реактивную архитектуру архитектуру

00:34

фронтенд приложений и другие виды

00:37

архитектур этот ролик будет водный в

00:39

целом расскажу Для чего нужна

00:40

архитектура Какие проблемы Она решает и

00:43

почему соблюдение архитектуры это важно

00:45

но и как обычно меньше слов больше дела

00:48

начинаем

00:49

начинающих очень размытое понимание того

00:52

что такое архитектура Я предлагаю начать

00:54

проблематики мы начинаем разрабатывать

00:57

приложение архитектуру мы никакую не

00:59

продумали просто пишем код у нас

01:01

появляется первый модуль внутри этого

01:03

модуля уже есть какие-то связи между под

01:06

модулями между какими-то компонентами

01:08

потом у нас появляется другой модуль и

01:10

связями обрастает не только внутренность

01:13

этого модуля но и связи появляются уже

01:15

между первым и вторым модулем Ну и как

01:18

нетрудно догадаться потом появляется

01:19

третий четвертый модуль связи становится

01:21

еще больше И вот в такой вот прогрессии

01:24

становится больше больше больше и больше

01:27

и вот проблема в том что безболезненно

01:30

удалить Один из таких модулей уже не

01:33

получается на него завязаны другие

01:35

модули То есть у нас все обросло

01:37

какими-то явными связями хоть и

01:39

openclose принципе солит говорить нам о

01:41

том что программные сущности должны быть

01:44

открыты для расширения но закрыты для

01:46

модификации Все мы все равно понимаем

01:48

что бизнес такая что и старый код

01:50

приходит моментами как-то изменять И

01:52

опять же здесь мы благодаря этим связям

01:54

из меня один модуль затрагиваем и другие

01:56

модули и соответственно чем больше такая

01:59

система тем больше этих связей и

02:01

компонентов в ней находится И

02:04

поддерживать систему с неявными связями

02:06

становится сложнее опять же в прогрессии

02:09

По мере того как эта система

02:11

разрастается и из этого вытекает очень

02:14

очевидная умозаключение Если

02:17

разрабатывать становится сложнее значит

02:19

это будет стоить дороже и дороже с

02:22

каждым днем грубо говоря причем Проблема

02:25

не только в удалении или изменении

02:27

старых модулей такие хаотичные связи с

02:30

ростом проекта усложняют также и

02:31

поддержку рефакторинг и добавление новых

02:34

печей то есть новые фичи в принципе

02:36

добавлять будет тоже сложнее потому что

02:39

хаотичные связи непонятно что куда

02:41

добавлять Как сделать Это лучше Ну и как

02:43

я уже сказал Вот это сложность она

02:45

эквивалентна деньгам и эквивалентна

02:48

времени затраченному на разработку из

02:50

этого можно сделать такой вывод что вот

02:52

эти модули которыми мы оперируем должны

02:55

обладать сильной связанностью это когда

02:57

внутренний компоненты модуля направлены

03:00

на решение одной четкой задачи то есть

03:02

Они между собой связаны сильно но при

03:05

этом с другими модулями должна эта связь

03:08

быть слабой обычно открывают слабые

03:10

зацепленностью то есть зависимость от

03:12

других модулей должна быть наименьшая об

03:16

этом мы еще на конкретных примерах чуть

03:17

позже поговорим с проблематикой

03:19

более-менее мы разобрались А теперь

03:22

давайте введем определение архитектуры

03:24

по архитектура это набор модулей

03:27

кирпичиков компонентов системы описания

03:30

того как эти компоненты модули должны

03:33

разрабатываться и описание связей между

03:36

этими модулями и также создание

03:39

интерфейсов который четко описывают для

03:42

чего этот модуль предназначен все вот

03:45

это в принципе такое краткое понятное

03:47

определение архитектуры еще начинающие

03:50

часто думают что архитектура это набор

03:52

папочек и файликов вашим компоненте и

03:56

вот здесь можно однозначно ответить Нет

03:57

это не так это всего лишь файловая

04:00

структура вашего проекта хотя и она в

04:02

том числе является частью архитектуры

04:04

теперь вернемся к той самой сильной

04:07

связанности и слабой зацеп и прям на

04:10

конкретных примерах посмотрим как это

04:13

должно работать Какие примеры У нас есть

04:15

плохие и Какие примеры есть хорошие

04:24

посмотрим на эту ось координат в которой

04:26

представлено 4 варианта различных связей

04:30

между модулями и компонентами им здесь

04:32

сразу можно заметить что идеальный

04:34

вариант это правый нижний угол где у нас

04:38

сильная связанность и слабая

04:40

зацепленность и давайте сейчас по

04:42

каждому из примеров пройдемся и

04:43

обговорим что в них не так самый простой

04:46

для объяснения пример это так называемый

04:48

Анти паттерн год object когда у нас есть

04:52

классы модули компоненты любые функции

04:56

которые выполняют сразу все я думаю

04:59

каждый из вас сталкивался с такими

05:01

классами которые на несколько тысяч

05:03

строк кода и которые решают сразу

05:05

миллион задач нарушая все принципы соли

05:08

причем в данном случае речь идет не о

05:11

классе а целом проекте Когда у нас нет

05:14

четкой выделенных модулей Когда у нас

05:16

нет четко выделенных компонентов и все

05:18

это обрастает такими вот непонятными

05:20

связями и получается один такой большой

05:23

кусок который вроде бы и решает какую-то

05:25

задачу но распутать этот клубок уже

05:28

практически невозможно и если взглянуть

05:30

опять же на ось координат то глоток у

05:33

нас обладает и высокой связанностью и

05:36

высокой зацепленностью что они есть

05:38

Хорошо теперь рассмотрим пример в

05:40

котором и слабая зацепленность и слабая

05:42

связанность то здесь можно заметить что

05:45

вроде как какие-то модули здесь

05:47

выделяются но при этом кирпичики из

05:49

которых этот модуль строится Они вроде

05:51

как решают разные задачи Как видите

05:53

здесь они покрашены в разные цвета то

05:56

есть тоже внутри модуля есть какая-то

05:58

хаотичность и слабая связанность вот

06:00

этих вот кирпичиков но и при этом здесь

06:03

можно заметить что между модулями тоже

06:05

как таковые связи не явные это еще раз

06:08

был пример из Нижнего левого угла Когда

06:11

у нас и слабая зацепленность и слабая

06:13

связанность теперь рассмотрим почти

06:15

хороший пример здесь уже можно заметить

06:18

что модуль нас выделены четко и связи

06:21

между этими модулями Тоже хорош три

06:24

модулей должна быть сильная связанность

06:26

А тут как видите она слабая то есть

06:28

кирпичики вот эти у нас разных цветов и

06:31

они подразумеваются что они не решают

06:33

конкретную задачу они как-то хаотично

06:36

перемешаны и такое тоже часто

06:37

встречается вроде бы человек создает

06:40

отдельный модуль но при этом в этом

06:42

модуле вот как-то непонятно все сделано

06:44

вроде бы можно что-то вынести в

06:46

переиспользуемое что-то можно отнести к

06:48

другому модулю что-то где-то дублируется

06:51

но этот пример уже гораздо лучше чем

06:54

предыдущие два поскольку здесь

06:55

безболезненно можно удалить целый модуль

06:58

и прям как-то кардинально на приложение

07:00

это Не скажется и остается у нас

07:03

последний вариант это идеальный вариант

07:05

правый нижний угол и вот здесь вот уже

07:08

все по канону во-первых связи между

07:10

модулями у нас слабые то есть один

07:13

модуль легко можно удалить и кардинально

07:15

на приложение это Не скажется но и

07:17

внутри модуля у нас компоненты которые

07:19

решают одну задачу они сильно связаны

07:22

друг с другом и нету вот этой вот

07:24

перемешанности которая была в предыдущем

07:26

примере Понятное дело что это идеальный

07:29

вариант и в реальном мире такое

07:31

встречается крайне редко хочешь не

07:33

хочешь появляются лишние связи

07:35

появляется слабая связанность между теми

07:38

же компонентами модуля Но к такому надо

07:40

стремиться и стремление к этому в любом

07:43

случае в долгосрочной перспективе

07:45

улучшит разработку и поддержку вашего

07:47

проекта и того еще раз подытожим

07:50

архитектура это именно набор модулей

07:53

компонентов и связей между этими

07:55

компонентами в первую очередь и основная

07:58

суть чтобы вот те самые принципы драй

08:01

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

08:03

уже где-то был написан кейс чтобы все

08:06

было как можно проще солит паттерны это

08:09

все должно работать и самое главное что

08:12

удаление и изменения модуля должно быть

08:14

простым даже не изменение а именно

08:16

удаление то есть первую очередь акцент

08:19

стоит делать на удалении модулей То есть

08:21

вы безболезненно можете взять один из

08:23

модулей выпилить его Исхода и в целом

08:25

это как-то затронуть приложение

08:27

глобально не должно может быть в двух

08:29

трех местах что-то поправить и В целом

08:31

все еще важно понимать что если вы

08:33

разрабатываете проект не один Если у вас

08:35

есть команда то строгое описание вот

08:37

этой архитектуры помогает улучшить

08:39

качество потому что во-первых все делают

08:41

примерно единообразно пишет похожий код

08:44

переиспользуют похожие модули и таким

08:47

образом легче проводить коды review

08:49

легче создавать новые модули потому что

08:51

уже есть похожие примеры в коде и в

08:54

целом легче разрабатывать потому что не

08:56

каждый придумывает какие-то свои

08:57

велосипеды а все действуют по четко

09:00

обозначенным правилам и даже если в

09:02

команду приходит Новый человек можно

09:04

скинуть ему документацию на вашу

09:06

архитектуру он почитает и в целом уже

09:08

будет примерно понимать что у вас

09:09

происходит

09:10

что мы здесь происходит также

09:13

архитектура бывает на разных уровнях

09:15

бывает уровень повыше бывает уровень

09:17

пониже уровень повышен например

09:19

микросервис на архитектура монолитно

09:21

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

09:23

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

09:25

что у нас есть какой-то шлюз есть

09:27

какой-то набор микросервисов и с этими

09:30

сервисами через шлюз мы можем

09:31

взаимодействовать То есть это такая

09:33

архитектура более верхнееуровневая и уже

09:36

в свою очередь каждый из этих сервисов

09:38

обладает какой-то своей уже более

09:40

низкоуровневой архитектурой выстраивает

09:42

те самые модули связи между этими

09:45

модулями и вот в серии роликов которую я

09:48

запланировал мы будем рассматривать

09:49

именно архитектуру приложений Хотя

09:51

микросервис но возможно мы рассмотрим

09:53

тоже если будет много желающих в

09:55

комментариях Если в целом поддержите

09:57

этот ролик то есть будем рассматривать

09:59

такие архитектуры и подходы как nvc и

10:02

чисто архитектура лукова или

10:03

многослойная архитектуры архитектуру

10:05

фронтенд приложений реактивный

10:07

архитектура этот список не отражает

10:09

последовательность роликов не отражает

10:11

их тематику Я пока еще Думаю над тем

10:14

Какие архитектурные подходы Я хочу

10:15

записать и соответственно Вот такая вот

10:18

серия роликов у нас получится начнем с

10:21

более простых вариантов например mvc или

10:23

многослойная архитектура чтобы даже

10:25

новички смогли погрузиться и затем

10:27

постепенно Постепенно будем переходить к

10:29

более сложным вариантам Ну и самое

10:31

главное я планирую давать не только

10:33

сухую теорию но и какие-то практические

10:36

варианты реализации чтобы лучше было

10:38

понятно как говорится теория без

10:40

практики мертва на практика без теории

10:42

слепа они должны идти всегда в тандеме и

10:46

на этом сводным роликом мы заканчиваем

10:48

Надеюсь было Хоть кому-то Полезно если

10:50

это так Оставь комментарий Поставь лайк

10:53

это во-первых и поддержка меня и

10:56

продвижение ролика по алгоритмам YouTube

10:59

Ну а я свою очередь пойду делать

11:01

следующий ролик