Является ли генерация кода плохой вещью?

Question

Это субъективный вопрос.

Недавно я пытался изучить NHibernate. Проблема с ним как минимум в 2 раза:

1. картографический xml-файл, который необходимо кодировать вручную
2. Класс сущностей, для которого требуется ручное кодирование

Хотя NHibernate - это замечательная среда, но необходимость писать файл сопоставления и создавать классы сущностей, которые имитируют таблицы базы данных, - трудная задача для написания. Есть несколько инструментов, которые могут решить эту проблему, например Castle ActiveRecord или NHibernate Fluent.

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

Что вы думаете?

Answer 1

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

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

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

Answer 2

Генерация кода - это хорошо, когда все сделано правильно, но слишком часто это делается неправильно.

ИМО, генераторы кода должны быть достаточно умны, чтобы обрабатывать изменения в сгенерированном коде. Еще в дни .NET 1.0 даже блестящие новые генераторы кода Visual Studio .NET могли это делать - в пределах разумного. В .NET 2.0 мы получили частичные классы, чтобы сделать его еще проще.

И все же есть еще генераторы, которые совершенно не способны работать более одного раза.

Мои правила генерации «хорошего» кода:

• Код должен быть сгенерирован в среде IDE, для которой генерируется код. Нет сторонних исполняемых файлов. Обычно это плагин для Visual Studio, но это правило применимо и к другим языкам.
• Сгенерированный код должен обеспечивать простые и понятные возможности расширения.
• Сгенерированный код должен быть невидим для разработчика.
  • Другими словами, разработчик должен использовать конструктор только для изменения сгенерированного кода.

Answer 3

Ларри Уолл (создатель Perl) говорит, что три основные добродетели - это лень, нетерпение и гордыня, и что есть хорошие и плохие версии каждого.

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

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

Answer 4

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

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

Answer 5

Я абсолютно ничего не имею против генерации кода, который не нужно модифицировать: это то, что делают компиляторы: -)

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

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

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

Правило гласит, что все, что делается автоматически, должно повторяться. Генерация кода не повторяется, если есть какая-то мысль, необходимая для превращения того, что он производит, в то, что вы хотите.

Answer 6

Генерация кода в порядке, если вы понимаете, что генерируется, или когда оно заменило значение по умолчанию на пользовательское (в данном случае)
Например, . Это часть отображения nhibernate, сгенерированного MyGeneration
Почему существует

IsChanged

свойство

/// <summary>
/// Returns whether or not the object has changed its values.
/// </summary>
Public virtual bool IsChanged { get; private set; }

Это изменится?, Когда это изменится? и что происходит, когда он меняется.

Созданный вручную класс сущностей nhibernate, скорее всего, будет иметь только свойства столбцов и конструкторы.

Это все сценарии, с которыми вы столкнетесь, особенно в корпоративном мире, где над проектом работают сотни программистов, а посредственность - факт жизни.

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

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

Answer 7

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

Я написал 3 генератора кода, но в настоящее время я использую Code Smith. Иногда я использую шаблоны NETTiers. Иногда я пользуюсь своим.

Мне все равно, какой генератор вы используете. CodeBreeze, CodeSmith, LLBLGen, файлы xslt и т. Д. ...

Возьми, выучи, люби.

КАЖДЫЙ проект, в котором я участвовал 10 или более лет, включал в себя сгенерированный код.

Начните здесь: <<a href="http://www.dotnetrocks.com/default.aspx?showNum=63" rel="nofollow noreferrer">http://www.dotnetrocks.com/default.aspx?showNum=63>

<<a href="http://www.dotnetrocks.com/default.aspx?showNum=304" rel="nofollow noreferrer">http://www.dotnetrocks.com/default.aspx?showNum=304>

<<a href="http://www.dnrtv.com/default.aspx?showNum=77" rel="nofollow noreferrer">http://www.dnrtv.com/default.aspx?showNum=77>

<<a href="http://www.dnrtv.com/default.aspx?showNum=133" rel="nofollow noreferrer">http://www.dnrtv.com/default.aspx?showNum=133>

<<a href="http://www.nettiers.org/Home.ashx" rel="nofollow noreferrer">http://www.nettiers.org/Home.ashx>

Должен бежать. Наслаждайтесь.

Answer 8

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

Марк

Answer 9

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

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

Answer 10

Генерация кода во время сборки это плохо , потому что:

• поддерживать его гораздо сложнее - новый программист, глядя на проект, может потратить неделю на понимание того, что какой-то код на самом деле сгенерирован;

• требуется полная сборка, и в среде разработки вы не хотите часто проходить полную сборку;

• когда в сгенерированном коде возникает исключение, вы застряли;

• для игнорирования требуются дополнительные (часто сложные) настройки SCM;

• вы не можете изменить его, даже если хотите, потому что он будет переопределен при следующей сборке;

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