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

Question

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

-Adam

Answer 6

Это вопрос рабочего процесса. 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) более тщательно поддерживать процедуры предварительной сборки, чтобы генераторы кода могли быть интегрированы в рабочий процесс ваших решений с использованием метаданных, а не управляться вручную как внешние файлы кода, которые необходимо поддерживать. в изоляции.

Jon

Answer 7

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

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

Answer 8

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

Answer 9

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

Answer 10

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

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