Да, я об этом и говорю! А если low-code платформы нет, то пишем её сами. Это не настолько космическая задача, как принято думать. Пресловутый Lombok - это тот же low-code, но на минималках. Spring Boot и Hibernate - то же low-code. Ещё можно придумать свои аннотации, хотя в том же C# это развито на много больше. А Lisp/Scheme - это один сплошной low-code, там просто размыта грань между написанием кода и его генерацией (благодаря макросам).

Например, документацию из комментариев в коде. Или Swagger генерит UI для доступа к API.

Либо конечной точкой, описали схему данных и сгенерили из неё всё остальное: Java-код, Word-документ и т.п.

Это конечно какая-то жесть и на практике наверное нет смысл делать такое. Но возможен такой сценарий. Нарисовали схему данных, сгенерили из неё Word-документ, отправили на согласование заказчику, предметным специалистам и т.д. Они что-то поправили в документе, синхронизируем эти изменения обратно в модель. Можно в другую модель (не в исходную), а затем аналитик уже в удобном для него инструменте моделирования сравнивает две модели, смотрит что изменилось, мержит изменения в основную версию. Затем итерации повторяются. В итоге из модели генерятся окончательные версии документов и код. Поскольку источник один, то это гарантия того, что документы, код, какие-нибудь XML-схемы и т.п. не разойдутся между собой. У нас в некоторых проектах работа была ровно так организована за исключением конечно автоматического перегона документа обратно в модель, это проще сделать аналитику вручную, хотя если бы делалось автоматически, то экономило бы кучу времени.

Ещё как вариант можно использовать не обязательно Word. А какие-то языки разметки или DSL, но прикрутить к ним WYSIWYG редактор. Похоже всё уже придумано, я описываю JetBrains MPS :) хотя сам им не пользовался

Если код можно написать за один день или даже месяц, то всё это нафиг не нужно. Конечно, проще нажать две кнопки в IDE и сгенерить эти злосчастные геттеры/сеттеры. Наверное, да, у меня немного деформация. Есть смысл это использовать, когда на написание и отладку кода уйдет скажем год. И можно потратить месяц на создания кодогенератора, это всяко более интеллектуальное занятие. Я просто реально уже давно другими проектами не занимаюсь. И у нас люди вечно начинают писать тонны какого-то boilerplate-кода, а я это автоматизирую, чтобы как можно больше всего этого переехало из каталога src в src-gen.

Что может быть не оптимальным в Entity или DTO классах? Или в мепперах между Entity и DTO? В каких-нибудь CRUD-контроллерах? Речь же не идёт о генерации каких-то сложных алгоритмов. Самое сложное, что я генерил: правила валидации документов, описанные на одном DSL (язык OCL), преобразовывал в XPath и Java код. При этом там делалась куча всяких оптимизаций, автоматически генерился не только код для валидации, но и для определения пути к невалидному элементу и т.п. В данном случае пользователь - это предметный специалист, на Java он не напишет вообще никакую реализацию, тем более оптимальную. К тому же на DSL у него правило валидации занимает одну строку, а на Java там генерится строк 50-100 boilerplate-кода.

Встречный вопрос :) Как вы пишите SQL запросы? Вдруг СУБД выполнит их не оптимально? Наверное лучше напрямую доставать данные из базы через какое-нибудь API или сделать свою СУБД. Вы пишите одну строку SQL, а внутри там происходит куча операций, где гарантия, что во всех этих тоннах кода программист не допустил ошибку? Где гарантия, что СУБД правильно поняла ваш запрос? Вдруг вы имели в виду другое? Где гарантия, что по вашим JavaDoc комментариям сгенерилась корректная и оптимальная документация? Где гарантия, что вы описали API с помощью Swagger и для вас сгенерился правильный boilerplate-код или правильный UI? Где гарантия, что ваш gradle скрипт работает правильно? DSL, генераторы разных вещей из кода или из моделей используются просто повсеместно.

Насчет корректности сгенеренного кода, да, конечно я озадачивался этим вопросом. Гарантируется это очень просто. Если тупо, то тестированием. Протестировать генератор можно один раз, это на порядок проще, чем писать кучу новых тестов для однотипного кода, который писался бы вручную. Более правильный вариант это 1) формально описать семантику исходного языка 2) описать семантику результирующего языка 3) формально описать преобразование выражений из одного языка в другой 4) доказать что это преобразование сохраняет семантику. Всё это стоит примерно в тыщу раз дороже, чем написание кодогенераторов или преобразований моделей. Меня хватило только частично на 1-ый пункт . Но дело не в кодогенерации, в принципе формальная верификация любого софта - это очень долго дорого. Для бедных есть тестирование.

Уже есть DevExpress XAF, там формочки, менюшки и т.п. описываются в модели. Достаточно описать схему данных, всё остальное получается практически автоматически. Правда, есть какая-то доля нетиповой функциональности, которую приходится реализовывать вручную и на неё обычно и уходит больше всего времени. На XAF уже сделана ERP Галактика. VIPRos тут ещё где-то был, идея абсолютно та же самая.

Для Java с этим сложнее. В основном наверное используют Eclipse. Ecore-модели и всякие кодогенераторы там очень давно. 1С: EDT сделана на Eclipse, я никогда ей не пользовался, но на сколько я понимаю конфигурации там создаются в виде Ecore-моделей, а этот их русскоязычный DSL реализован Xtext, но это всё не точно.

Он нужен для заказчиков, бизнес-пользователей. Уж, лучше его сгенерить по нужному шаблону (или ГОСТу), чем аналитики будут делать это вручную. А если в word что-то поправили, то, да, наверное проще чтобы аналитик это перенес в модель вручную.

Да, в этом и смысл. OCL - это как-раз скорее язык спецификации, чем программирования. В основном в нём обращения к свойствам/полям объектов, логические предикаты, минимальный набор операций (арифметических, строковых) и т.п. И больше ничего, нет операций изменения, вывода в консоль и т.п. Есть SQL для реляционных моделей, XPath/XQuery для XML и есть OCL для объектных моделей.

Никанор Кузьмич,

генератор из OCL в XPath/Java писался не для разработчиков, а для аналитиков. Они вообще не знают, что там есть какой-то генератор, они просто пишут спецификации правил. Раньше они писали их на русском языке, в части правил вообще невозможно было понять, что имеется в виду, их можно было интерпретировать как угодно. Эти правила отдавались системным аналитикам, которые во всём этом разбирались и писали чуть более детальную постановку разработчику. Разработчик во всём этом находил ещё кучу неоднозначностей или реализовывал как считал правильным. Затем всё это тестировалось. Причём протестировать задача не из простых. Представьте документ с 300 полями и 1000 правил валидации эти полей из разряда "если в таком-то поле указано то-то, то сумма таких-то полей должна быть такой-то". Сколько тестов нужно написать, чтобы всё это проверить? А это только один документ из десятков. Плюс правила постоянно меняются.

Когда предметные специалисты стали писать правила не на русском языке, а на формальном (на самом деле конечно они не сами их писали, а с помощью обученных системных аналитиков), то все эти этапы (интерпретация правил на русском языке, реализация их в коде, тестирование) просто потеряли актуальность. Затрачиваемое время уменьшается на порядок.

Конечно генератор может работать неправильно, но протестировать его проще, чем постоянно тестировать эти тыщи правил.

Конечно аналитики могут написать неправильную спецификацию правила и тогда для неё сгенерится неправильный код. Но вероятность того, что они напишут неправильное правило на русском языке и что его неправильно поймут и реализуют существенно выше.

Поскольку эти правила описаны на формальном языке (а не на русском языке и не в коде), то мы можем автоматически сгенерить тесты по спецификациям правил. Можем автоматически проверить правила на противоречивость (например, два правила одновременно соблюдаться никак не могут), на избыточность, ... Правда мы этого не делали :) но возможность есть. В принципе, для Java кода есть всякие статические анализаторы, генераторы тестов. А для очень ограниченного DSL эти вещи делать гораздо проще, чем для ЯП общего назначения.

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

Насчет того, чтобы запустить код и посмотреть как он работает. 1) Раньше они просто писали правила на русском языке, эти правила могли быть вообще бессмысленными, ссылаться на несуществующие поля документа. То что они пишутся на формальном языке и валидируются в соответствии со структурой документа - это уже огромный шаг. 2) Если они их как-то формулировали на русском языке, то могут как-то сформулировать и на формальном. Математики же как-то пишут формулы не запуская их :) OCL - это по сути тот же язык формальной логики (переменные, предикаты). 3) Вообще, запустить и посмотреть это полезная функциональность, мы её не делали, но можно было бы сделать. Точнее правила нельзя было запускать в процессе написания. Но можно их написать, нажать кнопку генерации, загрузить тестовый документ и получить детальный HTML-отчет о валидации с возможность кликнуть на ошибку, увидеть элемент документа, для которого найдена ошибка. Увидеть какие правила успешно отработали и т.п. Ну т.е. запускать правила можно. Если что-то идёт не так, то либо правило написано неправильно, либо нужно поправить генератор.


Насчёт кодогенерации для разработчиков, а не аналитиков. Здесь история та же. На чаше весов: 1) потратить на этот проект 10 лет или 2) сделать его за год с кодогенераторами. Если в проекте возникает куча однотипного кода, то есть два способа с этим справиться:

1) Можно вынести какие-то вещи в конфиги, в аннотации. Написать интерпретатор для всего этого и в рантайме как-то обрабатывать. В определенном пространстве имен находим классы с определенными аннотациями, ищем в них методы с определенными аннотациями, ищем ещё что-то, что-то со всем этим делаем.

2) Другой вариант делать то же самое, но в design-time.

Для конкретики банальный пример. Есть много разных object mapper'ов. Их можно разделить на две категории: 1) те которые конфигурируются с помощью аннотаций, билдеров и т.п., в рантайме ищут у объектов атрибуты с одинаковыми названиями 2) те которые основаны на кодогенерации.

Как-раз 1-ый вариант обычно работает медленнее, потому что очевидно есть накладные расходы. И самое главное, чтобы понять работают они или нет их нужно запустить! Фиг знает, что там вообще происходит. А если для мепперов код сгенерен, то я просто смотрю этот код и сразу вижу что не так. И, вообще, почему вы считаете, что сгенеренный код - это что-то обязательно непонятное? У нас генерится ровно такой код (с форматированием и комментариями!), который мы написали бы вручную. Мне просто лень писать однотипный код, но если бы я его писал или если бы его писали джуны, то он был бы точно таким же с точностью до пробелов.

PetroNotC Sharp,

насчет оверхеда сложный вопрос. Наверное в большинстве проектов возникает какая-то рутина в разработке. Я очень ленивый человек, писать два раза аналогичный код мне очень лень. Как только такое возникает я сразу же ищу варианты автоматизации. Если кодогенератор на 10 строк сгенерит мне 1000 строк, то какой тут оверхед. Если с нуля во всё это погружаться, то наверное, да, нужно кучу всего прочитать, попробовать кучу разных инструментов, написать кучу этих генераторов.

Чтобы показать насколько я ленивый. У нас есть конструктор инструментов моделирования, в котором можно добавляться новые нотации. Начнём с того, что в большинстве инструментов либо хрен добавишь новую нотацию моделирования, они жёстко зашиты в коде, либо в модели можно добавлять новые значки, но модели просто на уровне картинок, их потом дальше невозможно анализировать. У нас не так, каждая нотация - это полноценный язык моделирования. Отдельно описывается 1) семантическая составляющая моделей (типы объектов, типы связей, атрибуты), 2) отдельно визуальная составляющая (какие значки должны быть на диаграммах, какая палитра инструментов, что должно происходить при создании объектов, при удалении, при переприсоединении связей, какие формы свойств должны быть - короче полностью описывается редактор диаграмм со всем операциями над моделями). И 1, и 2 у нас описаны в виде моделей. Методолог может просто накликать всё это мышкой, в том числе достаточно сложные вещи (просто добавление объектов в модель, добавление объектов из справочника с помощью диалога, всякие правила валидации - что обычно реализуется в коде). Но мне на столько лень делать даже это, что написал генератор этих спецификаций редакторов диаграмм из метамоделей. И конечно это экономит кучу времени. Лень файлы локализации писать, лень типовой Java-код писать, лень документацию писать. Наверное это единственное, что движет мной в работе :)