Генераторы кода плохие?

Question

Я использую MyGeneration вместе с nHibernate для создания основных объектов POCO и файлов сопоставления XML. Я слышал, что некоторые люди считают, что генераторы кода не очень хорошая идея. Каково текущее лучшее мышление? Просто генерация кода плоха, когда генерирует тысячи строк непонятного кода?

Answer 1

Код, сгенерированный генератором кода, не должен (как обобщение) использоваться в ситуации, когда он впоследствии редактируется вмешательством человека. Некоторые системы, такие как мастера в различных воплощениях Visual C ++, генерировали код, который программист должен был отредактировать вручную. Это было непопулярно, так как от разработчиков требовалось разбирать сгенерированный код, понимать его и вносить изменения. Это также означало, что процесс генерации был одним выстрелом.

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

-- =============================================================
-- === Foobar Module ===========================================
-- =============================================================
--
--         === THIS IS GENERATED CODE.  DO NOT EDIT. ===
--
-- =============================================================

Генерация кода в действии - неплохая книга на эту тему.

Answer 2

Генераторы кода отличные, плохой код плохой.

Большинство других ответов на этой странице имеют вид "Нет, потому что часто сгенерированный код не очень хорош."

Это плохой ответ, потому что:

1) Генераторы - это инструмент, как и все остальное - если вы его неправильно используете, не вините инструмент.

2) Разработчики, как правило, гордятся своей способностью писать отличный код один раз, но вы не используете генераторы кода для разовых проектов.

Мы используем систему генерации кода для постоянства во всех наших Java-проектах и ​​имеем тысячи сгенерированных классов в производстве.

Как менеджер я люблю их, потому что:

1) Надежность: в этом коде не осталось значительных ошибок. За прошедшие годы он был настолько исчерпывающе протестирован и усовершенствован, что при отладке я никогда не беспокоюсь о постоянном уровне.

2) Стандартизация: код каждого разработчика идентичен в этом отношении, поэтому парню гораздо меньше нужно учиться при подборе нового проекта у коллеги.

3) Эволюция: если мы найдем лучший способ сделать что-то, мы сможем обновлять шаблоны и быстро и последовательно обновлять 1000 классов.

4) Революция: если в будущем мы переключимся на другую систему персистентности, то тот факт, что каждый постоянный класс имеет абсолютно идентичный API, значительно облегчит мою работу.

5) Производительность. Чтобы создать постоянную объектную систему из метаданных, достаточно нескольких кликов - это экономит тысячи скучных часов для разработчиков.

Генерация кода похожа на использование компилятора - в отдельных случаях вы могли бы написать лучше оптимизированный язык ассемблера, но при большом количестве проектов вы бы предпочли, чтобы компилятор сделал это за вас, верно?

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

Answer 3

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

Одна проблема состоит в том, что если инструмент не позволяет вам защитить изменения, внесенные в измененный код, тогда ваши изменения будут перезаписаны.

Другая проблема, с которой я столкнулся, особенно с генераторами кода в RSA для веб-сервисов, если вы слишком сильно измените сгенерированный код, генератор будет жаловаться на несоответствие и отказываться от регенерации кода. Это может произойти для чего-то столь же простого, как изменение типа переменной. Затем вы застреваете, генерируя код в другом проекте и объединяя результаты обратно в исходный код.

Answer 4

Генераторы кода могут быть благом для производительности, но есть несколько вещей, которые нужно искать:

Позвольте вам работать так, как вы хотите работать.

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

Запуск как часть вашей обычной сборки.

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

Без установки

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

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

Нет редактирования вывода

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

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

Читаемый вывод

Вывод должен быть хорошо написан и отформатирован. Вы хотите иметь возможность открыть вывод и прочитать его без особых проблем.

#line

Многие языки поддерживают что-то вроде директивы #line, которая позволяет отображать содержимое вывода обратно на вход, например, при создании сообщений об ошибках компилятора или при входе в отладчик. Это может быть полезно, но это также может раздражать, если не сделано по-настоящему хорошо, поэтому это не является обязательным требованием.

Answer 5

Моя позиция заключается в том, что генераторы кода неплохие, но их использует МНОГИЕ.

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

Answer 6

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

Answer 7

Компиляторы являются генераторами кода, поэтому они не являются плохими по своей природе, если только вы не любите программировать в необработанном машинном коде.

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

Answer 8

Если это генератор кода Кобола для мэйнфреймов, который Фрэн Таркентон пытается продать вам, тогда, безусловно, да!

Answer 9

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

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

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

Answer 10

Наш текущий проект интенсивно использует генератор кода. Это означает, что я видел как «очевидные» преимущества генерации кода в первый раз - без ошибок кодера, без опечаток, лучшей приверженности стандартному стилю кодирования - и, после нескольких месяцев работы в режиме обслуживания, неожиданные недостатки. Наш генератор кода действительно улучшил качество нашей кодовой базы. Мы убедились, что он полностью автоматизирован и интегрирован с нашими автоматизированными сборками. Однако я бы сказал, что:

(1) Генератором кода может быть костыль. Сейчас в нашей системе есть несколько массивных, уродливых клочков сложного в обслуживании кода, потому что когда-то в прошлом было проще добавить двадцать новых классов в наш XML-файл генерации кода, чем делать надлежащий анализ и класс рефакторинга.

(2) Исключения из правила убивают вас. Мы используем генератор кода для создания нескольких сотен классов Screen и Business Object. Первоначально мы установили стандарт на то, какие методы могут появляться в классе, но, как и все стандарты, мы начали делать исключения. Теперь наш XML-файл генерации кода - это огромный монстр, заполненный особыми фрагментами кода Java, которые вставляются в избранные классы. Почти невозможно разобрать или понять.

(3) Поскольку большая часть нашего кода генерируется с использованием значений из базы данных, разработчикам оказалось трудно поддерживать согласованную базу кода на своих отдельных рабочих станциях (поскольку может быть несколько версий базы данных). Отладка и трассировка с помощью программного обеспечения намного сложнее, и новичкам в команде требуется гораздо больше времени, чтобы выяснить «поток» кода из-за дополнительной абстракции и неявных отношений между классами. IDE не могут определить отношения между двумя классами, которые взаимодействуют через класс, сгенерированный кодом.

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