São geradores de código ruim?

https://stackoverflow.com/questions/202871

03-07-2019
|

Pergunta

Eu uso MyGeneration juntamente com nHibernate para criar os objetos POCO básicos e arquivos de mapeamento XML. Já ouvi algumas pessoas dizem que eles pensam geradores de código não são uma boa idéia. Qual é o melhor pensamento atual? É apenas que a geração de código é ruim quando se gera milhares de linhas de código não compreensível?

Solução

código gerado por um gerador de código não deve (como uma generalização) ser usado em uma situação onde é posteriormente editado por intervenção humana. Alguns sistemas tais os assistentes em várias encarnações do Visual C ++ código gerado que o programador foi então esperados para editar manualmente. Este não era popular, pois era necessário desenvolvedores para escolher distante o código gerado, compreendê-lo e fazer modificações. Também significava que o processo de geração era um tiro.

código gerado deve viver em arquivos separados de outro código no sistema e só pode ser gerado a partir do gerador. O código código gerado devem ser claramente marcados como tal para indicar que as pessoas não devem modificá-lo. Já tive a oportunidade de fazer algumas sistemas de geração de código de um tipo ou outro, e Todos do código de modo gerado tem algo parecido com isso no preâmbulo:

-- =============================================================
-- === Foobar Module ===========================================
-- =============================================================
--
--         === THIS IS GENERATED CODE.  DO NOT EDIT. ===
--
-- =============================================================

Geração de Código em Ação é bastante um bom livro sobre o assunto.

Outras dicas

Geradores de código são grandes, código ruim é ruim.

A maioria das outras respostas nesta página são ao longo das linhas de "Não, porque muitas vezes o código gerado não é muito bom."

Esta é uma resposta fraca porque:

1) Os geradores são ferramenta como qualquer outra coisa - se você abusar delas, a culpa não faça a ferramenta.

2) Os desenvolvedores tendem a se orgulham de sua capacidade de escrever grande momento um código, mas você não geradores de código de uso para um fora projectos.

Nós usamos um sistema de geração de código para a persistência em todos os nossos projetos Java e tem milhares de classes geradas na produção.

Como gestor eu os amo porque:

1) Confiabilidade: Não existem erros remanescentes significativos nesse código. Ele tem sido tão exaustivamente testado e aperfeiçoado ao longo dos anos do que quando a depuração Eu nunca se preocupar com a camada de persistência.

2) Padronização:. Cada código de desenvolvedores é idêntico a este respeito para que haja muito menos para um cara para aprender quando pegar um novo projeto a partir de um colega de trabalho

3) Evolução:. Se nós encontrar uma maneira melhor de fazer as coisas, podemos atualizar os modelos e atualização 1000, de aulas de forma rápida e consistente

4) Revolution:. Se mudar para um sistema de persistência diferente no futuro, então o fato de que cada classe persistente tem uma API exatamente idêntica torna o meu trabalho muito mais fácil

5) Produtividade:. É apenas alguns cliques para construir um sistema de objeto persistente de metadados - isso economiza milhares de chato horas desenvolvedor

Geração de código é como usar um compilador -? Numa base caso individual que você pode ser capaz de escrever linguagem melhor otimizado montagem, mas com o grande número de projetos que preferem ter o compilador fazer isso por você direita

Nós empregamos um truque simples para garantir que as aulas sempre pode ser regenerado sem perder personalizações: cada classe gerada é abstrato. Em seguida, o desenvolvedor estende-lo com uma classe concreta, acrescenta a lógica de negócios personalizada e substitui quaisquer métodos de classe base de que ele quer ser diferente do padrão. Se houver uma mudança nos metadados ele pode regenerar a classe abstrata, a qualquer momento, e se o novo modelo quebra sua classe concreta o compilador irá avisá-lo.

O maior problema que eu tive com geradores de código é durante a manutenção. Se você modificar o código gerado e, em seguida, fazer uma alteração em seu esquema ou modelo e tentar regenerar você pode ter problemas.

Um problema é se a ferramenta não permite que você para proteger alterações feitas ao código modificado, em seguida, as alterações serão substituídas.

Outro problema que eu vi, particularmente com geradores de código em RSA para serviços web, se você alterar o código gerado muito o gerador se queixam de que há uma incompatibilidade e se recusam a regenerar o código. Isso pode acontecer por algo tão simples como mudar o tipo de uma variável. Então você está gerando preso o código para um projeto diferente e fundindo os resultados de volta em seu código original.

Geradores de código pode ser um benefício para a produtividade, mas há algumas coisas para procurar:

permitem que você trabalhe da maneira que você deseja trabalhar.

Se você tem que dobrar seu código não-gerado para caber em torno do código gerado, então você provavelmente deve escolher uma abordagem diferente.

Executar como parte de sua compilação regular.

A saída deve ser gerada para um diretório intermediários, e não ser verificados no controle de origem. A entrada deve ser verificado no controle de origem, no entanto.

Não instalar

O ideal é que você verifique a ferramenta no controle de origem, também. Fazer as pessoas instalar as coisas quando se prepara uma nova máquina de compilação é uma má notícia. Por exemplo, se você ramo, você quer ser capaz de versão das ferramentas com o código.

Se você deve, fazer um único script que terá uma máquina limpa com uma cópia da árvore de origem, e configurar a máquina, conforme necessário. Totalmente automatizada, por favor.

Sem edição de saída

Você não deveria ter que editar a saída. Se a saída não é suficiente útil como-é, em seguida, a ferramenta não está funcionando para você.

Além disso, a saída deve indicar claramente que é um arquivo gerado e não deve ser editado.

saída legível

A saída deve ser escrito e formatado bem. Você quer ser capaz de abrir a saída e lê-lo sem um monte de problemas.

#line

Muitas línguas apoiar algo como uma directiva #line, que permite mapear o conteúdo de parte de trás saída para a entrada, por exemplo, quando a produção de mensagens de erro do compilador ou ao pisar no depurador. Isso pode ser útil, mas também pode ser irritante a menos que feito muito bem, por isso não é uma exigência.

A minha posição é que os geradores de código não são ruins, mas muitos usos deles são.

Se você estiver usando um gerador de código para economia de tempo que escreve código bom, então ótimo, mas muitas vezes ele não é otimizado, ou adiciona muita sobrecarga, nesses casos eu acho que é ruim.

geração de código pode causar-lhe algum sofrimento, se você gosta de misturar o comportamento em suas classes. Uma alternativa igualmente produtivos poderiam ser atributos / anotações e runtime reflexão.

Os compiladores são geradores de código, para que eles não são inerentemente mau, a menos que você só gosta de programa em código de máquina cru.

Eu acredito, porém, que os geradores de código deve sempre encapsular completamente o código gerado. Ou seja, você deve não tem que modificar o código gerado pelo lado, qualquer alteração deve ser feito modificando a entrada para o gerador e regenerar o código.

Se seu um gerador de mainframe código COBOL que Fran Tarkenton está tentando vendê-lo em seguida, absolutamente sim!

Eu escrevi alguns geradores de código antes - e para ser honesto eles salvou a minha bunda mais de uma vez

Uma vez que você tem um objeto claramente definido - coleção - usuário projeto de controle, você pode usar um gerador de código para construir as bases para você, permitindo que o seu tempo como um desenvolvedor para ser usado de forma mais eficaz na construção do material complexo, afinal, que realmente quer escrever mais de 300 declarações de propriedade pública e instatiations variáveis? Eu prefiro ficar preso dentro da lógica de negócios do que todas as tarefas repetitivas sem sentido.

O erro muitas pessoas fazem quando se utiliza a geração de código é para editar o código gerado. Caso você tenha em mente que se você sentir que você precisa para editar o código, você realmente precisa estar editando a ferramenta de geração de código é um benefício para a produtividade. Se você está constantemente lutando contra o código que é gerado ele vai acabar custando a produtividade.

Os melhores geradores de código que eu encontrei são aqueles que permitem que você edite os modelos que geram o código. Eu realmente gosto CodeSmith por esta razão, porque é modelo baseado e os modelos são facilmente editáveis. Quando você achar que há uma deficiência no código que é gerado, você acabou de editar o modelo e regenerar o seu código e você é sempre bom depois disso.

A outra coisa que eu encontrei é que um monte de geradores de código não são super fácil de usar com um sistema de controle de origem. A maneira que temos obtido em torno deste é verificar no templates em vez do código e a única coisa que verificar em controle de origem que é gerado é uma versão compilada do código gerado (arquivos DLL, principalmente ). Isto poupa-lhe muita dor, porque você só tem que verificar em poucos DLLs em vez de possivelmente centenas de arquivos gerados.

Nosso projeto atual faz uso pesado de um gerador de código. Isso significa que eu tenho visto os benefícios "óbvias" de geração de códigos pela primeira vez - nenhum erro codificador, sem erros, melhor adesão a um padrão de codificação estilo - e, depois de alguns meses em modo de manutenção, as desvantagens inesperadas. Nosso gerador de código que, de fato, melhorar a nossa qualidade codebase inicialmente. Temos a certeza que foi totalmente automatizada e integrada com a nossa compilações automatizadas. No entanto, eu diria que:

gerador de código (1) A pode ser uma muleta. Temos várias bolhas enormes, feias de difícil de manter o código em nosso sistema agora, porque em um ponto no passado era mais fácil para adicionar vinte novas classes para nosso arquivo XML geração de código, do que era fazer uma análise adequada e classe refatoração.

(2) Excepções à regra de matá-lo. Usamos o gerador de código para criar várias classes centenas de tela e objetos de negócios. Inicialmente, imposta uma norma sobre quais métodos poderiam aparecer em uma classe, mas como todas as normas, começamos a fazer exceções. Agora, o nosso arquivo XML geração de código é um monstro enorme, cheia de casos especiais de trechos de código Java que são inseridos em selecione classes. É quase impossível para analisar ou entender.

(3) Uma vez que grande parte do nosso código é gerado, usando valores de um banco de dados, está provado difícil para os desenvolvedores a manter uma base de código consistente em suas estações de trabalho individuais (uma vez que pode haver várias versões do banco de dados). Depuração e rastreamento através do software é muito mais difícil, e novatos para a equipe de levar muito mais tempo para descobrir o "fluxo" do código, por causa da abstração extra e relações implícitas entre classes. IDE não pode pegar as relações entre duas classes que se comunicam através de uma classe gerada pelo código.

Isso é provavelmente o suficiente para agora. Acho Código Geradores são excelentes, como parte do kit de ferramentas individual de um desenvolvedor; um conjunto de scripts que escrever o seu código clichê make iniciar um projeto muito mais fácil. Mas Código Geradores fazer não problemas fazer a manutenção ir embora.

Em alguns (não muitos) casos, eles são úteis. Tal como se você quer gerar classes com base em dados do tipo de pesquisa nas tabelas de banco de dados.

Geração de código é ruim quando se torna a programação mais difícil (IE, código mal gerado, ou um pesadelo de manutenção), mas eles são bons quando se tornar a programação mais eficiente.

Eles provavelmente não sempre gerar código otimizado, mas dependendo de sua necessidade, você pode decidir que manhours desenvolvedor salvo compensar algumas questões menores.

Tudo o que disse, o maior cólica com geradores de código ORM é que a manutenção do código gerado pode ser um PITA se as alterações de esquema.

geradores

código não são ruins, mas às vezes eles são utilizados em situações em que uma outra solução existe (ou seja, instanciar um milhão de objetos quando uma matriz de objetos teria sido mais adequado e realizado em poucas linhas de código).

A outra situação é quando eles são usados ??incorretamente, ou codificados mal. Muitas pessoas jurar fora geradores de código porque tiveram más experiências devido a bugs, ou sua incompreensão de como configurá-lo corretamente.

Mas, em si e por si, geradores de código não são ruins.

-Adam

Eles são como qualquer outra ferramenta. Alguns dão melhores resultados do que outros, mas cabe ao usuário saber quando usá-los ou não. Um martelo é uma ferramenta terrível se você está tentando parafuso em um parafuso.

Esta é uma daquelas questões altamente controversas. Pessoalmente, acho que os geradores de código são realmente ruins devido ao código porcaria unoptimized maioria deles colocar para fora.

No entanto, a questão é realmente uma que só você pode responder. Em muitas organizações, o tempo de desenvolvimento é mais importante do que a velocidade de execução do projeto ou até mesmo manutenção.

Nós usamos geradores de código para classes de entidade de dados de geração, objetos de banco de dados (como gatilhos, procedimentos armazenados), proxies de serviço etc. Em qualquer lugar que você vê muito código repititive seguindo um padrão e muito trabalho manual envolvido, geradores de código pode ajudar. Mas, você não deve usá-lo muito, na medida em que a manutenção é uma dor. Algumas questões também surgem se você quiser regenerá-los.

Ferramentas como o Visual Studio, CodeSmith têm os seus próprios modelos para a maioria das tarefas comuns e facilitar esse processo. Mas, é fácil de rolar para fora em seu próprio país.

Ela pode realmente tornar-se um problema com manutenção quando você tem que voltar e não consigo entender o que está acontecendo no código. Por isso muitas vezes você tem que pesar o quanto é importante para começar o projeto feito rápido em comparação com fácil manutenção

manutenção <> processo fácil ou rápido de codificação

Eu uso My Generation com espaços de entidade e não tenho qualquer problema com ele. Se eu tiver uma alteração de esquema Eu só regenerar as classes e tudo funciona muito bem.

Eles servem como uma muleta que pode desativar a sua capacidade de manter o programa de longo prazo.

Os primeiros compiladores C ++ foram geradores de código que cuspir código C (Cfront).

Eu não tenho certeza se este é um argumento a favor ou contra geradores de código.

Eu acho que Mitchel atingiu-o na cabeça. geração de código tem o seu lugar. Existem algumas circunstâncias em que é mais eficaz para ter o computador fazer o trabalho para você! Pode dar-lhe a liberdade de mudar de idéia sobre a implementação de um componente em particular quando o custo de tempo de fazer as alterações de código é pequena. Claro, ainda é provavelmente importante compreender a saída do gerador de código, mas nem sempre. Tivemos um exemplo em um projeto acabamos onde um número de C ++ os aplicativos necessários para se comunicar com um aplicativo C # tubulações sobre nomeados. Era melhor para nós usar pequenos, simples, arquivos que definiram as mensagens e têm todas as classes e código gerado para cada lado da transação. Quando um programador estava trabalhando no problema X, a última coisa que eles precisavam era de se preocupar com os detalhes implentation das mensagens e o acerto de cache inevitável que implicaria.

Esta é uma questão de fluxo de trabalho. ASP.NET é um gerador de código. O mecanismo de análise XAML realmente gera C # antes que ele é convertido em MSIL. Quando um gerador de código torna-se um produto externo como CodeSmith que é isolado de seu fluxo de trabalho de desenvolvimento, cuidados especiais devem ser tomados para manter seu projeto em sincronia. Por exemplo, se o código gerado é emitido ORM, e você fizer uma alteração para o esquema de banco de dados, você terá que abandonar ou completamente o gerador de código ou então aproveitam C # 's capacidade para trabalhar com classes parciais (que permitem adicionar membros e funcionalidade de uma classe existente sem herdar-lo).

Eu, pessoalmente, não gosto da natureza isolada / Alt-Tab dos fluxos de trabalho de geradores; se o gerador de código não faz parte do meu IDE, então eu sinto que é um truque. Alguns geradores de código, como entidade Espaços de 2009 (ainda não lançado), estão mais integrados do que gerações anteriores de geradores.

Eu acho que a panaceia para o finalidade de geradores de código pode ser apreciado nas rotinas pré-compilação. C # e outras linguagens .NET falta deste, embora ASP.NET gosta do que faz e é por isso que, digamos, SubSonic funciona tão bem para ASP.NET, mas não muito mais. SubSonic gera código C # em tempo de compilação pouco antes das normais ASP.NET compilação entra em ação.

Pergunte ao seu ferramentas fornecedor (ie Microsoft) para apoiar rotinas pré-compilação mais profundamente, de modo que os geradores de código podem ser integrados no fluxo de trabalho de suas soluções utilizando metadados, ao invés de gerenciados manualmente como arquivos de código outputted externamente que têm de ser mantidos isoladamente.

Jon

A melhor aplicação de um gerador de código é quando todo o projeto é um modelo, e todo o código fonte do projeto é gerado a partir desse modelo. Eu não estou falando UML e porcaria relacionado. Neste caso, o modelo de projeto também contém código personalizado.

Em seguida, os únicos desenvolvedores coisa tem que se preocupar é o modelo. Uma mudança arquitectura simples pode resultar em modificação imediata de milhares de linhas de código fonte. Mas tudo permanece em sincronia.

Esta é IMHO a melhor abordagem. Soar utópico? Pelo menos eu sei que não é;) O futuro próximo dirá

Em um projeto recente que construímos nosso próprio gerador de código. Geramos todo o material base de dados, e todo o código base para nossas classes do controlador e Vista. Embora o gerador levou vários meses para construir (principalmente porque esta foi a primeira vez que tinha feito isso, e nós tivemos um par de falsos começos) que se pagou a primeira vez que ele correu e gerou a estrutura básica para todo o aplicativo em cerca de dez minutos. Isso foi tudo em Java, mas o Ruby é uma excelente linguagem de escrever código especial para, one-off projectos do tipo pequenas. A melhor coisa foi a consistência do código e da organização do projeto. Além disso, você tipo de ter de pensar a estrutura básica para fora antes do tempo, o que é sempre bom.

Geradores de código são grandes assumindo que é um gerador de código bom. Especialmente trabalhando c ++ / java que é muito detalhado.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow