«Щоб не писати код з нуля». Навіщо розробникам 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.