Прекрасно понимаю, что общий опыт скорее негативный, потому и пишу про все это, чтобы показать, что подход может использоваться и во благо и приносить ощутимую пользу.
В генерацию переносится код, который ни писать руками, ни тем более рефакторить никто не собирается, код, который генерируется должен быть понятным и делать конкретные вещи,
в этом смысле магии становится меньше, а не больше, ведь мы не прячем суть за кучей прокси и чего-то еще, что появляется вдруг в рантайме.
Если генератор для себя пишете вы сами, а я пытаюсь показать, что это не так уж и сложно, то вы сами контролируете ситуацию и с тем, как методы называются и как работают.
Рефакторинг и даже багфиксинг в этом случае выглядит немного по другому — вы сначала правите код генератора, проверяете все на тестах, а дальше прикладной код меняется везде,
где этот генератор используется при этом у вас куда больше возможностей, чем просто поиск и замена.
В качетве бонуса, примерно так же происходит миграция на новые версии библиотек и фреймворков, которые в нашем коде используются — смотрим, что поменялось, фиксируем эти изменения в одном месте,
а потом скоупом переезжаем — это куда приятнее и продуктивнее, чем поменяв версию зависимости сначала править ошибки компиляции, а потом и все остальные.
Спасибо за развернутый комментарий. Пример в статье лишь для того, чтобы продемонстрировать возможности и конечно его можно расширять с дополнять,
вооружившись пониманием, как все работает на базовом уровне.
В нашем случае, по коду модели генерируется и слой хранения и DTO и код модели на клиенте и ресурсы,
таким образом все это остается консистентным и изменения разработчику надо вносить в одном конкретном месте.
В рамках кодогенерации мы практически никогда не говорим про один конкретный класс, речь идет про типовой код, которого может быть достаточно много,
он должен породжаться по каким-то условиям и который не хочется повторять.
Механика здесь примерно такая — сначала код пишется руками, мы видим закономерность, после пары повторений переносим его в генератор и профит.
Например, нам нужны константы для всех полей сущности с именами, чтобы дальше по коду на них ссылаться при определении отношений, классно же,
если такой код будет генерироваться и оставаться всегда актуальным. Или какие-то простенькие скрипты миграции, мы добавили поле, а у нас уже есть нужный alter table.
Соглашусь, что все бывает непросто. Для себя мы из положения вышли — есть собственный плагин для IDEA с поддержкой DSL на Xtend для описания модели, который показан в статье и watcher, который инкрементально запускает генерацию Java кода по ней. Страдания прикладных разработчиков сведены к минимуму: кода писать меньше и обратная связь моментально практически, без полной сборки и запуска этого всего. А команда, которая поддерживает генератор от использования Eclipse и не страдает. )
Слайд правильный - с контактами. ) Рейтинг выступлений - твой личный, а встреча точно была крутой, приятно вспомнить.
Прекрасно понимаю, что общий опыт скорее негативный, потому и пишу про все это, чтобы показать, что подход может использоваться и во благо и приносить ощутимую пользу.
В генерацию переносится код, который ни писать руками, ни тем более рефакторить никто не собирается, код, который генерируется должен быть понятным и делать конкретные вещи,
в этом смысле магии становится меньше, а не больше, ведь мы не прячем суть за кучей прокси и чего-то еще, что появляется вдруг в рантайме.
Если генератор для себя пишете вы сами, а я пытаюсь показать, что это не так уж и сложно, то вы сами контролируете ситуацию и с тем, как методы называются и как работают.
Рефакторинг и даже багфиксинг в этом случае выглядит немного по другому — вы сначала правите код генератора, проверяете все на тестах, а дальше прикладной код меняется везде,
где этот генератор используется при этом у вас куда больше возможностей, чем просто поиск и замена.
В качетве бонуса, примерно так же происходит миграция на новые версии библиотек и фреймворков, которые в нашем коде используются — смотрим, что поменялось, фиксируем эти изменения в одном месте,
а потом скоупом переезжаем — это куда приятнее и продуктивнее, чем поменяв версию зависимости сначала править ошибки компиляции, а потом и все остальные.
Спасибо за развернутый комментарий. Пример в статье лишь для того, чтобы продемонстрировать возможности и конечно его можно расширять с дополнять,
вооружившись пониманием, как все работает на базовом уровне.
В нашем случае, по коду модели генерируется и слой хранения и DTO и код модели на клиенте и ресурсы,
таким образом все это остается консистентным и изменения разработчику надо вносить в одном конкретном месте.
В рамках кодогенерации мы практически никогда не говорим про один конкретный класс, речь идет про типовой код, которого может быть достаточно много,
он должен породжаться по каким-то условиям и который не хочется повторять.
Механика здесь примерно такая — сначала код пишется руками, мы видим закономерность, после пары повторений переносим его в генератор и профит.
Например, нам нужны константы для всех полей сущности с именами, чтобы дальше по коду на них ссылаться при определении отношений, классно же,
если такой код будет генерироваться и оставаться всегда актуальным. Или какие-то простенькие скрипты миграции, мы добавили поле, а у нас уже есть нужный alter table.
Видео со встречи — youtu.be/ypLoO49TLjI