Преамбула В этой серии статей я собираюсь обсудить различные преимущества микросервисов как архитектурного шаблона.
Я постараюсь осветить аспекты, которые либо вообще не обсуждаются в сети, либо обсуждаются, но недостаточно глубоко.
Все модели разработки обычно имеют свои плюсы и минусы.
Таким образом, преимущества часто субъективны, и проектировщику приходится выбирать подходящие модели в зависимости от условий и контекста.
Я постараюсь выделить объективные или почти объективные преимущества — преимущества, которые дадут положительный эффект любому разработчику, независимо от языка программирования, размера команды и рациона питания.
Первая статья посвящена стоимости плохо написанного кода — мы сравним влияние такого кода на монолитные приложения и на микросервисы.
Кроме того, позже, когда у меня будет несколько статей, я планирую смонтировать видео для YouTube — анимации и скринкасты будут более четко передавать мою мысль.
Введение: Как соглашения и фреймворки улучшают беспорядочный код
Когда вы пишете программу из 100 строк, не имеет значения, насколько крут ваш дизайн или насколько внимательно вы следите за модными тенденциями.Небольшое приложение относительно легко понять просто потому, что оно небольшое.
И начинать его оптимизировать было бы само по себе антипаттерном — такую оптимизацию часто называют преждевременной.
Обычно вы начинаете рефакторинг кода, когда замечаете, как выросли ваши исходные файлы или как вы повторяете одну и ту же логику более двух раз.
Но если в приложении всего 100 строк, сколько из этих повторов реально может поместиться? А потом ваш начальник просит все больше и больше функций, и ваше приложение начинает расти.
Теперь уже нет смысла хранить всю логику в одном файле; необходимо разбить приложение на несколько файлов.
А когда файлов становится много, начинаешь организовывать их по папкам.
Когда у вас много файлов и папок, вы ищете способ логически отсортировать их.
Вероятно, вы начнете разделять исходные файлы на модели, контроллеры и т. д. Начинает появляться опасность запутать код — файл X вызывает файл Y, Y частично зависит от файла Z, файл Z импортирует несколько функций из файлов A и B. Приходит младший разработчик, меняет один файл и все приложение ломается, и вы надо исправить ошибку до того, как первый разгневанный клиент позвонит начальнику.
Фреймворки пришли к нам, чтобы решить проблему.
Фреймворки часто навязывают свои собственные соглашения (правила), систематически разделяя приложение на файлы и каталоги.
Например, контроллеры должны заниматься только веб-запросами, классы моделей должны содержать бизнес-логику, шаблоны должны содержать только HTML, конфигурация должна храниться в отдельном месте и желательно зависеть от текущей среды.
Хотите добавить ресурс? Измените файл маршрутов! Хотите добавить дополнительную логику, которая запускается после сохранения записи? Подпишитесь на событие! Хотите добавить в базу данных дополнительные условия запроса? Создайте класс поведения таблицы! И так далее.
Это не просто поможет вам разрабатывать более крупные монолитные приложения, это единственный способ разработать большое приложение, не сойдя с ума! Если каждый член команды будет иметь возможность добавлять код куда угодно, ваш процесс разработки довольно быстро выйдет из-под контроля.
Давайте посмотрим на структуру пустого приложения Ruby on Rails:
Реальность такова, что в вашей команде могут быть неопытные (или похмельные) коллеги, которые время от времени будут нарушать, казалось бы, простые соглашения, и код будет становиться все сложнее и уродливее, несмотря на выбор «правильного» фреймворка и структуры../app/assets .
/app/assets/config .
/app/assets/images .
/app/assets/javascripts .
/app/assets/javascripts/channels .
/app/assets/stylesheets .
/app/channels/application_cable .
/app/controllers .
/app/controllers/concerns .
/app/helpers .
/app/jobs .
/app/mailers .
/app/models .
/app/models/concerns .
/app/views/layouts .
/bin .
/config .
/config/environments .
/config/initializers .
/config/locales .
/db .
/lib .
/lib/assets .
/lib/tasks .
/log .
/public .
/test .
/test/controllers .
/test/fixtures .
/test/fixtures/files .
/test/helpers .
/test/integration .
/test/mailers .
/test/models .
/tmp .
/vendor .
/vendor/assets .
/vendor/assets/javascripts .
/vendor/assets/stylesheets
Написание хорошего кода особенно важно в контексте большого приложения.Принципы SOLID, шаблоны разработки, структуры и соглашения появились, прежде всего, для помощи разработчикам при работе с большими приложениями.
Монолиты и микросервисы: влияние на спагетти-код
Вот что микросервисы делают со спагетти:
Упс, неправильная картинка.
Вот как выглядит спагетти-код для монолитного приложения: 
Один класс (или функция) вызывает другой класс, и этот класс зависит от другого класса, а этот класс зависит от нескольких других классов и так далее.
Хотите пройтись по коду и исправить ошибку — будьте готовы открыть множество файлов и параллельно их изучать.
Почему я считаю, что это характеристика монолитного приложения?
В монолитном приложении модули кода (элементы) вызывают друг друга напрямую — пользуясь тем, что все они загружаются в ОЗУ на одной машине.Это приводит к тому, что ленивые разработчики слишком тесно связывают части приложения вместе.
С другой стороны, микросервисы обычно взаимодействуют посредством веб-запросов (обычно RESTful) или сообщений.
Таким образом, разработчик не может просто вызвать функционал одного микросервиса из другого микросервиса — ему как минимум придется создать дополнительный маршрут, открыть этот метод в контроллере и так далее.
Это дополнительная работа, барьер, который разработчики не преодолеют без крайней необходимости.
Также существует вероятность того, что этот другой микросервис в настоящее время поддерживается другой командой вашей компании, а разработчики там отвратительны и не хотят добавлять ненужный (с их точки зрения) маршрут только для того, чтобы облегчить вам жизнь.
В результате у вас, скорее всего, будет меньше и лучше организованных связей.
А тот факт, что между микросервисами (различными функциональными модулями вашего приложения) меньше зависимостей, означает, что если микросервис А будет плохо реализован, он не окажет такого плохого влияния на другие микросервисы.
В среде микросервисов плохой код изолирован.
Микросервисы: успокойте своего внутреннего перфекциониста
Поскольку один микросервис — это не что иное, как один или два класса, вырезанных из вашего монолитного приложения, теперь у вас меньше, значительно меньше файлов в одном открытом приложении в IDE. Таким образом, вам, вероятно, больше не придется беспокоиться о строгих правилах именования файлов и папок, и, возможно, вы даже сможете ослабить правила SOLID. Теперь вы можете позволить себе халяву — вы можете сделать несколько ошибок, несколько неоптимальных реализаций, и ваше приложение по-прежнему довольно легко читать и редактировать, потому что ваш LoC (строк кода) упал с нескольких тысяч до жалких десятков или сотен! Процесс разработки ускорится, потому что вас будут меньше волновать строгие правила и множество зависимостей!Заключение
Микросервисы, как архитектурный шаблон, могут снизить стоимость неоптимального исходного кода, ускорить разработку и улучшить качество сна.Теги: #Микросервисы #soa #микросервисы #программирование #Идеальный код #проектирование и рефакторинг #ООП #Микросервисы
-
Болезни И Смерть Станции «Мир»
19 Oct, 24 -
Bgp Интер-Ас
19 Oct, 24 -
Несколько Жизненных Советов Для Разработчика
19 Oct, 24 -
Управление Мозгом С Помощью Лазера
19 Oct, 24 -
Управление Mozilla Firefox Через Gpo
19 Oct, 24
