Являются ли генераторы кода плохими?

Ответ 1

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

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

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

Code Generation in Action - довольно хорошая книга по этому вопросу.

Ответ 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

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

Нет установки

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

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

Без редактирования

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

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

Считываемый выход

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

#line

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

Я написал несколько генераторов кода раньше - и, честно говоря, они спасли мой прикладом более одного раза!

Как только у вас есть четко определенный дизайн объекта - коллекция - пользовательский элемент управления, вы можете использовать генератор кода для создания основ для вас, что позволяет вашему времени как разработчика более эффективно использоваться при создании сложного материала, кто действительно хочет написать более 300 деклараций публичной собственности и переменные уступы? Я предпочел бы зацикнуться на бизнес-логике, чем на все бессмысленные повторяющиеся задачи.

Ответ 10

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

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

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

Ответ 11

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

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

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

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

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

Ответ 12

В некоторых (не многих) случаях они полезны. Например, если вы хотите генерировать классы на основе данных типа поиска в таблицах базы данных.

Ответ 13

Генерация кода плохой, когда он затрудняет программирование (IE, плохо сгенерированный код или кошмар для обслуживания), но они хороши, когда они делают программирование более эффективным.

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

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

Ответ 14

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

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

Но сами по себе генераторы кода неплохие.

-Adam

Ответ 15

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

Ответ 16

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

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

Ответ 17

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

Инструменты, такие как Visual Studio, Codesmith имеют свои собственные шаблоны для большинства общих задач и упрощают этот процесс. Но его легко развернуть самостоятельно.

Ответ 18

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

поддерживаемость < > простой или быстрый процесс кодирования

Ответ 19

Я использую My Generation с Entity Spaces, и у меня нет никаких проблем с ним. Если у меня есть изменение схемы, я просто регенерирую классы, и все это отлично работает.

Ответ 20

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

Ответ 21

Первые компиляторы С++ были генераторами кода, которые выплевывали C-код (CFront).

Я не уверен, что это аргумент для или против генераторов кода.

Ответ 22

Я думаю, что Митчел ударил его по голове. Создание кода имеет свое место. Есть некоторые обстоятельства, когда более эффективно использовать компьютер для вас! Это может дать вам свободу передумать о реализации конкретного компонента, когда затраты на изменение кода незначительны. Конечно, по-прежнему важно понимать выход генератора кода, но не всегда. У нас был пример в проекте, который мы только что закончили, где несколько приложений на С++ нуждались в общении с приложением С# по именованным каналам. Нам было лучше использовать небольшие, простые файлы, которые определяли сообщения и имели все классы и код, сгенерированные для каждой стороны транзакции. Когда программист работал над проблемой X, последнее, что им нужно было, - это беспокоиться о деталях внедрения и о неизбежном попадании кеша.

Ответ 23

Это вопрос рабочего процесса. ASP.NET - это генератор кода. Механизм синтаксического анализа XAML фактически генерирует С#, прежде чем он преобразуется в MSIL. Когда генератор кода становится внешним продуктом, таким как CodeSmith, который изолирован от рабочего процесса разработки, необходимо соблюдать особую осторожность, чтобы синхронизировать ваш проект. Например, если сгенерированный код является ORM-выходом и вы вносите изменения в схему базы данных, вам придется либо полностью отказаться от генератора кода, либо использовать возможности С# для работы с частичными классами (что позволяет добавлять элементы и функциональность для существующего класса, не наследуя его).

Мне лично не нравится изолированный /Alt -Tab характер рабочих процессов генератора; если генератор кода не является частью моей IDE, тогда я чувствую, что это kludge. Некоторые генераторы кода, такие как Entity Spaces 2009 (еще не выпущенные), более интегрированы, чем предыдущие поколения генераторов.

Я думаю, что панацею с целью создания генераторов кода можно использовать в процедурах предварительной компиляции. С# и другим .NET-языкам этого не хватает, хотя ASP.NET пользуется им и почему, скажем, SubSonic работает так хорошо для ASP.NET, но не намного больше. SubSonic генерирует код С# во время сборки непосредственно перед началом компиляции обычной ASP.NET.

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

Джон

Ответ 24

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

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

Это ИМХО лучший подход. Звук утопический? По крайней мере, я этого не знаю;) Ближайшее будущее расскажет.

Ответ 25

В недавнем проекте мы построили собственный генератор кода. Мы создали весь материал базы данных и весь базовый код для наших классов представления и просмотра. Хотя генератору потребовалось несколько месяцев, чтобы построить (в основном потому, что это был первый раз, когда мы это сделали, и у нас было несколько ложных запусков), он заплатил за себя в первый раз, когда мы его запустили, и создал базовую структуру для всего приложения в около десяти минут. Все это было на Java, но Ruby отлично подходит для написания кода, особенно для небольших проектов одноразового типа. Лучше всего было согласованность кода и организации проекта. Кроме того, вам нужно подумать о базовой структуре заблаговременно, что всегда хорошо.

Ответ 26

Генераторы кода великолепны, полагая, что это хороший генератор кода. Особенно работает С++/java, которая очень многословна.