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

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

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

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

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

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

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

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

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

Jon

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-Adam

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

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

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

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

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

Я записал несколько генераторов кода прежде - и быть честными они сохранили мой зад несколько раз!

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

Если это - мейнфреймовый генератор кода Кобола, что Fran Tarkenton пытается продать Вам тогда абсолютно да!

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

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

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

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

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

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

Позволяют Вам работать способ, которым Вы хотите работать.

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

Выполнение как часть Вашей регулярной сборки.

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

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

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

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

Никакое редактирование не произвело

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

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

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

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

#line

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Однако мое самое большое схватывание с генераторами кода ORM - то, что обслуживание, сгенерированным кодом может быть ЛАВАШ, если схема изменяется.

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

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

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

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

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