Повышает ли генерация кода качество кода?

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

Мы используем файлы XML для описания отношений сущностей в нашей схеме базы данных, поэтому они помогают нам создавать нашу структуру ORM и формы HTML, которые можно использовать для добавления, удаления и изменения сущностей.

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

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

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

Генераторы кода не могут генерировать лучший код, чем тот, кто написал генератор.

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

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

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

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

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

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

Я могу привести еще один пример, когда автоматическая генерация кода снижает качество кода. Это не всемогущий ASP.NET WebForms. Он выполняет автоматическую генерацию кода, переводя иерархию элементов управления пользовательского интерфейса в разметку HTML, которая не является стабильной, предсказуемой и управляемой.

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

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

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

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

Генерация кода хороша, если:

• сгенерированный код не должен редактироваться
• генератор кода дает вам достаточно гибкости, чтобы делать то, что вам нужно сделать
• язык ввода для генератора кода лучше (т.е. СУХОЙ), чем то, что вы должны были бы написать в противном случае
• генератор кода создает хороший надежный код, о котором вам не нужно беспокоиться, даже если он многословный

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

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

Повышенное качество кода из-за СУХОГО (не повторяйте себя).

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

Я предполагаю, что вы имеете в виду проприетарные генераторы кода, управляемые для конкретного внутреннего использования, поскольку в противном случае все, кроме машинного кода, является генератором кода. Но здесь вы идете:

Я думаю, что это очень спорно, что граф узел Blueprints легче поддерживать и гораздо менее подвержены ошибкам, чем код GLSL / HLSL он генерирует (и был бы в противном случае должен был быть написано от руки).

Кроме того, гораздо эффективнее создавать новые шейдеры, поскольку вы получаете визуальную обратную связь в реальном времени о том, как будет выглядеть конечный результат при изменении графика. Я определенно предпочел бы поддерживать тысячи шейдеров, представленных в виде узловых графов, таким образом, вместо кода GLSL / HLSL, и на самом деле я больше знаком с написанием GLSL / HLSL, чем с использованием Blueprints. Я думаю, что на самом деле практически невозможно вызвать, как серьезную ошибку, кроме, возможно, небольшого визуального сбоя, который вы, вероятно, сразу заметите, потому что «визуальный язык» накладывает разумные ограничения, зачастую с чисто функциональным стилем, который не позволяет вам, скажем, разбить шейдер, по крайней мере, AFAIK (я, правда, не эксперт по Blueprints).

Там даже не «код», чтобы поддерживать больше. Вы просто размещаете узлы внутри графика и рисуете связи между ними, и, вуаля, он генерирует шейдерный код для вас. Кто поддерживает этот материал и говорит: « Вы знаете, моя жизнь была бы намного проще, и у меня было бы намного больше свободного времени, если бы это было просто написано в коде GLSL вместо использования Blueprints». Вероятно, никогда.

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

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

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

Генераторы кода в порядке, но будьте осторожны с ними!

Раньше я работал в магазине, который сильно полагался на генерацию кода. На мой взгляд, это сделало код проекта очень единообразным. И в этом отношении качество было в порядке.

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

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

Просто мои 2 цента.

В дополнение к ответу Мартина я хотел бы добавить, что генерация кода SQL очень хороша, когда вы работаете по принципу «запись за записью» (выберите * из tab1, где tab1.pkcolumn =: параметр, обновление tab1 set [любое количество столбцов], где tab1.pkcolumn =: параметр и т. д.). И ваш ORM будет сиять в этом сценарии, потому что SQL, который должен быть сгенерирован, действительно повторяется.

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

Язык мета-запросов, который переводится на другой язык (SQL), который переводится в план запроса для эффективного выполнения сбора данных. И сгенерированный результат должен быть объектами, поэтому ORM должен создавать экземпляры затронутых объектов - чтобы он мог инициировать еще один поток запросов, чтобы заполнить атрибуты объектов, не принесенных самой мета-запросом ...

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

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

Приложение: конечно, другие факторы, такие как время выполнения, могут играть роль.

Лично я написал довольно много генераторов кода, но никогда в качестве начального подхода.

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

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

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