Ruby, Punch Code Generator. Інструмент для розробки бізнес-логіки

Привіт,

Створив інтрумент для розробки бізнес-логіки згідно з принципами The Clean Architecture. Поки тестую на невеликих доменах та на мій погляд вийшло доволі добре, так що вирішив поділитися зі спільнотою. Якщо хто зацікавився — запрошую до github.com/nvoynov/punch

Декілька днів тому зібрав трохи статистики на простому домені керування користувачами, та вийшло що цей інструмент може зекономити до половини всіх зусиль на створення бізнес-логіки. Більше дивиться github.com/...​nch/blob/master/README.md

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

В документації отут зайвий пробіл:
Punch goes a bit further than just a source code generator for services an d entities and provides DSL for describing domains of those things.

В 80х-90х була мода на кодогенератори, але потім виявилося, що їх нереально дебажити.

1) Себто, поки усе працює як слід — ок, а коли ні — то доводиться лізти в нагенерований код, котрого ніхто не знає.

2) От маєте автогенерований код. В ньому вже внесено модифікації — написали щось в call(), десь якусь специфіку в конструктори, тощо. І тут з’являється нове розуміння чи потреби в домені. Що робити? Перегенерувати файли — то пропадуть рукописні зміни. Забити на автогенератор, і писати нове руками — то навіщо тоді той генератор був потрібен, бо ж реальні проекти часто роками живуть та модифікуються, а не пишуться за вечір.

3) Clean Architecture не є стандартом індустрії — весь час з’являються нові підходи, та перевинаходять старі. Наприклад, ось історія уявлень про архітектуру, де цей підхід є лише одним з нещодавніх щаблів herbertograca.com/...​-architecture-chronicles

4) Clean Architecture як підтип гексагоналки має певні проблеми:
* Вона не масштабується під великі проекти, бо усе в одному репозиторії, і синхронно взаємодіє. Тому спочатку робили SOA, потім — мікросервіси, потім — усякі Cell-Based Architecture.
* В гексагоналці уся логіка має однакові нефункціональні властивості (наприклад, швидкодію, час відгуку, мову програмування, швідкість змін коду, тип тестування). В багатьох випадках потрібно інше — наприклад, CQRS виходить з того, що записи транзакцій до бази та аналітика — це геть різні програми з протилежними властивостями. Таке не лягає на Clean Architecture.

Ідея цікава, може спрацювати, якщо її розрекламувати десь на форумах рубістів та залучити ентузіастів звідти до розробки. Але буде мати обмежене використання — імовірно, для одноразових проектів, що не потребують підтримки чи розвитку.

Наскільки усе складно з доменами — можна почитати в класичній книзі Eric Evans 2003 — Domain-Driven Design — Tackling Complexity in the Heart of Software. Вони там переписували великий шматок домену десь через рік роботи, коли зрозуміли деталі. От автогенератор такого не дозволить.

Сподіваюся, знайдете якісь цікаві думки в цьому дописі.
Ще приєднуйтесь до групи t.me/swarchua там може хтось щось інше підкаже, коли запропонуєте обговорення.

Денис. дякую за розлугий коментар!

> 2) От маєте автогенерований код. В ньому вже внесено модифікації — написали щось в call()

Я розглядаю свій генератор як генератор скелетів для окремого слою бізнес-логіки, без будь-яких залежностей від інших слоїв аплікації. Тобто для повноцінної аплікації йому ще треба зробити фейс та реалізацію плагінів. Реальний код бізнес-логіки треба створювати руцями, але вже завдяки генерації можна позбутися багатого шматка дурної роботи. Також останній тиждень показав що далі маючи домен можна генерувати адаптери до сервісів, скелети аплікацій ... вчора згенерував шматок SRS :) Це тільки помічник — твірцем є програміст що його використовує во благо

> 4) Clean Architecture як підтип гексагоналки має певні проблеми:

Мій інтерес дещо простіший ніж великі проекти, я хочу мікросервісів та очкую помірний об’єм функціональності — пара акторів, деясток сутностей, пара десятков фічерів/сервісів. Зробив невеличкий приклад керування замовленнями н два актори, дві сутності та десятко сервісів, дав йому dRuby, Rack, RabbitMQ інтерфейси — все ну дуже схоже.

> Сподіваюся, знайдете якісь цікаві думки в цьому дописі.
Ще приєднуйтесь до групи t.me/swarchua

Шіро дякую!

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

Скільки чого треба стільки й генеруємо, генератор двиться чи був змінений сгенерований контент, якщо ні — файл замінюється на новий, робиться бекап у у filename~.

Ніяких інших обмежень не бачу — він нічного не ламає. Можно як через DSL, можна руцями — логіка та сама.

Підписатись на коментарі