Limpando código gerado: Refatorar ou mapear?

8

Contexto:

Recentemente, tive que lidar com um arquivo de classe gerado pelo XSD.exe. Tinha 3500 linhas de comprimento com nomes de classe / variável ridiculamente detalhados (pense someRidiculouslyLongPrefixThenMaybeOneThingUniqueAtTheEnd- difícil de comparar de relance someRidiculouslyLongPrefixThenMaybeOneOtherThingChanged) e anotações em todo o lugar. Resumindo, levei anos para descobrir o que diabos estava acontecendo. Eu li e pensei que nunca colocaria meu nome ao lado de algo tão ... Não limpo.

Questão:

1) É uma má prática mexer com o código gerado (ou seja, limpe-o).

2) Seria melhor prática escrever um mapeador para mapear as classes geradas para minhas próprias classes agradáveis e limpas (com as quais eu poderia trabalhar com prazer)?

EDITAR:

Obrigado por todos os comentários.

Se eu realmente faria algo interessante com ele (por exemplo, se houvesse objetos de domínio que não fossem objetos de transporte), acho que os mapeia para classes 'mais limpas', o que eu teria que fazer de qualquer maneira para obter tipo de funcionalidade deles. Nesse caso, as classes são efetivamente DTOs; portanto, talvez faça sentido que a nomeação corresponda aos elementos correspondentes. Como afirmado, não preciso tocá-lo - apenas para ligar para acessadores / mutadores antes de passar os dados para outra camada para processamento.

Por enquanto, acho que vou deixá-los em paz.

refactoring clean-code

— Tom Tom
fonte

Por que você teria que olhar (e muito menos alterar) o código gerado? Além de depurar o gerador de código, mas esse não parece ser o caso.

Eles eram as definições de classe. : |

— Tom Tom

2

Sim, entendi, mas o fato de ser gerado significa que ninguém (mais uma vez, exceto talvez o autor do gerador de código) deve ter que olhar para o código gerado. Ligue para ele, sim (se os nomes de classe / método o irritarem, você não pode escrever um adaptador que isola a feiura?), Mas não olhe para ele.

teve exatamente o mesmo problema com xsd- foi com 2

— jk.

Ponto tomado, delnan. Eu vou lidar com os nomes sem me sentir muito sujo. Afinal, eu não os escrevi.

— Tom Tom

14

O perigo de refatorar o código gerado para aprender e arrumar é que, se ele for regenerado novamente pela ferramenta por você ou por outro desenvolvedor, as alterações serão perdidas.

Sua equipe pode se colocar em uma posição em que você geraria o código em outro arquivo, copiá-lo para a versão limpa e refatorar para aplicar as alterações, o que leva tempo e recursos. (Eu estive lá com a versão original do Entity Framework.)

Se você não conseguir conviver com os nomes gerados, altere a fonte gerada ou faça o que você sugere no item 2.

— NikolaiDante
fonte

4

A única vez que você deve editar o código gerado é se você tem certeza de que não precisará gerá-lo novamente NUNCA. Se você tentar confiar em edições manuais e precisar gerar novamente, certamente perderá algo ao longo do caminho.

— precisa saber é o seguinte

A sobrecarga de manutenção é definitivamente o desagregador - obrigado.

— Tom Tom

1

@MichaelKohne Então, três semanas depois, os requisitos mudam um pouco e você precisa mudar de qualquer maneira. = P

— Izkata

10

Como regra geral, nunca toque no código gerado, pois isso significa prometer que você nunca mais o gerará novamente ou terá que refazer todas as alterações feitas. Se você deseja que o código gerado fique mais bonito, é necessário automatizar a geração e a limpeza do código; por exemplo, se você gerar um arquivo XML em algum lugar, convém executá-lo xmlindentcomo parte do seu processo de construção.

Por razões semelhantes, o código gerado não pertence ao controle de origem. Você coloca os dados e as regras sob controle de origem e permite que o script de construção lide com a geração de código.

Quaisquer alterações no código gerado precisam passar pelo gerador de código, ou seja, se você deseja que o código gerado pareça diferente, altere as entradas do gerador de código, o próprio gerador de código ou aplique o pós-processamento com script. Mas não edite manualmente.

Uma exceção são os geradores de código no estilo 'andaimes', onde você executa o gerador uma vez para fornecer um esqueleto a partir do qual você constrói mais. Com eles, você nunca executará o gerador novamente para o mesmo arquivo; portanto, basta tratar o arquivo gerado como um arquivo de origem regular e esquecer que ele vem de um gerador.

— tdammers
fonte

Pontos interessantes RE: controle de origem / processo de construção. Hmm. (Desculpe, ainda não posso marcar com +1 - tive que criar uma nova conta: $) #

— Tom Tom Tom '

Observe que, às vezes, o código gerado é bastante caro para criar. Por exemplo, se ele verifica o banco de dados e você tem um grande banco de dados, você pode não quero ter que fazer isso toda vez que você decidir fazer um novo checkout / ramo / whatever

— Earlz

3

Concordo totalmente com a resposta de @NikolaiDante (+1).

No dotnet / c #, você tem o conceito de "classes parciais": o código-fonte para a "classe usar" consiste em 2 arquivos separados, uma parte gerada e uma parte adicionada / editada manualmente. Suas api-embeautifications vão para o arquivo "manual" que não será sobrescrito pelo codegenerator.

No mundo java / hybris, eles usam herança para o código não gerado:

Você tem, por exemplo, uma classe Customer com suas "API-embelezamentos" herdadas de "GeneratedCustomer".

— k3b
fonte

É uma solução interessante, mas temo que permaneça no domínio de uma sobrecarga de manutenção (escrevendo / atualizando classes de wrapper para cada alteração no código gerado). Mas obrigada!

— Tom Tom