A geração de código aumenta a qualidade do código?

Argumentando pela geração de código, estou procurando alguns exemplos de maneiras pelas quais ele aumenta a qualidade do código. Para esclarecer o que quero dizer com geração de código, posso falar apenas sobre um projeto meu:

Usamos arquivos XML para descrever relacionamentos de entidades em nosso esquema de banco de dados, para que eles nos ajudem a gerar nossa estrutura ORM e formulários HTML que podem ser usados ​​para adicionar, excluir e modificar entidades.

Na minha opinião, aumenta a qualidade do código porque o erro humano é reduzido. Se algo for implementado incorretamente, ele será quebrado no modelo, o que é bom, pois o erro pode aparecer mais cedo, pois também é quebrado o código gerado.

Desde que me pediram a definição da qualidade do código , deixe-me esclarecer isso, o que eu quis dizer é qualidade do software .

Qualidade do software : não são apenas um atributo, mas muitos, por exemplo, eficiência, modificabilidade, legibilidade, correção, robustez, compreensibilidade, usabilidade, portabilidade etc. que impactam um no outro.

Geradores de código não podem gerar código melhor do que a pessoa que escreveu o gerador.

Minha experiência com geradores de código é que eles estão bem desde que você nunca precise editar o código gerado . Se você puder se apegar a essa regra, estará pronto. Isso significa que você pode gerar de forma confiável essa parte do sistema com confiança e velocidade, adicionando automaticamente mais recursos, se necessário. Eu acho que isso pode contar com qualidade.

Certa vez, ouvi um argumento para geradores de código de que um único programador pode produzir tantas e tantas linhas de código por dia e, com geradores de código, eles poderiam produzir milhares de linhas! Obviamente, essa não é a razão pela qual estamos usando geradores.

Eu diria o contrário - presumindo que você esteja escrevendo aplicativos interessantes, a geração de código diminui a qualidade do código. A natureza da geração de código recompensa estruturas muito específicas, exageradas e super especificadas que se tornam muito difíceis de lidar sem depender continuamente da ferramenta de geração de código para gerar continuamente grupos de códigos maiores, mais complexos e mais feios. Embora possa ser uma boa ferramenta, ela realmente não deve ser a principal ferramenta na caixa.

Eu acho que a geração automatizada de código e a qualidade do código são um tanto ortogonais e não necessariamente se correlacionam.

A geração de código é apenas uma maneira de resolver uma tarefa técnica específica. Se isso resulta em maior qualidade do código depende muito do que você está fazendo.

Sua situação é um bom exemplo de geração de código, resultando em maior qualidade do código através da recuperação antecipada de possíveis erros.

Posso dar outro exemplo quando a geração automatizada de código diminui a qualidade do código. É todo poderoso ASP.NET WebForms. Ele gera geração automatizada de código, convertendo uma hierarquia de controles da interface do usuário em marcação HTML, que é tudo, menos estável, previsível e gerenciável.

Para tirar a conclusão, a geração automatizada de código pode ajudar a aumentar a qualidade do código quando usado corretamente.

A geração de código não afeta a qualidade do código , por si só, nem a consistência do código .

O código gerado será consistente entre instâncias de geração. Se o gerador for projetado para emitir código de boa qualidade, o código gerado será consistentemente de boa qualidade. Se, no entanto, o gerador de código emitir código de má qualidade, você obterá um código constantemente incorreto.

A geração de código também pode ser usada para criar código mais rapidamente . Mais rápido, no entanto, não significa melhor ... Isso pode significar que você obtém seu código de má qualidade muito mais rápido.

A geração de código é boa se:

• o código gerado não deve ser editado
• o gerador de código oferece flexibilidade suficiente para você fazer o que precisa
• o idioma de entrada para o gerador de código é melhor (ou seja, SECO) do que o que você teria que escrever
• o gerador de código cria um bom código confiável com o qual você não precisa se preocupar, mesmo que seja prolixo

Nesse caso, o código cuja qualidade você precisa considerar é o código que é inserido no gerador.

Uma medida simples da qualidade é, para alterações típicas nos requisitos, quanta edição manual você precisa fazer. Quanto menos, melhor.

Aumento da qualidade do código devido a DRY (não se repita).

As regras de geração de código são escritas uma vez; eles não são codificados para todas as instâncias do código gerado e, portanto, reduzem o potencial de erro humano ao copiar / colar o conteúdo com pequenas modificações.

Suponho que você queira dizer geradores de código proprietários, manuseados manualmente para uso interno específico, pois, caso contrário, qualquer coisa que não seja o código da máquina é um gerador de código. Mas aqui vai você:

Eu acho que é muito discutível que o gráfico de nós no Blueprints seja mais fácil de manter e muito menos propenso a erros do que o código GLSL / HLSL que ele gera (e, caso contrário, precisaria ser manuscrito).

Também é muito mais produtivo criar novos shaders, pois você obtém um feedback visual em tempo real de como o resultado final se parece à medida que você altera o gráfico. Definitivamente, prefiro manter milhares de shaders representados com gráficos nodais dessa maneira, em vez do código GLSL / HLSL, e na verdade estou mais familiarizado com a escrita do GLSL / HLSL do que com o Blueprints. Eu acho que é praticamente impossível causar um bug grave, além de talvez algumas pequenas falhas visuais que você provavelmente perceberia imediatamente porque a "linguagem visual" impõe restrições sensíveis com um estilo funcional puro que não permite, por exemplo, bater um shader, pelo menos AFAIK (eu não sou um especialista em Blueprints).

Não há mais "código" para manter mais. Você apenas coloca nós dentro de um gráfico e desenha links entre eles e, voila, gera código de sombreador para você. Quem mantém essas coisas e diz: " Sabe, minha vida seria muito mais fácil e eu teria muito mais tempo livre se isso fosse escrito apenas no código GLSL em vez de usar o Blueprints " . Provavelmente nunca.

Dito isso, encontrei minha parte de geradores de código proprietários que tornaram a vida mais difícil, o que me fez aprender essa meta linguagem estúpida que possui benefícios muito limitados, se houver, sobre a escrita de código no idioma do código gerado. Para mim, um sinal revelador de geração de código é uma merda, que faz pouco mais do que reduzir uma pequena quantidade de clichê e não reduz, digamos, a possibilidade de bugs. Você sabe que é especialmente ruim se ele realmente introduzir novas maneiras de causar bugs que o idioma original não possuía. Mas há casos de geração de código, como o descrito acima, em que o aumento da produtividade é tão grande, tornando coisas meticulosas que custam um tempo enorme agora custam centavos, que ninguém jamais usaria e depois olharia para trás.

Para mim, há um argumento mais legítimo para o desenvolvimento proprietário do Blueprints entre a equipe da Epic do que muitas linguagens de programação supérfluas por aí criadas para o público em geral, que mal trazem algo novo para a mesa.

Eu diria que, no seu caso, isso pode melhorar um pouco a qualidade, mas reduz muito o tempo de desenvolvimento. Às vezes, o código gerado é esquisito, estranho ou simplesmente ruim. Nesses casos, o código gerado pode diminuir a qualidade e adicionar mais tempo de teste / fixação / regressão ao projeto. E algumas tarefas são complexas demais para serem facilmente geradas - o gerador se torna todo um sistema separado (possivelmente maior e mais complexo que o projeto principal).

Geradores de código são bons, mas tenha cuidado com eles!

Eu costumava trabalhar em uma loja que dependia muito da geração de código. Em minha opinião, tornou o código do projeto muito uniforme. E a esse respeito, a qualidade estava boa.

No entanto, quando você não tem mais permissão para escrever código personalizado, porque tudo precisa passar pelo gerador, acho que você perde parte da vantagem de ser um programador.

Então eu acho que esse é um tópico de espada de ponta dupla, com certeza. Sim, os geradores são ótimos porque reduzem erros e aumentam os padrões de código; no entanto, eles também fazem "alguns" dos programadores serem burros, porque confiam nos geradores em vez de sujar as mãos.

Apenas meus 2 centavos.

Além da resposta de Martin, eu acrescentaria que a geração de código SQL é muito boa quando você trabalha em uma base registro por registro (selecione * da tab1 em que tab1.pkcolumn =: parâmetro, atualize a tab1 set [qualquer número de colunas] em que tab1.pkcolumn =: parâmetro, etc). E seu ORM brilhará nesse cenário, porque o SQL que precisa ser gerado é realmente repetitivo.

Minhas principais preocupações são as metaqueries - consultas nas propriedades do objeto que o ORM traduz para o SQL usando qualquer algoritmo. Metaquerias muito semelhantes podem gerar um SQL completamente diferente - e não garantem que esse SQL gerado seja performático.

Uma linguagem de metaqueria que se traduz em outro idioma (SQL) que se traduz em um plano de consulta para executar efetivamente a coleta de dados. E o resultado gerado deve ser objetos, para que o ORM instancie os objetos afetados - para que possa desencadear outra chuva de consultas para preencher os atributos dos objetos não trazidos pela própria metaqueria ...

Eu concordo totalmente com aqueles que dizem que a geração de código é boa, desde que você nunca precise editar (de preferência, nunca precise olhar) o código gerado.

Se podemos aceitar que o código gerado é aproximadamente o mesmo número de linhas escritas à mão, e se podemos dizer que é livre de erros, o número de linhas que podem conter erros diminuiu. Portanto, a qualidade do código deveria ter aumentado.

Adendo: é claro que outros fatores, como o tempo de execução, podem desempenhar um papel.

Pessoalmente, escrevi vários geradores de código, mas nunca como uma abordagem inicial.

Sempre foi quando eu notei um padrão repetitivo no código existente, então meu gerador pega um código existente ao adicionar um código novo, mas semelhante, e parametriza algumas partes variáveis ​​dele.

Nessa medida, meu código gerado é quase idêntico ao código manuscrito existente (exceto que ele tende a apresentar melhor visualmente e a ser mais uniforme, o que eu acho que ajuda na legibilidade, se é que ele precisa ser examinado).

A propósito, defendo a inserção de comentários de abertura / fechamento que indiquem que o código foi gerado, incluindo detalhes da ferramenta e seu mantenedor.