DEV Community: Alex Almeida

Duplicar código é um problema?

Alex Almeida — Wed, 30 Oct 2024 21:48:14 +0000

Quando você está escrevendo código, procurando uma solução elegante, ou não, para algum problema de código, ou de arquitetura, a pergunta que deveria ser feita é: alguém já enfrentou esse problema antes? Existe uma grande chance que sim, que este problema já tenha uma ou mais soluções padronizadas que o resolvam. Como desenvolvedores temos que ser eficientes, e nada melhor que usar o conhecimento alheio 😄

O problema

Você trabalha em uma instituição financeira, que tem um serviço onde pode-se fazer transferências internacionais. Os desenvolvedores do app precisam mostrar a listra de transações realizadas num período, e para cada item da lista você pode clicar e ver mais detalhes daquela transação.

Do lado do backend, você tem as seguintes entidades:

Poderia até ter mais atributos cada uma dessas entidades, mas não precisamos entrar afundo nesse detalhe.
A resposta do endpoint para listar transações será simples, nome do beneficiado, tipo de transação, valor enviado e data. Como vc resolve isso?

Uma possível solução

Existem muitas maneiras de se resolver um problema, pode-se simplesmente trazer os dados do banco, converter-los para seu modelo, se estiver usando algum ORM, e deixar disponível para consumo no formato JSON, vai funcionar, sim, é o ideal? Vamos falar mais sobre.

Essa maneira de resolver traz pelo menos dois potenciais problemas:

O primeiro que é mais fácil de ver, tem muita informação que é irrelevante para aplicação cliente, pelo menos nesse contexto. Então vc pensa: ah é só a aplicação que estiver consumindo ignorar o que não precisa. Eu entendo, mas perceba que vc está desperdiçando recursos, o que vc pede e não usa é desperdício.
Esse talvez também seja fácil de pegar, mas a princípio, talvez não seja importante, dependendo do caso. Expor seus modelos internos de forma pública vai tornar a manutenção ao longo prazo extremamente difícil. E por que? Se precisar mudar a estrutura de dados, como renomear um campo, isso vai gerar uma quebra de contrato com o mundo exterior, quem está consumindo essa estrutura. Aquele campo que tinha um nome X agora é XX, pronto, quebrou as aplicações consumidoras.

Outra maneira é criar um novo modelo que tenha exatamente as informações que são necessárias, soa melhor, não acha?

Então vamos criar uma classe que represente esses dados.

// DTO para listar transações
public record TransacaoListaDTO(
    string NomeBeneficiario,
    string TipoTransacao,
    decimal ValorEnviado,
    DateTime Data
);

O que acabamos de criar agora é uma classe que define o que chamamos de Data Transfer Object [Fowler PoEAA], mais conhecido como DTO, que funciona como uma interface de entrada e saída de uma aplicação, Se pensarmos em uma API REST que retorna um JSON, é esse objeto que será serializado na saída e também é usado como dados de entrada, para criar ou atualizar um recurso. Porém DTOs não se limitam a API REST, pode ser usado em qualquer outro tipo de integração.


// Pode-se ter um controller mais ou menos assim

public class TransacoesController : ControllerBase
{
    [HttpGet]
    public ActionResult<TransacaoListaDTO[]> ListarTransacoes()
    {
        // Lógica para buscar transações
        var transacoes = _repositorio.ObterTransacoes():

        var dtos = transacoes.Select(ts =>
        {
            new TransacaoListaDTO(
                NomeBeneficiario: $"{ts.Beneficiario.Nome} {ts.Beneficiario.Sobrenome}",
                TipoTransacao: ts.TipoTransacao,
                ValorEnviado: ts.Valor,
                Data: ts.Data
                )
        };
        return Ok(dtos);
    }

}

Pois bem, parece ótimo, então toda vez que eu criar minhas APIs já vou criar um DTO de cara. Dependendo da complexidade do projeto e das entidades, não precisa, se as entidade do projeto são do tipo “anêmicas”, e seu endpoint é um CRUD bem simples é perda de tempo, não adicione complexidade onde não existe complexidade.

Continuando no nosso problema, existe uma funcionalidade para exibir os detalhes de uma transação, então será necessário mais dados do que no atual DTO para listar transações, nesse detalhe as informações necessárias são:

Quanto foi enviado
Qual a tarifa pra essa transação
Nome completo de quem fez a transferência
Código do banco
Nome do banco
Tipo de Conta

Então podemos simplesmente adicionar mais atributos no DTO? Claro… que não. O fato das mesmas entidades estarem envolvidas não significa que o mesmo DTO será utilizado, cada DTO serve para um propósito, o propósito do primeiro é exibir uma lista de transações, entretanto agora o propósito é dar detalhes sobre a transferência. Seria algo parecido com isso:

public record TransacaoDetalhesDTO(
    decimal ValorEnviado,
    decimal Tarifa,
    string NomeCompleto,
    string CodigoBanco,
    string NomeBanco,
    string TipoConta
);

E finalmente eu chego no título do post, existem algumas informações que são iguais, então partindo do princípio DRY, é melhor criar um DTO base e outros DTOs herdarem, certo? Não, heranças parecem boas até que vc precisa mudar algo na classe base efeitos colaterais podem ser espalhados pelas classes. Tente manter os DTOs mais isolados possível, assim garante-se que uma mudança no DTO irá afetar diretamente os consumidores daqueles DTOs, dessa forma há menos dor de cabeça quanto mudanças forem necessárias, e elas sempre aparecem.

Rolou até esse assunto em grupo de desenvolvedores onde participo se isso seria uma duplicação de código. Eu não considero uma duplicação, pra mim, para ser uma duplicação teria que sera mesma classe com os mesmos atributos, no caso apresentado nesse post as classes são parecidas, mas não iguais.

Resumindo

DTOs (Data Transfer Objects) são usados como interface de entrada e saída em APIs.
DTOs ajudam a evitar expor modelos internos e desperdiçar recursos.
Crie DTOs diferentes para propósitos distintos, mesmo que envolvam as mesmas entidades.
Evite herança entre DTOs para reduzir efeitos colaterais.
DTOs semelhantes não são considerados duplicação de código se tiverem propósitos diferentes.
Use DTOs quando necessário, mas evite adicionar complexidade desnecessária em projetos simples.

Minhas 6 dicas para resolver problemas.

Alex Almeida — Wed, 10 Mar 2021 15:41:55 +0000

Trabalhar na área de desenvolvimento é lidar com resolução de problemas a todo momento, ao longo dos anos, acabei desenvolvendo alguns hábitos para resolve-los.

Quero comentar aqui algumas dicas que uso para resolver problemas que as vezes não tenho a menor ideia de como resolver. Esses dias, me deparei com um problema de frontend, para completar usando bibliotecas que no máximo conhecia pelo nome: react, redux e react-redux.

Bora para as dicas!

1. Entenda com o que vc está trabalhando

Quando a gente olha para nossa base de código, já quer ir sentando o dedo no problema, mas as vezes é difícil de entender como nosso outro amigo desenvolvedor/a pensou, porque usou tais bibliotecas, porque o código foi escrito daquela maneira, entre outra coisas. Entender qual é a ideia por trás da biblioteca, suas funções, como ela funciona, quais problemas ela quer resolver e não sair reinventando a roda é super importante.

Como podemos descobrir isso? É o próximo passo.

2. Use a documentação oficial

Não há maneira melhor de entender os pontos citados anteriormente. Uma boa documentação irá contar a motivação por trás daquela solução, vai ter exemplos simples e práticos para que possamos ter uma visão geral, também contém documentação mais avançada da API caso seja necessário. Aliás, fique atento com a versão da biblioteca e versão da documentação, entre uma versão major e outra muita coisa pode mudar.

Enfim, é uma grande fonte de conhecimento, com esse entendimento vc poderá ir para a próxima fase.

3. Isole o problema

Sim, vc entendeu tudo, ou pelo menos uma parte importante do que aquela lib se propõe a fazer, mas quando olha pra base de código está um nojo, que vc não sabe onde começa e onde termina e vc só quer fazer uma pequena mudança, então pegue esse conhecimento e tente fazer um exemplo fora da aplicação de maneira isolada, tem várias formas de fazer isso.

Se vc esta trabalhando com frontend: React, Angular, Vue, o que seja, vc pode usar editores online, como Stackblitz, CodePen, etc.

Talvez seu problema seja desenvolvimento backend, pode-se criar um teste unitário, um teste integrado ou subir uma infra no docker, muitas possibilidades.

Nada disso deu certo, talvez vc precise do próximo passo.

4. Peça ajuda para alguém

A gente não é uma ilha e vc não está resolvendo um problema único no mundo, provavelmente vc está com um problema que muitos outros já passaram, inclusive alguém da sua própria equipe, empresa, cidade, enfim, alguém já sofreu.

Geralmente eu determino um tempo que vou trabalhar num problema, até jogar a toalha. Tem hora que damos voltas e voltas, e o simples fato de compartilhar o problema com alguém, faz que vc tenha uma nova visão do problema, e por muitas vezes ter o momento "eureka".

Se esse lampejo de luz não aparecer, essa pessoa possa te ajudar dizer: - Olha, quando isso acontecer basta fazer tal coisa, é a hora que vc faz aquela cara de "ahhhh era só isso?"

5. Aplique seus conhecimentos adquiridos

Essa é a melhor parte, parte de resolver o problema real, agora que vc já tem a faca que o queijo na mão, é aplicar o que aprendeu e fazer aquele PR maravilhoso. Pode dar alguma coisa errada? Claro que pode, foi o meu caso, eu estava tentando entender o redux, depois react e por fim, react-redux, ou seja, foi um processo de cada vez. Inclusive estava olhando uma versão diferente na documentação do que realmente tínhamos em produção, já cantei essa bola no passo 3.

Tudo resolvido, o último passo é um dos mais importantes.

6. Divida o conhecimento com os colegas

Use aquele seu exemplo isolado para explicar aos seus colegas de trabalho, ou até mesmo para o mundo, como resolveu seu problema. Além de ajudar as pessoas, vc consegue absorver melhor o conhecimento, de forma que alguém possa perguntar algo e vc saber responder com propriedade, ou no máximo gerar alguma dúvida, assim vc irá buscar mais conhecimento para solidificar o aprendizado, no final, vc só tem ganhar.

Concluindo

Esse é um processo que tenho obtido um certo sucesso, não sei se vai servir para tudo mundo, mas achei legal compartilhar, pois posso ajudar alguém. E você, tem alguma fórmula para resolver problemas?