Комментарии 10
Даже хороший «монолитчик» с большим стажем, который всю жизнь делает монолиты и даже слышал что-то про 12 факторовПримерно то же, как сказать
Даже хороший «монолитчик» с большим стажем, который всю жизнь делает монолиты и даже слышал что-то про Linux
«Я как-то видел, когда в команду разработки закинули задачу распилить монолит. И всё. Люди должны были работать в два раза больше – это ужасно».
А если бы им закинули сразу два монолита, то пришлось бы работать в четыре раза больше, а сутки пришлось бы растягивать c 24 до 32 часов. Вот где весь ужас!!
Как я понял, здесь речь ведется о веб разработке, но конкретики мало. Меня лично более интересуют модульное программирование десктопных GUI приложений. Вот про это хотелось бы узнать больше. Но, несмотря на как бы избитую тему, путного в Интернете, как всегда, мало. Хоть бери и пиши сам статью, типа: «Практическое модульное и итерационное программирование на С / С++ под Windows».
Но уже сейчас можно сказать, в чем проблема «распила монолита». Это сильные связи между программными модулями (файлами). А задача состоит не в том, чтобы убрать эти связи, а в том, чтобы унифицировать их.
Обычно это делается с помощью виртуального интерфейса. Реализацию этих интерфейсов можно осуществлять двояко: статически и динамически (в виде бинарных модулей – плагинов). Статические плагины нужны для их отладки, в рамках главного модуля, в первую очередь. А динамические, как минимум, – для доказательства их бинарной независимости. Компиляция того и другого должна быть из одного кода, с помощью условных директив.
Таким образом, процесс модульного проектирования приложения состоит из следующих этапов:
1. Делается минимальное приложение (главный модуль), содержащий в том числе, функции общего назначения.
2. Все расширения и дополнения исходного кода оформляются в виде статических / динамических плагинов и сервисных функций, таких как, выход из программы, закрытие одного либо всех окон, переупорядочивание всех открытых окон и т.п. Как правило, это безоконные функции. Про статические плагины, я нигде не читал, но у себя, практически, использую.
3. Виртуальный интерфейс, к которому имеет доступ главный модуль, должен быть не только у плагинов, но и у главного модуля. Это важное замечание! Ничего подобного, в Интернете, я не видел. Доступ к интерфейсу плагина, главный модуль производит стандартным образом (LoadLibrary / GetProcAddress). А обратный доступ, из плагина к интерфейсу главного модуля, происходит путем передачи соответствующей ссылки из главного модуля плагину, при его инициализации.
Особенно удобно использовать плагины для создания MDI приложения. Скажем, одному окну либо группе окон одного типа, соответствует один плагин. А сами плагины, если они есть, загружаются, допустим, из определенной папки. Причем, плагины могут иметь собственные ресурсы и загружать другие плагины.
У меня уже есть подобное тестовое MDI приложение, содержащее пару оконных плагинов, разного типа (одно из которых работает с множеством одновременно открываемых окон, общего типа).
Но, как я вижу, интересными становятся SDI приложения. Во-первых, SDI приложение можно использовать для независимого тестирования одного плагина (но здесь мы ограничены отсутствием функций общего назначения главного модуля). А, во-вторых, интересное окно, как правило, всегда сложное, которое трудно уместить в один плагин. Проще использовать плагинное проектирование и для одного окна / SDI приложения. Однако я до этого пока в своем демо проекте еще не дошел, как дойду и оттестирую, то сразу можно будет писать соответствующую статью :).
«Грамотный менеджмент» должен основываться на практической теории. А «грамотные менеджеры» ее знают?
Но уже сейчас можно сказать, в чем проблема «распила монолита». Это сильные связи между программными модулями (файлами). А задача состоит не в том, чтобы убрать эти связи, а в том, чтобы унифицировать их.
Обычно это делается с помощью виртуального интерфейса. Реализацию этих интерфейсов можно осуществлять двояко: статически и динамически (в виде бинарных модулей – плагинов). Статические плагины нужны для их отладки, в рамках главного модуля, в первую очередь. А динамические, как минимум, – для доказательства их бинарной независимости. Компиляция того и другого должна быть из одного кода, с помощью условных директив.
Таким образом, процесс модульного проектирования приложения состоит из следующих этапов:
1. Делается минимальное приложение (главный модуль), содержащий в том числе, функции общего назначения.
2. Все расширения и дополнения исходного кода оформляются в виде статических / динамических плагинов и сервисных функций, таких как, выход из программы, закрытие одного либо всех окон, переупорядочивание всех открытых окон и т.п. Как правило, это безоконные функции. Про статические плагины, я нигде не читал, но у себя, практически, использую.
3. Виртуальный интерфейс, к которому имеет доступ главный модуль, должен быть не только у плагинов, но и у главного модуля. Это важное замечание! Ничего подобного, в Интернете, я не видел. Доступ к интерфейсу плагина, главный модуль производит стандартным образом (LoadLibrary / GetProcAddress). А обратный доступ, из плагина к интерфейсу главного модуля, происходит путем передачи соответствующей ссылки из главного модуля плагину, при его инициализации.
Особенно удобно использовать плагины для создания MDI приложения. Скажем, одному окну либо группе окон одного типа, соответствует один плагин. А сами плагины, если они есть, загружаются, допустим, из определенной папки. Причем, плагины могут иметь собственные ресурсы и загружать другие плагины.
У меня уже есть подобное тестовое MDI приложение, содержащее пару оконных плагинов, разного типа (одно из которых работает с множеством одновременно открываемых окон, общего типа).
Но, как я вижу, интересными становятся SDI приложения. Во-первых, SDI приложение можно использовать для независимого тестирования одного плагина (но здесь мы ограничены отсутствием функций общего назначения главного модуля). А, во-вторых, интересное окно, как правило, всегда сложное, которое трудно уместить в один плагин. Проще использовать плагинное проектирование и для одного окна / SDI приложения. Однако я до этого пока в своем демо проекте еще не дошел, как дойду и оттестирую, то сразу можно будет писать соответствующую статью :).
«Успех распила монолита – грамотный менеджмент»
«Грамотный менеджмент» должен основываться на практической теории. А «грамотные менеджеры» ее знают?
Спасибо за полезное дополнение. Уверен, что практическая статья для разработчиков будет очень полезной)
Если говорить про грамотный менеджмент, то речь больше про технический менеджмент и, да согласен, для распила монолита нужен опытный и знающий менеджмент, о чём Марсель и говорил в интервью.
Если говорить про грамотный менеджмент, то речь больше про технический менеджмент и, да согласен, для распила монолита нужен опытный и знающий менеджмент, о чём Марсель и говорил в интервью.
Согласен, дополнительные технические знания специалистам не повредят.
Честно говоря, я с трудом могу себе представить «грамотный технический менеджмент». Обычно, реальные спецы, себя менеджерами не называют. Но спорить не буду, может быть у вас действительно настоящие менеджеры. Вот был как-то фильм про профсоюзных лидеров в Штатах, которые реально боролись за права рабочих. Настолько, что их боялись даже местная мафия и полиция. Но то Америка, им верить опасно… :).
Честно говоря, я с трудом могу себе представить «грамотный технический менеджмент». Обычно, реальные спецы, себя менеджерами не называют. Но спорить не буду, может быть у вас действительно настоящие менеджеры. Вот был как-то фильм про профсоюзных лидеров в Штатах, которые реально боролись за права рабочих. Настолько, что их боялись даже местная мафия и полиция. Но то Америка, им верить опасно… :).
Вот, начал писать на эту тему: «Модульное программирование в C++. Статические и динамические плагины» ( https://habr.com/ru/post/566864/ ).
Инструментарий в данном случае сильно влияет на идеологию и методику разработки.
Даже если desktop приложение собирается с плагинами у вас остатется точка «единого релиза». Для вас нет необходимости поддерживать работоспособность нескольких версий модулей, вы не рассматриваете штаного использования нескольких веток доработок (канареечные релизы) и дешевой проверки гипотез, у вас не будет мониторинга deprecated функционала, не будет версионного API для backend. Вам это просто не нужно.
Этот «джентельментский набор», который идет бонусом в микросервисной архитектуре, у вас сам по себе не появится.
Так же, для системы плагинов имеет место дешевое появление сильных связей, и, дорогие процедуры поддержки использования формализованного интерфейсного взаимодействия. И сам инструментарий архитектурного надзора вам приходится обеспечивать в рамках дополнительных затрат.
А вот при использовании web-платформ даже джуну гораздо проще обеспечить изолированность функционала и использование для взаимодействия только API. Да и архитектурный надзор на 90% выносится на анализ логов доступа к API.
Даже если desktop приложение собирается с плагинами у вас остатется точка «единого релиза». Для вас нет необходимости поддерживать работоспособность нескольких версий модулей, вы не рассматриваете штаного использования нескольких веток доработок (канареечные релизы) и дешевой проверки гипотез, у вас не будет мониторинга deprecated функционала, не будет версионного API для backend. Вам это просто не нужно.
Этот «джентельментский набор», который идет бонусом в микросервисной архитектуре, у вас сам по себе не появится.
Так же, для системы плагинов имеет место дешевое появление сильных связей, и, дорогие процедуры поддержки использования формализованного интерфейсного взаимодействия. И сам инструментарий архитектурного надзора вам приходится обеспечивать в рамках дополнительных затрат.
А вот при использовании web-платформ даже джуну гораздо проще обеспечить изолированность функционала и использование для взаимодействия только API. Да и архитектурный надзор на 90% выносится на анализ логов доступа к API.
Инструментарий в данном случае сильно влияет на идеологию и методику разработки.
Согласен!
Этот «джентельментский набор», который идет бонусом в микросервисной архитектуре, у вас сам по себе не появится.
Не вижу проблем! У меня уже есть служебные сервисные функции, использование их, как и двустороннего интерфейса плагин <-> приложение (главный модуль) достаточно просто и удобно. Не буду спорить, возможно, на уровне моего, относительно простого демо-проекта, все будет хорошо, а в общем случае проблем будет больше. Но какой выход? Веб программирование это не мое, мне это просто не интересно. А стандартных техник плагинного (модульного) программирования я пока в Интернете не нашел.
Так же, для системы плагинов имеет место дешевое появление сильных связей, и, дорогие процедуры поддержки использования формализованного интерфейсного взаимодействия. И сам инструментарий архитектурного надзора вам приходится обеспечивать в рамках дополнительных затрат.
«Сильные связи» это не следствие плагинов, а общая причина «монолитного программирования». «Распил» и означает, как минимум, упрощение этих связей. Плагины их не убирают, но упрощают использование, за счет унификации и стандартизации. Например, все оконные плагины генерируют события, которые должен обрабатывать цикл сообщений главного модуля. Однако можно создать пул интерфейсов, автоматически формируемый для динамических плагинов и вручную определяемый, при статической линковке. В любом случае, этот пул успешно обрабатывается, на автомате, главным циклом сообщений.
Так что никаких «дорогих процедур поддержки использования формализованного интерфейсного взаимодействия» у меня нет. Стандартным образом получаю ссылку на интерфейс, стандартным образом его использую, применяя стандартные виртуальные функции. Да, эти протоколы взаимодействия мне нужно разрабатывать самому, поскольку, хороших примеров у меня нет. А те, что есть, работают, достаточно примитивно и только с консолью.
Главная проблема, пока, просто, руки еще не дошли, это применение нескольких плагинов для одного дочернего окна, либо клиентской области главного окна, типа, сплитеры, MDI-закладки, статусная строка, панель инструментов и т.п.
Что касается меню, то проблемы нет. Приложение у меня, практически, не использует никаких ресурсов, в смысле, rc-файлов. В них прописана всего лишь одна-единственная иконка для exe-файла. Иначе, я не знаю, как, на уровне проекта, задать извне эту иконку. Для внутренних иконок вопросов не возникает, они все грузятся из внешних файлов. Другими словами, я делаю программу, как конструктор. Минимальный ее вариант, кроме пустого окна и единственного пункта меню, для выхода из программы, не содержит ничего. Однако, все ресурсы, иконки, хот-кеи, дополнительные пункты меню, обработчики (сервисные функции), наименования окон, параметры приложения, в т.ч., текстовые блоки, для дочерних окон, фоновые изображения и т.п., все считывается из внешних файлов. Даже окно «О программе» формируется полностью извне. Т.е., мы имеем абсолютный конструктор приложения, с нуля. Замечу, что запись / чтение параметров приложения и его плагинов осуществляется из упрощенного аналога ini-файлов. Код настолько простой, что практически умещается на одном экране, причем работает даже с многострочным текстом. Так что, совсем не обязательно идти «общепризнанным» путем, если свой проще и эффективней.
Каждый плагин у меня, формирует собственный полный путь меню, в собственном конфигурационном ini-файле, вместе с альт-клавишами, обработчиками и хоткеями.
В общем, пока мне все нравится. :)
А вот при использовании web-платформ даже джуну гораздо проще обеспечить изолированность функционала и использование для взаимодействия только API. Да и архитектурный надзор на 90% выносится на анализ логов доступа к API.
Я уже как бы вышел из того возраста, чтобы купиться на подобную рекламу. Поддержка логов у меня подключена на автомате. Очень удобно, когда надо анализировать маршруты событий всех окон.
Водораздел для меня проходит на границе веб / десктоп и ноутбук / настольный компьютер. Первые варианты мне просто не привлекают от слова «совсем». :)
...У меня уже есть служебные сервисные функции...
...«Сильные связи» это не следствие плагинов...
...можно создать пул интерфейсов, автоматически формируемый для динамических плагинов и вручную определяемый, при статической линковке...
Необходимость единой точки сборки. Минус возможность отдельного обновления приложения или плагина без пересбоки всего и вся. И минус возможность разделения по разрабочкикам/вендорам.
...все оконные плагины генерируют события, которые должен обрабатывать цикл сообщений главного модуля...
...Каждый плагин у меня, формирует собственный полный путь меню...
Самый прямой пример сильных связей
...можно создать пул интерфейсов, автоматически формируемый для динамических плагинов...
...никаких «дорогих процедур поддержки использования формализованного интерфейсного взаимодействия» у меня нет...
На текущий момент нет, и на текущий момент это не микросервисы а самый типовой монолит, и ... стоимость/трудоемкость разработки и поддержки таких инструментов крайне неприятно удивит
...«Распил» и означает, как минимум, упрощение этих связей...
Переход на микросервисы приципиально предусматривает не использование таких связей
...мне нужно разрабатывать самому, поскольку, хороших примеров у меня нет...
один из примеров
https://docs.microsoft.com/ru-ru/dotnet/core/tutorials/creating-app-with-plugin-support
...у меня, практически, не использует никаких ресурсов, в смысле, rc-файлов. В них прописана всего лишь одна-единственная иконка для exe-файла. Иначе, я не знаю, как, на уровне проекта, задать извне эту иконку...
для микросервисов это будет звучать иначе
у меня в проекте несколько команд, у каждой свой график разработки и релизов, и каждая команда может сама выбирать язык/платформу, и, может менять язык и платформу от версии к версии
удалено (коментарий добавлен не в ту ветку)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интервью с Марселем Ибраевым о распиле монолита или «Успех распила монолита – грамотный менеджмент»