День шестьсот девяносто седьмой. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
71. Изобретайте Велосипеды
Просто используйте то, что уже существует. Глупо изобретать велосипед…
Сколько раз вы слышали эту фразу или её вариации? Каждому разработчику это приходится слышать довольно часто. Но почему? Почему изобретение велосипеда так осуждается? Потому что чаще всего существующий код является рабочим кодом. Он уже прошёл какой-то контроль качества и тщательное тестирование и успешно используется. Кроме того, время и усилия, вложенные в переписывание, вряд ли окупят выгоды перед использованием существующего продукта или кодовой базы. Стоит ли изобретать велосипед? Зачем? Когда?
Возможно, вы слышали о паттернах (#DesignPatterns) разработки или читали книги по разработке ПО. Эти книги могут быть скучными, независимо от того, насколько прекрасна содержащаяся в них информация. Точно так же, как просмотр фильма о парусном спорте сильно отличается от парусного спорта. Так и использование существующего кода намного скучнее разработки собственного ПО с нуля, его тестирования, взлома, починки и улучшения в процессе.
Изобретение велосипеда - это не просто упражнение в том, где разместить конструкции кода: это о том, как получить глубокие знания о внутренней работе различных компонентов, которые уже существуют. Вы знаете, как работают менеджеры памяти? Виртуальный пейджинг? Можете реализовать это самостоятельно? Как насчет двусвязных списков? Классов динамических массивов? ODBC-клиента? Можете написать графический пользовательский интерфейс, который бы работал так же, как один из популярных, известных вам? Можете создать свой собственный виджет для браузера? Знаете, как «на лету» выбрать между записью в постоянную БД или в БД в памяти?
Большинство разработчиков просто никогда сами не создавали такие типы основных программных реализаций и поэтому не имеют глубоких знаний о том, как они функционируют. Как следствие, все эти виды программного обеспечения рассматриваются как загадочные чёрные ящики, которые просто работают. Только поверхностного понимания недостаточно, чтобы выявить скрытые в глубине опасности. Незнание более глубоких вещей в разработке программного обеспечения ограничит вашу способность создавать блестящие продукты.
Изобретать велосипед и ошибаться гораздо важнее, чем делать всё правильно с первого раза. Уроки, извлечённые из проб и ошибок, содержат эмоциональную составляющую, которую невозможно получить при чтении технической книги!
Изученные факты и «книжные навыки» имеют решающее значение. Но для того, чтобы стать отличным программистом, приобретённый опыт не менее важен, чем полученные знания. Изобретать велосипед так же важно для образования и навыков разработчика, как тяжелая атлетика важна для бодибилдера.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Jason P. Sage
97 Вещей, Которые Должен Знать Каждый Программист
71. Изобретайте Велосипеды
Просто используйте то, что уже существует. Глупо изобретать велосипед…
Сколько раз вы слышали эту фразу или её вариации? Каждому разработчику это приходится слышать довольно часто. Но почему? Почему изобретение велосипеда так осуждается? Потому что чаще всего существующий код является рабочим кодом. Он уже прошёл какой-то контроль качества и тщательное тестирование и успешно используется. Кроме того, время и усилия, вложенные в переписывание, вряд ли окупят выгоды перед использованием существующего продукта или кодовой базы. Стоит ли изобретать велосипед? Зачем? Когда?
Возможно, вы слышали о паттернах (#DesignPatterns) разработки или читали книги по разработке ПО. Эти книги могут быть скучными, независимо от того, насколько прекрасна содержащаяся в них информация. Точно так же, как просмотр фильма о парусном спорте сильно отличается от парусного спорта. Так и использование существующего кода намного скучнее разработки собственного ПО с нуля, его тестирования, взлома, починки и улучшения в процессе.
Изобретение велосипеда - это не просто упражнение в том, где разместить конструкции кода: это о том, как получить глубокие знания о внутренней работе различных компонентов, которые уже существуют. Вы знаете, как работают менеджеры памяти? Виртуальный пейджинг? Можете реализовать это самостоятельно? Как насчет двусвязных списков? Классов динамических массивов? ODBC-клиента? Можете написать графический пользовательский интерфейс, который бы работал так же, как один из популярных, известных вам? Можете создать свой собственный виджет для браузера? Знаете, как «на лету» выбрать между записью в постоянную БД или в БД в памяти?
Большинство разработчиков просто никогда сами не создавали такие типы основных программных реализаций и поэтому не имеют глубоких знаний о том, как они функционируют. Как следствие, все эти виды программного обеспечения рассматриваются как загадочные чёрные ящики, которые просто работают. Только поверхностного понимания недостаточно, чтобы выявить скрытые в глубине опасности. Незнание более глубоких вещей в разработке программного обеспечения ограничит вашу способность создавать блестящие продукты.
Изобретать велосипед и ошибаться гораздо важнее, чем делать всё правильно с первого раза. Уроки, извлечённые из проб и ошибок, содержат эмоциональную составляющую, которую невозможно получить при чтении технической книги!
Изученные факты и «книжные навыки» имеют решающее значение. Но для того, чтобы стать отличным программистом, приобретённый опыт не менее важен, чем полученные знания. Изобретать велосипед так же важно для образования и навыков разработчика, как тяжелая атлетика важна для бодибилдера.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Jason P. Sage
День восемьсот восемьдесят третий. #DesignPatterns #Microservices
Микросервисная Архитектура и Паттерны Проектирования
Существует множество определений микросервисной архитектуры. Вот одно из них:
Микросервисная архитектура представляет собой вертикальное разделение больших сложных систем (по функциональным или бизнес-требованиям) на более мелкие подсистемы, которые являются отдельными процессами (следовательно, могут развёртываться независимо), и эти подсистемы взаимодействуют друг с другом через лёгкие, не зависящие от языка сетевые вызовы либо синхронным (например, через REST, gRPC) или асинхронным (через обмен сообщениями) способом.
Компонентное представление бизнес-веб-приложения с микросервисной архитектурой представлено на рисунке ниже.
Характеристики:
- Всё приложение разделено на отдельные процессы, каждый из которых может содержать несколько внутренних модулей.
- В отличие от модульных монолитов или сервисно-ориентированной архитектуры, микросервисное приложение разделено по вертикали (в соответствии с бизнес-потребностями или доменами).
- Границы микросервисов внешние, то есть микросервисы взаимодействуют друг с другом через сетевые вызовы (RPC или сообщения).
- Поскольку микросервисы являются независимыми процессами, их можно развёртывать независимо.
- Они общаются легко и не нуждаются в каком-то хитром канале связи.
Преимущества:
- Лучшее масштабирование разработки.
- Более высокая скорость разработки.
- Поддерживается итеративная или инкрементная модернизация.
- Возможность использовать преимущества современной экосистемы разработки ПО (облако, контейнеры, DevOps, бессерверная среда).
- Поддерживается как горизонтальное, так и гранулярное масштабирование (возможность масштабировать отдельные микросервисы).
- Благодаря меньшему размеру, снижается нагрузка на разработчиков, которым не приходится держать в голове большую систему.
Недостатки:
- Большее количество элементов (сервисы, базы данных, процессы, контейнеры, фреймворки).
- Сложность переходит от кода к инфраструктуре.
- Большее количество вызовов RPC и сетевого трафика.
- Управление безопасностью всей системы является сложной задачей.
- Проектировать всю систему сложнее.
- Возникают сложности распределённых систем.
Варианты использования:
- Разработка веб-приложений.
- Разработка корпоративных приложений, когда над приложением работают несколько команд.
- В случаях, когда долгосрочный эффект предпочтительнее краткосрочного.
- В команде есть архитекторы ПО, способные разработать микросервисную архитектуру.
Источник: https://towardsdatascience.com/microservice-architecture-and-its-10-most-important-design-patterns-824952d7fa41
Микросервисная Архитектура и Паттерны Проектирования
Существует множество определений микросервисной архитектуры. Вот одно из них:
Микросервисная архитектура представляет собой вертикальное разделение больших сложных систем (по функциональным или бизнес-требованиям) на более мелкие подсистемы, которые являются отдельными процессами (следовательно, могут развёртываться независимо), и эти подсистемы взаимодействуют друг с другом через лёгкие, не зависящие от языка сетевые вызовы либо синхронным (например, через REST, gRPC) или асинхронным (через обмен сообщениями) способом.
Компонентное представление бизнес-веб-приложения с микросервисной архитектурой представлено на рисунке ниже.
Характеристики:
- Всё приложение разделено на отдельные процессы, каждый из которых может содержать несколько внутренних модулей.
- В отличие от модульных монолитов или сервисно-ориентированной архитектуры, микросервисное приложение разделено по вертикали (в соответствии с бизнес-потребностями или доменами).
- Границы микросервисов внешние, то есть микросервисы взаимодействуют друг с другом через сетевые вызовы (RPC или сообщения).
- Поскольку микросервисы являются независимыми процессами, их можно развёртывать независимо.
- Они общаются легко и не нуждаются в каком-то хитром канале связи.
Преимущества:
- Лучшее масштабирование разработки.
- Более высокая скорость разработки.
- Поддерживается итеративная или инкрементная модернизация.
- Возможность использовать преимущества современной экосистемы разработки ПО (облако, контейнеры, DevOps, бессерверная среда).
- Поддерживается как горизонтальное, так и гранулярное масштабирование (возможность масштабировать отдельные микросервисы).
- Благодаря меньшему размеру, снижается нагрузка на разработчиков, которым не приходится держать в голове большую систему.
Недостатки:
- Большее количество элементов (сервисы, базы данных, процессы, контейнеры, фреймворки).
- Сложность переходит от кода к инфраструктуре.
- Большее количество вызовов RPC и сетевого трафика.
- Управление безопасностью всей системы является сложной задачей.
- Проектировать всю систему сложнее.
- Возникают сложности распределённых систем.
Варианты использования:
- Разработка веб-приложений.
- Разработка корпоративных приложений, когда над приложением работают несколько команд.
- В случаях, когда долгосрочный эффект предпочтительнее краткосрочного.
- В команде есть архитекторы ПО, способные разработать микросервисную архитектуру.
Источник: https://towardsdatascience.com/microservice-architecture-and-its-10-most-important-design-patterns-824952d7fa41
👍1
День восемьсот восемьдесят четвёртый. #DesignPatterns #Microservices
Паттерны в Микросервисах
1. База Данных на Микросервис
Когда компания заменяет большую монолитную систему множеством мелких микросервисов, самое важное решение, с которым она сталкивается, - это база данных. В монолитной архитектуре используется большая централизованная база данных. Многие архитекторы предпочитают сохранять базу данных как есть, даже при переходе на микросервисную архитектуру. Хотя это даёт некоторую краткосрочную выгоду, это анти-шаблон, особенно в крупной системе, поскольку микросервисы будут тесно связаны на уровне базы данных. Весь смысл перехода на микросервисы (расширение возможностей команды, независимая разработка) потеряется.
Лучший подход - предоставить каждому микросервису собственное хранилище данных, чтобы не было сильной связи между службами на уровне базы данных (см. рисунок ниже). Здесь термин «база данных» используется, чтобы показать логическое разделение данных, то есть микросервисы могут совместно использовать одну и ту же физическую базу данных, но они должны использовать отдельную схему/коллекцию/таблицу. Это также гарантирует, что микросервисы правильно разделены в соответствии с предметно-ориентированным проектированием (DDD).
Плюсы
- Полное владение данными для каждого сервиса.
- Слабая связь между командами, разрабатывающими сервисы.
Минусы
- Обмен данными между службами становится проблематичным.
- Предоставление транзакционной гарантии ACID для приложения становится намного сложнее.
- Разделение монолитной базы данных на более мелкие части требует тщательного проектирования и является сложной задачей.
Когда использовать:
- В крупномасштабных корпоративных приложениях.
- Когда команде необходимо полное владение своими микросервисами для масштабирования и скорости разработки.
Когда не использовать:
- В небольших приложениях.
- Если одна команда разработает все микросервисы.
Поддержка
Все базы данных SQL и NoSQL предлагают логическое разделение данных (например, отдельные таблицы, коллекции, схемы, базы данных).
Подробнее:
- Microservices Pattern: Database per service
- Распределённые данные
Источник: https://towardsdatascience.com/microservice-architecture-and-its-10-most-important-design-patterns-824952d7fa41
Паттерны в Микросервисах
1. База Данных на Микросервис
Когда компания заменяет большую монолитную систему множеством мелких микросервисов, самое важное решение, с которым она сталкивается, - это база данных. В монолитной архитектуре используется большая централизованная база данных. Многие архитекторы предпочитают сохранять базу данных как есть, даже при переходе на микросервисную архитектуру. Хотя это даёт некоторую краткосрочную выгоду, это анти-шаблон, особенно в крупной системе, поскольку микросервисы будут тесно связаны на уровне базы данных. Весь смысл перехода на микросервисы (расширение возможностей команды, независимая разработка) потеряется.
Лучший подход - предоставить каждому микросервису собственное хранилище данных, чтобы не было сильной связи между службами на уровне базы данных (см. рисунок ниже). Здесь термин «база данных» используется, чтобы показать логическое разделение данных, то есть микросервисы могут совместно использовать одну и ту же физическую базу данных, но они должны использовать отдельную схему/коллекцию/таблицу. Это также гарантирует, что микросервисы правильно разделены в соответствии с предметно-ориентированным проектированием (DDD).
Плюсы
- Полное владение данными для каждого сервиса.
- Слабая связь между командами, разрабатывающими сервисы.
Минусы
- Обмен данными между службами становится проблематичным.
- Предоставление транзакционной гарантии ACID для приложения становится намного сложнее.
- Разделение монолитной базы данных на более мелкие части требует тщательного проектирования и является сложной задачей.
Когда использовать:
- В крупномасштабных корпоративных приложениях.
- Когда команде необходимо полное владение своими микросервисами для масштабирования и скорости разработки.
Когда не использовать:
- В небольших приложениях.
- Если одна команда разработает все микросервисы.
Поддержка
Все базы данных SQL и NoSQL предлагают логическое разделение данных (например, отдельные таблицы, коллекции, схемы, базы данных).
Подробнее:
- Microservices Pattern: Database per service
- Распределённые данные
Источник: https://towardsdatascience.com/microservice-architecture-and-its-10-most-important-design-patterns-824952d7fa41