Зачем мне использовать генераторы кода

По крайней мере, вы правильно сформулировали вопрос =)

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

Классический пример этого - доступ к данным; вы можете сгенерировать 250 классов (по 1 для каждой таблицы в схеме), эффективно создав решение табличного шлюза, или вы можете создать что-то более похожее на модель предметной области и использовать NHibernate / ActiveRecord / LightSpeed ​​/ [выберите свой orm] для отображения богатой модели предметной области в базу данных.

Хотя и ручное решение, и ORM фактически являются генераторами кода, основное различие заключается в том, когда код генерируется. В ORM это неявный шаг, который происходит во время выполнения и, следовательно, является односторонним по своей природе. Решение, созданное вручную, требует явного шага для генерации кода во время разработки и вероятности того, что сгенерированные классы потребуют настройки в какой-то момент, что создаст проблемы при повторной генерации кода. Явный шаг, который должен произойти во время разработки, вносит трение в процесс разработки и часто приводит к коду, который нарушает DRY (хотя некоторые утверждают, что сгенерированный код никогда не может нарушать DRY).

Другая причина рекламировать генерацию кода связана с миром MDA / MDE (Model Driven Architecture / Engineering). Я не придаю этому большого значения, но вместо того, чтобы приводить ряд плохо выраженных аргументов, я просто собираюсь кооптировать кого-то другого - http://www.infoq.com/articles/8-reasons-why-MDE-fails.

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

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

@John
Перенос создания «базовых классов» из IDE в xml / dsl часто наблюдается при разработке «большого взрыва» - классическим примером может быть попытка разработчиков преобразовать базу данных в модель предметной области. Если генератор кода не очень хорошо написан, он просто создает дополнительную нагрузку на разработчика, поскольку каждый раз, когда им нужно обновить модель предметной области, им придется либо переключать контекст и обновлять xml / dsl, либо расширять модель предметной области. а затем перенесите эти изменения обратно в xml / dsl (эффективно выполняя работу дважды).

Есть некоторые генераторы кода, которые очень хорошо работают в этом пространстве (дизайнер LightSpeed ​​- единственный, о котором я могу думать о atm), выступая в качестве движка для поверхности дизайна, но часто эти генераторы кода генерируют ужасный код, который невозможно поддерживать (например, winforms / webforms, поверхность дизайна EF1) и, следовательно, быстро сводит на нет любые преимущества производительности, полученные от использования генератора кода в первую очередь.

Ну это либо:

• вы пишете 250 классов, все они примерно одинаковы, но немного отличаются, например делать доступ к данным; занимает у вас неделю, и это скучно, подвержено ошибкам и раздражает

OR:

• вы вкладываете 30 минут в создание шаблона кода и позволяете механизму генерации выполнять основную работу еще за 30 минут

Итак, генератор кода дает вам:

• скорость
• воспроизводимость
• намного меньше ошибок
• намного больше свободного времени! :-)

Отличные примеры:

• Шаблоны Linq-to-SQL T4 от Damien Guard для создания одного отдельного файла для каждого класса в модели вашей базы данных, используя лучший секрет Visual Studio 2008 - шаблоны T4

• PLINQO - то же самое, но для генератора Codesmith

и многое другое .....

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

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

Использование построителей графического интерфейса, которые генерируют для вас код, является обычной практикой. Благодаря этому вам не нужно вручную создавать все виджеты. Вы просто перетаскиваете их и используете сгенерированный код. Для простых виджетов это действительно экономит время (я много использовал это для wxWidgets).

На самом деле, когда вы используете практически любой язык программирования, вы используете «генератор кода» (кроме ассемблера или машинного кода). Я часто пишу небольшие 200-строчные скрипты, которые выжимают несколько тысяч строк на C. Есть также программное обеспечение. вы можете получить, который помогает генерировать определенные типы кода (например, yacc и lex используются для генерации синтаксических анализаторов для создания языков программирования).

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

Например, вот очень длинный и утомительный файл, который я (не) писал в рамках своей работы по модификации игрового движка CRX на основе Quake2. Он берет целочисленные значения всех констант #defined из двух заголовков и превращает их в "cvars" (переменные для игровой консоли).
http://meliaserlow.dyndns.tv:8000/alienarena/lua_source/game/cvar_constants.c

Вот короткий сценарий Bash, который сгенерировал этот код во время компиляции:
http://meliaserlow.dyndns.tv:8000/alienarena/lua_source/autogen/constant_cvars.sh

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

Канонический пример этого - доступ к данным, но у меня есть другой пример. Я работал над системой обмена сообщениями, которая обменивается данными через последовательный порт, сокеты и т. Д., И обнаружил, что мне постоянно приходилось писать такие классы снова и снова:

public class FooMessage
{
    public FooMessage()
    {
    }

    public FooMessage(int bar, string baz, DateTime blah)
    {
        this.Bar = bar;
        this.Baz = baz;
        this.Blah = blah;
    }

    public void Read(BinaryReader reader)
    {
        this.Bar = reader.ReadInt32();
        this.Baz = Encoding.ASCII.GetString(reader.ReadBytes(30));
        this.Blah = new DateTime(reader.ReadInt16(), reader.ReadByte(),
            reader.ReadByte());
    }

    public void Write(BinaryWriter writer)
    {
        writer.Write(this.Bar);
        writer.Write(Encoding.ASCII.GetBytes(
            this.Baz.PadRight(30).Substring(0, 30)));
        writer.Write((Int16)this.Blah.Year);
        writer.Write((byte)this.Blah.Month);
        writer.Write((byte)this.Blah.Day);
    }

    public int Bar { get; set; }
    public string Baz { get; set; }
    public DateTime Blah { get; set; }
}

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

Я не буду публиковать код code-gen, это много загадочного материала CodeDom, но суть в том, что я смог сжать всю систему до одного XML-файла:

<Messages>
    <Message ID="12345" Name="Foo">
        <ByteField Name="Bar"/>
        <TextField Name="Baz" Length="30"/>
        <DateTimeField Name="Blah" Precision="Day"/>
    </Message>
    (More messages)
</Messages>

Насколько это проще? (Риторический вопрос.) Я наконец смог дышать. Я даже добавил несколько наворотов, чтобы он мог сгенерировать «прокси», и я мог написать такой код:

var p = new MyMessagingProtocol(...);
SetFooResult result = p.SetFoo(3, "Hello", DateTime.Today);

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

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

Генератор кода полезен, если:

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

2. Согласованность, достигнутая с помощью генератора кода, уменьшит количество ошибок до степени, которая того стоит.

3. Дополнительная проблема отладки сгенерированного кода не сделает отладку достаточно неэффективной, чтобы перевесить преимущества 1 и 2.

Для доменных или многоуровневых приложений генерация кода - отличный способ создать начальную модель или уровень доступа к данным. Он может произвести 250 классов сущностей за 30 секунд (или в моем случае 750 классов за 5 минут). После этого программист может сосредоточиться на улучшении модели с помощью отношений, бизнес-правил или получения представлений в MVC.

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

Если вы просто хотите, чтобы уровень данных был «автоматически создан», чтобы вы могли «заставить графический интерфейс работать за 2 дня», то я бы предложил использовать продукт / набор инструментов, ориентированный на управляемое данными или двухуровневое приложение. сценарий.

Наконец, не забывайте «мусор на входе = мусор на выходе». Если весь ваш уровень данных однороден и не абстрагируется от базы данных, пожалуйста, спросите себя, зачем вам вообще нужен слой данных. (Если только вам не нужно выглядеть продуктивно :))

Как насчет примера хорошего использования генератора кода?

Здесь используются шаблоны t4 (встроенный в Visual Studio генератор кода) для создания сжатого CSS из файлов .less: http://haacked.com/archive/2009/12/02/t4-template-for-less-css.aspx

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

Здесь все говорят о простой генерации кода, но как насчет генерации кода на основе моделей (например, MDSD или DSM)? Это поможет вам выйти за рамки простых ORM / элементов доступа / генераторов шаблонов и перейти к генерации кода концепций более высокого уровня для вашей проблемной области.

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

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

MetaEdit + от MetaCase (зрелый) и ABSE от Isomeris (мой проект, в альфа-версии, информация на http://www.abse.info) - это две передовые технологии генерации кода на основе моделей.

Что действительно необходимо, так это изменение мышления (как в 90-х годах требовалось ООП) ...

Я фактически добавляю последние штрихи к генератору кода, который использую для проекта, для которого меня наняли. У нас есть огромные XML-файлы определений, и за несколько дней работы мне удалось сгенерировать более 500 классов C #. Если я хочу добавить функциональность ко всем классам, скажем, я хочу добавить атрибут ко всем свойствам. Я просто добавляю его в свой генератор кода, нажимаю - и бац! Я задолбался.

Это действительно здорово, правда.

Есть много применений для генерации кода.

Написание кода на знакомом языке и создание кода для другого целевого языка.

• GWT - Java -> Javascript
• MonoTouch - C# -> Objective-C

Написание кода на более высоком уровне абстракции.

• Компиляторы
• Языки, специфичные для домена

Автоматизация повторяющихся задач.

• Уровни доступа к данным
• Исходные модели данных

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

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

Если с генератором кода вы также намереваетесь использовать фрагменты, попробуйте разницу между вводом ctor + TAB и написанием конструктора каждый раз в ваших классах. Или проверьте, сколько времени вы зарабатываете, используя фрагмент для создания оператора switch, связанного с перечислением со многими значениями.

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

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

Вот какая ересь:

Если задача настолько глупа, что ее можно автоматизировать во время написания программы (т.е. исходный код может быть сгенерирован сценарием, скажем, из XML), то то же самое можно сделать и во время выполнения (т.е. некоторое представление этого XML может можно интерпретировать во время выполнения) или с помощью некоторого метапрограммирования. Таким образом, по сути, программист был ленив, не пытался решить настоящую проблему, но нашел простой выход и написал генератор кода. В Java / C # посмотрите на отражение, а в C ++ на шаблоны