Плохи ли генераторы кода?

https://stackoverflow.com/questions/202871

03-07-2019
|

Вопрос

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

Решение

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

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

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

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

Другие советы

Генераторы кода - это здорово, плохой код - это плохо.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#line

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

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

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

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

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

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

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

Я уже написал несколько генераторов кода - и, честно говоря, они не раз спасали мою задницу!

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

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

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

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

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

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

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

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

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

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

Генерация кода плоха, когда она усложняет программирование (НАПРИМЕР, плохо сгенерированный код или кошмар обслуживания), но она хороша, когда делает программирование более эффективным.

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

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

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

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

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

-Адам

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Джон

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow