Що під капотом в Uklon? Слухай TechPower Podcast 🎧

«Чтобы не писать код с нуля». Зачем разработчикам MEF.DEV?

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

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

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

Что такое MEF.DEV? Сложная версия

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

Действительно сложно. Давайте проще — зачем нужна платформа?

Главная задача платформы — ускорить процесс разработки.

Окей, а за счет чего это происходит?

Начнем с того, что над одним проектом одновременно работает несколько команд разработчиков. Это помогает решить больше задач за меньший срок. 

Разве никто так больше не делает?

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

Платформа дает стандартизированный подход, начиная с проектирования и заканчивая его реальным использованием. 

Что это за подход?

Все разработчики пишут слабо связанный код (это позволяет различным компонентам соединяться между собой).

А что значит слабо связанный код?

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

Если бы код был сильно связан, то пришлось бы остальные компоненты тоже менять.

Давайте дальше, что код делает? 

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

Например, кто-то делает билды раз в две недели, кто-то раз в месяц, а кто-то — каждый день. Тут команды «отвязаны» друг от друга. Каждая живет так, как нравится ей. Но все они делают один общий продукт. 

То есть, они вообще не зависят друг от друга?

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

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

Образно говоря, конкретная версия слабо связанного кода — это некий контейнер бизнес-логики.

А напомните, что такое бизнес-логика?

Это совокупность правил, принципов, зависимостей поведения объектов предметной области. Она задает правила, которым подчиняются данные этой области.

И что же дальше?

Все команды могут специализироваться в разных конкретных областях.  

Возьмем пример из практики MEF.DEV. Их команда специализировалась на системе биллинга. Они эксперты в этом, а их заказчик (мобильный оператор) — знает, как продавать услуги связи.

Чтобы разработчики понимали друг друга, в MEF.DEV пришли к тому, что сначала все проектирование делается на основе domain-driven design. Это набор правил, которые позволяют принимать правильные проектные решения. Он помогает ускорить процесс проектирования программного обеспечения в незнакомой предметной области.

И как это работает?

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

Вернемся к упомянутому кейсу. Например, в MEF.DEV написали кубик, который совершает расчет абонплаты. А другие системы мобильного оператора не проводят повторный расчет, а используют ее значение. Задача — сделать так, чтобы ее списали с банковской карточки. Каждый делает свою работу.  

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

А как команды взаимодействуют между собой? 

Обычно команды тратят много времени на взаимодействие. Например, проводят различные митинги и коллы. Уточняют для себя множество вопросов: какая у кого спецификация и типизация, просят новые версии, спрашивают, какие значения может принимать тот или иной параметр. Чтобы избавиться от этого, в MEF.DEV придумали интерфейс взаимодействия.  

Обычно каждая команда придумывает свой. Кто-то пишет его в Microsoft Word, кто-то в HTML, а кто-то вообще просто на бумажке.  

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

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

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

А что еще платформа может генерировать автоматически? 

Для платформы решили генерировать автоматически все, что можно сделать. Это нужно для того, чтобы не писать код с нуля. Чтобы сгенерировать код, нужна модель. В виде конкретной модели можно описать сущности и экшены, которые делает каждая команда. 

Команды пишут модели, на их основе генерируют проекты и их развивают.

А как это помогает разработчикам?

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

Все остальные сервисные вещи (подход к стандартизации, протоколирование, взаимодействие с другими системами, интеграционные точки) — стандартизированные, ведь их дает платформа MEF.DEV.

А где узнать больше о MEF.DEV?

На сайте платформы MEF.DEV. Также команда делится информацией в собственном блоге, а кейсами — на Хабре и в специализированной группе инженеров на LinkedIn

Новий випуск «З фронту в IT» про айтівців, які повертаються до цивільного життя після ЗСУ.

Історія світчера з Тернопільщини, який змінив агро на IT, а IT на ЗСУ

Хотите сообщить важную новость? Пишите в Telegram-бот

Главные события и полезные ссылки в нашем Telegram-канале

Обсуждение
Комментариев пока нет.