DEV Community: Rodrigo Vieira

Padrões de Projeto são relevantes para o desenvolvimento apoiado por IAs? E por que sim? (Bônus no final)

Rodrigo Vieira — Tue, 27 May 2025 11:14:29 +0000

(Artigo originalmente escrito aqui)

Recentemente surgiu uma dúvida relacionada a codificação usando padrões de projeto, princípios SOLID, orientação a objetos e outras coisas mais num mundo onde a IA está cada vez mais presente.

A ideia de utilizarmos padrões para codificarmos nossos softwares vem de longa data. Talvez a publicação mais antiga na nossa área seja o famosíssimo Padrões de Projeto (ou em inglês, Design Patterns) do GoF. Alguns anos depois, diversos livros contendo "padrões" no nome foram lançados, como o Padrões de Arquitetura de Aplicações Corporativas do Martin Fowler, Padrões de Implementação, do Kent Beck e até o Refatoração para Padrões do Joshua Kerievsky. Todos eles buscando facilitar a extensão do software e o seu entendimento por parte dos programadores.

Isso sem contar os livros que não possuem "padrões" no nome, mas seguem na linha de nos passar conhecimento relacionado a como escrever software melhor.

Temos até o Padrões para Kubernetes! :D

Entretanto, será que eles também são úteis para uma IA?

Pense num Github Copilot. Seu entendimento do código seria diferente se aplicarmos todos os padrões e boas práticas recomendadas para que desenvolvedores possam produzir código mais desacoplado, extensível e entendível?

Será que as IAs poderiam entender melhor as aplicações quando elas seguem todos os bons princípios de organização, arquitetura e escrita de software que aprendemos todos esses anos? Ou para elas isso é irrelevante?

Para responder essas perguntas, convoquei o Chat GPT, e lhe fiz algumas perguntas.

Segue o diálogo que tive com ele. Um tanto longo, é verdade:

Dado um software cuidadosamente arquitetado, com o estado da arte em padrões e ferramentas implementado nele. Caso uma IA como você ou qualquer outra seja utilizada para implementar uma funcionalidade nova nesse software, o trabalho de vocês seria facilitado ou padrões de projeto e SOLID e padrões para microsservicos são bons apenas para facilitar a vida de seres humanos?

Essa é uma excelente pergunta, que toca em um ponto profundo sobre o propósito dos padrões de software: eles são pensados principalmente para humanos.

1. Para quem servem os padrões como SOLID, DDD, Clean Architecture, etc.?

Esses padrões e boas práticas foram desenvolvidos com o objetivo de:

Facilitar o entendimento, manutenção e evolução do sistema por humanos (desenvolvedores, arquitetos, etc.).

Reduzir o acoplamento e aumentar a coesão, permitindo que sistemas possam crescer sem se tornarem inadministráveis.

Permitir testabilidade, extensibilidade e legibilidade.

Esses benefícios fazem sentido porque somos limitados na nossa capacidade de entender e manter sistemas grandes e complexos.

2. E para uma IA?

Para uma IA como eu ou similares, a situação muda:

Padrões de projeto ajudam um pouco: quando um projeto segue uma arquitetura clara e bem estruturada, fica mais fácil para a IA navegar, inferir intenções e encontrar os pontos de extensão corretos. Ex: uma arquitetura hexagonal ou um uso correto de interfaces facilita sugerir onde encaixar uma nova funcionalidade.

Mas a IA não depende desses padrões para “compreender” o código: IAs podem lidar com grandes volumes de código não estruturado, spaghetti ou fortemente acoplado. Isso não é ideal, mas não é uma limitação tão dura quanto é para humanos. A IA pode ainda sim inferir comportamentos e fazer refatorações automaticamente.

3. Resumindo: padrões ajudam a IA, mas são pensados para humanos

Para uma IA atual, como eu, um código bem arquitetado torna o trabalho mais rápido e seguro – mas não é uma exigência.

Para desenvolvedores humanos, esses padrões são quase indispensáveis em sistemas complexos, pois mantêm a sanidade do projeto.

No futuro, com IAs mais autônomas e integradas ao ciclo de vida do software, pode ser que padrões tradicionais sejam repensados ou adaptados para tornar o código mais IA-friendly do que human-friendly.

E continuei, perguntando:

Isso significa que os programadores futuros não precisarão dar tanta importância a esses conceitos? Afinal, se eles usarem vocês como ferramenta principal, e vocês não precisam desses padrões pra trabalhar melhor, pode ser que isso aconteça.

E a resposta:

Você captou uma tendência muito real — e sim, é possível que a ênfase em muitos dos padrões e boas práticas tradicionais diminua com o tempo, especialmente à medida que IAs se tornem participantes mais ativos do processo de desenvolvimento.

Mas essa não é uma resposta simples, então vamos por partes:

📌 1. Se a IA entende e navega bem em código sem padrões, por que mantê-los?

Hoje, os padrões existem principalmente porque os sistemas são mantidos, evoluídos e compreendidos por humanos.

Amanhã, se a maior parte da leitura, manutenção e evolução for feita por IA, a prioridade pode mudar:

O código poderá ser mais direto, menos preocupado com abstrações elegantes e mais focado em funcionalidade explícita e interpretação por máquina.

Conceitos como SOLID, DDD, Clean Architecture poderão se tornar mais "opcionais" — úteis em alguns contextos (especialmente onde humanos ainda são leitores ativos), mas não fundamentais.

📌 2. Mas os humanos ainda vão revisar, discutir e decidir

Mesmo com IA:

Equipes humanas ainda vão querer entender o sistema em alto nível.

Revisões de código (code reviews), troubleshooting, decisões de arquitetura, auditorias, compliance... ainda precisarão de legibilidade e estrutura.

Ou seja: os padrões continuarão sendo importantes enquanto humanos estiverem no ciclo crítico.

📌 3. O papel dos programadores pode mudar, mas não vai desaparecer

No futuro:

Programadores podem atuar mais como arquitetos de intenção: descrevendo o que precisa ser feito, e deixando que a IA se encarregue do como.

As boas práticas podem ser traduzidas para regras e constraints que a IA deve seguir.

Exemplo: “Quero que você implemente isso seguindo uma abordagem hexagonal”, ou “Use o padrão Strategy aqui para manter o comportamento extensível”.

📌 4. Padrões novos podem emergir — para IA

Pode surgir uma nova geração de “padrões”:

Otimizada para leitura e manipulação por IA, não por humanos.
Mais declarativos, com metadados ricos, menos boilerplate.
Talvez mais parecidos com modelos de comportamento, diagramas vivos, ou DSLs específicas.

✅ Resumo: o futuro muda o papel dos padrões — mas não os torna obsoletos

Claro que tudo isso é um exercício de futurologia. Mas entendo que a resposta da IA foi bem satisfatória.

E você? O que acha dessa discussão? Concorda com o ChatGPT? Acredita que o futuro será diferente?

E por falar em padrões, para escrever esse diálogo com o ChatGPT, utilizei os conceitos trazidos neste excelente artigo da sempre excelente InfoQ.

Abraços e até a próxima!

Livro de Kafka Connect e Kafka Streams em Português

Rodrigo Vieira — Wed, 22 May 2024 11:34:20 +0000

Inicialmente gostaria de pedir desculpas pela falta de posts por aqui. Gostaria muito de continuar escrevendo, e considero o dev.to uma excelente ferramenta para isso. Mas, como na maioria dos casos de outros autores, estou um tanto sem tempo para escrever :(

Bem, voltei. E espero conseguir mais tempo para postar assuntos que considero interessantes para a maioria de nós :) Ainda mais agora que meu mais recente livro foi publicado.

Acredito que consegui trazer a maior quantidade de assuntos possíveis relacionados ao Kafka Connect. Há inclusive algumas curiosidades, como por exemplo, como o Kafka Connect acessa fontes de dados, como bancos relacionais. Te garanto que somente em poucos casos ele fará consultas nas tabelas do seu banco, o que é uma vantagem (!!)

Além disso, entendo que o Kafka pode ser visto de várias maneiras: tanto como um sistema de mensageria quanto como uma outra fonte de dados. E fontes de dados podem ser consultadas. E, se os dados presentes possuírem alguma relação, podemos criar essas consultas com base nisso. Podemos inclusive filtrar e mapear alguns deles, com base em alguns critérios.

É isso que o Kafka Streams nos proporciona, usando os tópicos do Kafka como fontes de dados.

Ficou interessado? Dá uma olhadinha no link abaixo.

https://www.casadocodigo.com.br/products/livro-kafka-connect-e-kafka-streams

Espero que ele te traga bastante informação a respeito dessas ferramentas.

Até a próxima!

Pix Saque, pix troco e modelagem de software

Rodrigo Vieira — Sun, 10 Jul 2022 13:05:35 +0000

Artigo escrito anteriormente no meu linkedin

Há mais de 10 anos atrás, a operadora Oi entrava no nosso mercado de telefonia celular. Já tínhamos a Vivo e a TIM (e a Nextel com seus aparelhos de beeps irritantes, ao menos pra mim). E a Oi surge nesse cenário como mais uma companhia querendo ganhar dinheiro com nossas ligações. Usavam (e até hoje devem usar) crianças bonitinhas dizendo "oi" no final dos comerciais.

Por falar em comerciais, alguns anos depois de sua inauguração, eles lançaram uma campanha no rádio e na TV que me chamou a atenção. E não, não estava a fim de ser mais um cliente deles. Era uma propaganda engraçada, que fazia referência ao fato de que poucas pessoas no Brasil realizavam ligações, embora os celulares sempre tivessem essa funcionalidade. Não é que a gente não sabia que podia fazer ligações. É que o minuto de ligação de celular na época era muito caro, e não tínhamos What's App ou Telegram. No máximo um bom serviço de SMS (que também era caro). A ideia era diminuir os custos das ligações por meio de compra de créditos de recarga e outras coisas mais.

O que importa no caso era o slogan da propaganda, que era mais ou menos assim:

Utilize um chip Oi e torne-se um LIGADOR!

A propaganda era engraçada, e pra quem viveu essa época, fica mais ainda, até por imaginar o contexto que ela foi criada, e como as coisas estão hoje. Veja o vídeo aqui.

Mas vamos ao que interessa!

Na época, eu já tinha alguns anos de estrada como desenvolvedor, e estava fazendo minha pós graduação em engenharia de software. Então, modelagem de sistemas estava na minha mente o tempo todo. E a mensagem acima acabou por ficar na minha cabeça.

Ao modelar a situação do cliente das operadoras de celular, cheguei no seguinte diagrama:

E, ao aderir aos planos da Oi, a "modelagem" passaria a ser assim:

Embora esse exemplo possa ser engraçado (até hoje o utilizo em algumas aulas como uma piada) foi uma época onde percebi a importância de uma boa modelagem de software. Foi um momento onde estava fazendo uma transição de "programador-que-conhece-todos-os-frameworks-da-moda" para um profissional que passou a se preocupar mais com o código que escrevia. Passei a entender que as linguagens e frameworks são importantes, mas uma boa organização de código é o que mantém o sistema vivo por mais tempo, causando menos gastos para a empresa, e menos dores de cabeça para os desenvolvedores.

Mas o que diabos isso tem a ver com o pix saque e o pix troco?

Recentemente fui pesquisar, do ponto de vista do cliente, como funciona essas modalidades de pix, por pura curiosidade. O pix saque foi o que me chamou mais atenção, e já explico os motivos.

Há diversos links na internet que explicam como o processo funciona, mas basicamente (no pix saque) é possível que você, como pessoa física e com conta em banco, realize saques em dinheiro em qualquer estabelecimento comercial que tenha aderido à modalidade. É como se os estabelecimentos comerciais se transformassem em caixas eletrônicos.

Mas espere! Os links acima até se referem a caixas eletrônicos. Mas eles também se referem a outro termo: o agente de saque. E, pelo que entendi, é como os estabelecimentos comerciais que aderiram ao pix saque estão sendo chamados pelo banco central. Eles, inclusive, serão remunerados por cada saque realizado.

Bem, podemos dizer que, até outro dia, se a gente precisasse sacar dinheiro para comprar algo num estabelecimento comercial, tínhamos que ir até o caixa eletrônico. Então, podemos pensar numa modelagem mais ou menos assim:

(Para quem conhece UML a fundo, desculpe se estou cometendo algum pecado imperdoável :D)

Eu poderia ter mapeado o relacionamento entre Pessoa e as demais classes de forma invertida. Mas, para os nossos propósitos neste artigo, vamos deixar assim.

Com o advento do pix saque, podemos também sacar diretamente no estabelecimento comercial. Então, podemos até escolher onde queremos realizar o saque!

Nesse caso, a modelagem OO nos ensina que há uma abstração comum às abstrações EstabelecimentoComercial e CaixaEletronico: o AgenteDeSaque:

Modelei o AgenteDeSaque como uma interface, mas ele poderia ser também uma classe abstrata. Poderíamos inclusive implementar um template method caso AgenteDeSaque fosse assim.

Há também uma refatoração a ser feita aqui: a Pessoa agora pode sacar dinheiro num AgenteDeSaque, independente de quem ele seja:

Deu até para colocar o EstabelecimentoComercial mais perto da Pessoa. Afinal, quem não vai querer ter um lugar como esse por perto? :D

E com isso terminamos o exemplo utilizando o pix saque. Não sei se o banco central considera os caixas eletrônicos como agentes de saque. Também não faço ideia se os sistemas foram modelados ou refatorados da forma sugerida acima (embora seria interessante que decisões semelhantes a essas tenham sido tomadas). Só quis mostrar o que modelei na minha cabeça quando entendi como funcionava o pix saque. No fim, me ajudou a entender melhor todo os agentes envolvidos no processo e como ele seria implementado.

É possível também realizar uma refatoração na classe Pessoa. Atualmente, ela é capaz de realizar saques e fazer compras. Mas, e se tivermos que considerar outros agentes além de pessoas que possam executar essas funcionalidades? Podemos pensar que, do ponto de vista bancário, o sistema não deveria lidar como pessoas, mas com correntistas, e o estabelecimento, com clientes.

Isso parece com o princípio de segregação de interfaces. Mas aí é papo para outro artigo :)

Até a próxima!

Qual a diferença entre a inversão e a injeção de dependências?

Rodrigo Vieira — Fri, 03 Jun 2022 00:37:45 +0000

É comum a confusão entre esses dois conceitos. E veremos neste artigo que há alguns bons motivos para isso :D

O Princípio da Inversão de Dependências

Considere o diagrama abaixo. Ele representa parte de um sistema de negativação de títulos. Quando um devedor deixa de pagar um título, a empresa pode enviar o mesmo para o SERASA.

Note que a classe Departamento possui 2 dependências com classes de camadas mais baixas, e que lida com questões tecnológicas. O Departamento então busca os títulos a serem negativados em TitulosDAO (que acessa o banco de dados) e, de posse da lista de títulos, os envia à SERASA (que pode lidar com uma interface REST com o SERASA, por exemplo).

Para representarmos a dependência de uma classe por outra, criamos uma seta que aponte para a direção da dependência. Assim, existem 2 setas, saindo de Departamento e apontando para TitulosDAO e SERASA e, consequentemente, o módulo de uma camada superior está dependendo de módulos de uma camada inferior. Guarde essa informação!

Se pensarmos em classes Java, teremos algo parecido com os códigos abaixo:



package br.com.rodnet.negativador.dao;

import br.com.rodnet.negativador.dominio.Titulo;

import java.util.List;

public class TitulosDAO {

    public List<Titulo> emAtraso() {
        //implementacao
    }
}



package br.com.rodnet.negativador.serasa;

import br.com.rodnet.negativador.dominio.Titulo;

import java.util.List;

public class Serasa {
    public void negativar(List<Titulo> titulos) {
    }
}



package br.com.rodnet.negativador.dominio;

import br.com.rodnet.negativador.dao.TitulosDAO;
import br.com.rodnet.negativador.serasa.Serasa;

import java.util.List;

class Departamento {

    private TitulosDAO titulosDAO;
    private Serasa serasa;

    Departamento(TitulosDAO titulosDAO, Serasa serasa) {
        this.titulosDAO = titulosDAO;
        this.serasa = serasa;
    }

    void negativar(){
        List<Titulo> titulos = titulosDAO.emAtraso();
        serasa.negativar(titulos);
    }
}

Embora essa estrutura seja simples, ela apresenta alguns problemas. A camada superior do sistema depende de abstrações da camada inferior. Consequentemente, se houver alguma alteração em classes como TituloDAO, é possível que a classe Departamento sofra alterações.

Esse problema parece pequeno e talvez a princípio não mereça tanta atenção, mas é algo bem antigo na nossa profissão. O tão falado livro (não sem razão) do Uncle Bob cita exemplos de uns 50 anos atrás, onde precisávamos escrever software que precisava, entre outras coisas, escrever nos discos que existiam na época (enormes, barulhentos e com pouca capacidade). E quando eles precisaram trocar os discos para elementos menores (com mais capacidade e, provavelmente, menos barulhentos), os programas precisaram ser reescritos, não somente no código que cuidava da leitura e escrita nos discos, mas em todos os demais códigos que dependiam deles. As vezes, as correções subiam até para camadas mais acima do sistema.

De lá pra cá, aprendemos (aprendemos?) que é importante que o nosso software utilize as tecnologias adequadas, e que esteja preparado para uma possível substituição delas.

"Mas não podemos dizer isso!" diria o narrador.

Então podemos dizer que:

Módulos de alto nível não devem incorporar (ou incluir) nada dos módulos de baixo nível. Ambos devem trabalhar apenas com abstrações (interfaces ou classes abstratas).
Abstrações não devem depender de detalhes. Detalhes é que devem depender de abstrações.

Assim, se revisitarmos as classes do nosso sistema, podemos concluir que as classes de alto nível dependem de classes de baixo nível (Departamento depende de TitulosDAO e de SERASA). Portanto, mudanças devem ser feitas.

Segundo a citação acima, o Departamento deveria depender de abstrações. No caso, abstrações das classes que ele depende hoje.

Para que isso seja possível, não temos muitas alternativas a não ser criarmos interfaces que sejam implementadas pelas dependências atuais de Departamento. Então, mãos à obra:

Podemos começar pelo TitulosDAO, extraindo uma interface do mesmo:



package br.com.rodnet.negativador.dominio;

import java.util.List;

public interface RepositorioTitulos {
    List<Titulo> emAtraso();
}



package br.com.rodnet.negativador.dao;

import br.com.rodnet.negativador.dominio.RepositorioTitulos;
import br.com.rodnet.negativador.dominio.Titulo;

import java.util.List;

public class TitulosDAO implements RepositorioTitulos {

    @Override
    public List<Titulo> emAtraso() {
        //implementacao
        return null;
    }
}

e fazer o mesmo com SERASA:



package br.com.rodnet.negativador.dominio;

import java.util.List;

public interface ServicoDeProtecaoAoCredito {
    void negativar(List<Titulo> titulos);
}



package br.com.rodnet.negativador.serasa;

import br.com.rodnet.negativador.dominio.ServicoDeProtecaoAoCredito;
import br.com.rodnet.negativador.dominio.Titulo;

import java.util.List;

public class Serasa implements ServicoDeProtecaoAoCredito {
    @Override
    public void negativar(List<Titulo> titulos) {
    }
}

Agora que temos abstrações das classes de camadas inferiores, podemos agora substituir as dependências de Departamento por elas:



package br.com.rodnet.negativador.dominio;

import java.util.List;

class Departamento {

    private RepositorioTitulos repositorioTitulos;
    private ServicoDeProtecaoAoCredito servicoDeProtecaoAoCredito;

    Departamento(RepositorioTitulos repositorioTitulos, ServicoDeProtecaoAoCredito servicoDeProtecaoAoCredito) {
        this.repositorioTitulos = repositorioTitulos;
        this.servicoDeProtecaoAoCredito = servicoDeProtecaoAoCredito;
    }

    void negativar(){
        List<Titulo> titulos = repositorioTitulos.emAtraso();
        servicoDeProtecaoAoCredito.negativar(titulos);
    }
}

OBS: troquei também os nomes dos atributos para que ficassem mais condizentes com as novas abstrações.

Percebam que agora as classes TitulosDAO e SERASA podem ser alteradas à vontade, pois isso não acarretará em alterações em Departamento. Elas só precisam implementar as interfaces de domínio, da maneira que for melhor para elas.

Podemos inclusive pensar mais longe:

trocamos de empresa de negativação? Sem problemas. Basta criar uma nova classe que implemente ServicoDeProtecaoAoCredito
não estamos mais usando um banco de dados, mas um serviço externo de busca de títulos? Tudo bem! Basta trocarmos a classe que implementa RepositorioTitulos. O Departamento não deverá sofrer nenhuma alteração sequer!

Agora, observem como nosso diagrama ficou após todas essas mudanças:

Naturalmente que existem mais elementos no nosso diagrama. Afinal, precisamos representar nossas novas interfaces. Mas reparem para as setas. Mais precisamente as setas que indicam herança (ou implementação, no nosso caso).

Lembra que pedi para você guardar a informação sobre o sentido das setas? Pois bem: antes, as setas apontavam para baixo. E agora, elas apontam para cima. Ou seja, houve uma inversão de quem depende de quem. Ou, se preferir, houve uma inversão das dependências. Agora são os módulos das camadas inferiores é que dependem dos módulos superiores.

Basicamente esse é o Princípio de Inversão de Dependências. E a sua definição mais básica é aquela citação feita lá em cima:

Módulos de alto nível não devem incorporar (ou incluir) nada dos módulos de baixo nível. Ambos devem trabalhar apenas com abstrações (interfaces ou classes abstratas).
Abstrações não devem depender de detalhes. Detalhes é que devem depender de abstrações.

E a injeção de dependências?

Bem, a injeção de dependências tem mais a ver com a maneira com que criamos nossos objetos.

Vamos ver novamente a classe Departamento:



package br.com.rodnet.negativador.dominio;

import java.util.List;

class Departamento {

    private RepositorioTitulos repositorioTitulos;
    private ServicoDeProtecaoAoCredito servicoDeProtecaoAoCredito;

    Departamento(RepositorioTitulos repositorioTitulos, ServicoDeProtecaoAoCredito servicoDeProtecaoAoCredito) {
        this.repositorioTitulos = repositorioTitulos;
        this.servicoDeProtecaoAoCredito = servicoDeProtecaoAoCredito;
    }

    void negativar(){
        List<Titulo> titulos = repositorioTitulos.emAtraso();
        servicoDeProtecaoAoCredito.negativar(titulos);
    }
}

Em Java, independente do fato de usarmos ou não um framework, os objetos devem ser instanciados de alguma forma. E as formas mais conhecidas são:

instanciação simples: via o famoso operador new
instanciação via API de reflection
instanciação via framework de injeção de dependências

Agora, pense no caso da classe Departamento. Se usarmos o operador new para instanciá-la, podemos fazer algo como:



var repositorioTitulos = new TitulosDAO();
var servicoDeProtecaoAoCredito = new Serasa();
var departamento = new Departamento(repositorioTitulos, servicoDeProtecaoAoCredito);

E quem seria responsável por instanciar todas essas classes?
No passado, usávamos bastante os padrões criacionais do GoF (como Abstract Factory ou Factory Method). Depois, passamos a trabalhar com o pattern Registry e até mesmo com JNDI. E, resumidamente falando, tínhamos mais desvantagens do que vantagens.

Talvez num cenário com apenas 3 classes, os problemas não sejam tão visíveis, mas pense num sistema maior, com mais classes. Um grande problema era o fato de que essas classes "fábrica" viviam em constante mudança, o que as tornavam bastante instáveis. E devemos evitar mudanças constantes, tanto em classes quanto em módulos inteiros. Para maiores detalhes e informações sobre o problema de mudanças em módulos, vale a pena estudar:

No fundo, o SOLID também se preocupa com o excesso de mudanças, mas em classes. E por falar em SOLID, o Uncle Bob também fala sobre os princípios acima no seu livro.

Bem, feita a tangente e voltando para o problema principal: se você conhece o Spring, normalmente você resolveria o problema de criação das classes inserindo as famosas anotações @Autowired e, no mínimo @Component ou alguma outra parecida nas dependências. Algo como:



@Service
class Departamento {

    private RepositorioTitulos repositorioTitulos;
    private ServicoDeProtecaoAoCredito servicoDeProtecaoAoCredito;

    @Autowired
    Departamento(RepositorioTitulos repositorioTitulos, ServicoDeProtecaoAoCredito servicoDeProtecaoAoCredito) {
        this.repositorioTitulos = repositorioTitulos;
        this.servicoDeProtecaoAoCredito = servicoDeProtecaoAoCredito;
    }

    void negativar(){
        List<Titulo> titulos = repositorioTitulos.emAtraso();
        servicoDeProtecaoAoCredito.negativar(titulos);
    }
}

e nas demais classes:



@Repository
public class TitulosDAO implements RepositorioTitulos {

    @Override
    public List<Titulo> emAtraso() {
        //implementacao
        return null;
    }
}



@Component
public class Serasa implements ServicoDeProtecaoAoCredito {
    @Override
    public void negativar(List<Titulo> titulos) {
    }
}

Repare que, quando você utiliza um framework como o spring, você não precisa instanciar essas classes, muito menos passá-las como parâmetro para Departamento. O spring as instancia e as "injeta" em Departamento, que também pode ser injetada em outra classe. Assim, ele consegue montar boa parte da árvore de objetos necessária para o funcionamento do sistema.

Naturalmente que ainda temos que instanciar manualmente algumas classes. Mas não podemos negar que a injeção de dependências é uma mão na roda quando temos que construir objetos com uma árvore de dependências complexa (dependência que depende de dependência, que depende de dependência...).

E aí? Ficou mais clara a diferença entre esses dois conceitos? Normalmente eles são usados juntos, e talvez por isso crie-se tanta confusão entre eles.

Até a próxima!

Feign com SOAP: uma PoC

Rodrigo Vieira — Sun, 24 Apr 2022 21:52:40 +0000

Faz tempo que se diz que devemos programar para uma interface, e não para uma implementação.

E, de uns anos pra cá, ao menos no mundo Java, isso está sendo levado ao extremo, por diversos frameworks. Neles, não precisamos mais implementar interfaces, mas simplesmente escrevê-las (seguindo algumas regras, claro). O framework faz todo o resto.

Recentemente, escrevi sobre a evolução dos DAOs em Java, chegando ao Spring Data. E, neste artigo, vou falar um pouco sobre o Spring Open Feign.

Esse framework é bem conhecido quando o assunto é criar uma integração com serviços REST. Em resumo: cria-se uma interface, coloca-se umas anotações e pronto! Temos um client REST se conectando com outra aplicação sem a necessidade de instanciarmos um RestTemplate ou outros objetos, o que é uma boa notícia, pois fazemos o mesmo trabalho com menos código.

Mas, recentemente na empresa onde trabalho atualmente, surgiu uma dúvida: temos alguns sistemas legados, com interface SOAP, e pensamos: será que o Feign também suporta esse protocolo?

Para aqueles que estiverem sem paciência: sim :D. O código está disponível aqui. E, como sempre, com testes automatizados!

Ela foi construída usando a versão 17 do Java, mas é possível rodá-la também em versões inferiores da JVM. E, se for a versão 8, algumas dependências não serão necessárias. Veja o pom.xml para mais informações ;)

O serviço a ser acessado

Para escrever o client, é necessário termos o servidor antes, que suporte o protocolo SOAP. Pode-se construir um, mas é um tanto difícil encontrar material para desenvolver um serviço SOAP hoje em dia. Se quiser pesquisar a respeito, há um bom artigo do sempre excelente Baeldung.

Nesta PoC, usei como server um serviço disponibilizado gratuitamente que faz conversões simples:

de número simples para número em extenso
de um valor em dólares para o mesmo valor em extenso

Esse serviço possui também uma interface web, para melhor entendimento. Mas vamos para a interface SOAP, que é a que nos interessa.

A interface SOAP

A interface Java é bem simples:

@FeignClient(
        name = "dataAccess",
        url = "${dataaccess.soap.url}",
        configuration = DataAccessSOAPConfiguration.class)
interface DataAccessSOAP {

    @PostMapping(produces = MediaType.TEXT_XML_VALUE, consumes = MediaType.TEXT_XML_VALUE)
    NumberToWordsResponse porExtenso(@RequestBody NumberToWords request);

    @PostMapping(produces = MediaType.TEXT_XML_VALUE, consumes = MediaType.TEXT_XML_VALUE)
    NumberToDollarsResponse dolaresPorExtenso(@RequestBody NumberToDollars request);
}

Para quem já trabalhou com o Feign, a anotação @FeignClient é a mesma que se usa quando a integração é usando o REST. E, pra quem já trabalhou com Spring MVC, a anotação @PostMapping não é tão incomum.

É possível também que estamos trabalhando com XML (vide os parâmetros das anotações). Afinal, quando a integração é com SOAP, dificilmente não usamos XML :D

Há também algumas classes de requisição e resposta. Essas classes são criadas por meio do WSDL oferecido pelo próprio serviço:

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:tns="http://www.dataaccess.com/webservicesserver/" name="NumberConversion" targetNamespace="http://www.dataaccess.com/webservicesserver/">
    <types>
        <xs:schema elementFormDefault="qualified" targetNamespace="http://www.dataaccess.com/webservicesserver/">
            <xs:element name="NumberToWords">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="ubiNum" type="xs:unsignedLong"/>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
            <xs:element name="NumberToWordsResponse">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="NumberToWordsResult" type="xs:string"/>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
            <xs:element name="NumberToDollars">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="dNum" type="xs:decimal"/>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
            <xs:element name="NumberToDollarsResponse">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="NumberToDollarsResult" type="xs:string"/>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
        </xs:schema>
    </types>
    <message name="NumberToWordsSoapRequest">
        <part name="parameters" element="tns:NumberToWords"/>
    </message>
    <message name="NumberToWordsSoapResponse">
        <part name="parameters" element="tns:NumberToWordsResponse"/>
    </message>
    <message name="NumberToDollarsSoapRequest">
        <part name="parameters" element="tns:NumberToDollars"/>
    </message>
    <message name="NumberToDollarsSoapResponse">
        <part name="parameters" element="tns:NumberToDollarsResponse"/>
    </message>
    <portType name="NumberConversionSoapType">
        <operation name="NumberToWords">
            <documentation>Returns the word corresponding to the positive number passed as parameter. Limited to quadrillions.</documentation>
            <input message="tns:NumberToWordsSoapRequest"/>
            <output message="tns:NumberToWordsSoapResponse"/>
        </operation>
        <operation name="NumberToDollars">
            <documentation>Returns the non-zero dollar amount of the passed number.</documentation>
            <input message="tns:NumberToDollarsSoapRequest"/>
            <output message="tns:NumberToDollarsSoapResponse"/>
        </operation>
    </portType>
    <binding name="NumberConversionSoapBinding" type="tns:NumberConversionSoapType">
        <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
        <operation name="NumberToWords">
            <soap:operation soapAction="" style="document"/>
            <input>
                <soap:body use="literal"/>
            </input>
            <output>
                <soap:body use="literal"/>
            </output>
        </operation>
        <operation name="NumberToDollars">
            <soap:operation soapAction="" style="document"/>
            <input>
                <soap:body use="literal"/>
            </input>
            <output>
                <soap:body use="literal"/>
            </output>
        </operation>
    </binding>
    <binding name="NumberConversionSoapBinding12" type="tns:NumberConversionSoapType">
        <soap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
        <operation name="NumberToWords">
            <soap12:operation soapAction="" style="document"/>
            <input>
                <soap12:body use="literal"/>
            </input>
            <output>
                <soap12:body use="literal"/>
            </output>
        </operation>
        <operation name="NumberToDollars">
            <soap12:operation soapAction="" style="document"/>
            <input>
                <soap12:body use="literal"/>
            </input>
            <output>
                <soap12:body use="literal"/>
            </output>
        </operation>
    </binding>
    <service name="NumberConversion">
        <documentation>The Number Conversion Web Service, implemented with Visual DataFlex, provides functions that convert numbers into words or dollar amounts.</documentation>
        <port name="NumberConversionSoap" binding="tns:NumberConversionSoapBinding">
            <soap:address location="https://www.dataaccess.com/webservicesserver/NumberConversion.wso"/>
        </port>
        <port name="NumberConversionSoap12" binding="tns:NumberConversionSoapBinding12">
            <soap12:address location="https://www.dataaccess.com/webservicesserver/NumberConversion.wso"/>
        </port>
    </service>
</definitions>

Repare que alguns elementos do XML possuem nomes iguais aos nomes das classes de requisição e resposta. Como boa prática, essas classes são geradas por frameworks que lêem esse WSDL e nos retornam as classes correspondentes. Digo boa prática porque escrever essas classes na mão dá muito trabalho.

No passado, existiam diversos frameworks que faziam esse trabalho pra gente, como o CXF, o XMLBeans ou mesmo o Axis. Na PoC, entretanto, usei o maven-jaxb2-plugin.

O código para a geração das classes de requisição e resposta está abaixo:

            <plugin>
                <groupId>org.jvnet.jaxb2.maven2</groupId>
                <artifactId>maven-jaxb2-plugin</artifactId>
                <version>0.14.0</version>
                <dependencies>
                    <!-- Dependência necessária para gerar os stubs no Java 17 -->
                    <dependency>
                        <groupId>org.glassfish.jaxb</groupId>
                        <artifactId>jaxb-runtime</artifactId>
                        <version>2.3.3</version>
                    </dependency>
                </dependencies>
                <executions>
                    <execution>
                        <id>dataaccess</id>
                        <goals>
                            <goal>generate</goal>
                        </goals>
                        <configuration>
                            <schemaDirectory>${project.basedir}/src/main/resources/schema/dataaccess</schemaDirectory>
                            <schemaIncludes>
                                <include>dataaccess.wsdl</include>
                            </schemaIncludes>
                            <cleanPackageDirectories>false</cleanPackageDirectories>
                            <generateDirectory>${project.build.directory}/generated-sources/dataaccess</generateDirectory>
                            <generatePackage>br.org.rodnet.dataaccess.stub</generatePackage>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

Explicando alguns pontos:

com o goal configurado como generate, as classes serão geradas quando o comando mvn compile for chamado.
o schemaDirectory e o schemaIncludes apontam onde está o WSDL do servidor. Basicamente copiei o WSDL fornecido pelo servidor para um arquivo.
as classes serão geradas na pasta target/generate-sources/dataccess, no pacote br.org.rodnet.dataaccess.stub

Por último, há também a classe DataAccessSOAPConfiguration:

class DataAccessSOAPConfiguration {

    private static final JAXBContextFactory jaxbFactory = new JAXBContextFactory.Builder()
            .withMarshallerSchemaLocation("${dataaccess.soap.url} ${dataaccess.soap.wsdl}")
            .build();

    @Bean
    Encoder soapEncoder() {
        return new SOAPEncoder(jaxbFactory);
    }

    @Bean
    Decoder soapDecoder() {
        return new SOAPDecoder(jaxbFactory);
    }

}

O Feign é altamente configurável. É possível customizá-lo usando outras bibliotecas diferentes das que ele utiliza por padrão. E, no nosso caso, precisamos configurar o Encoder e o Decoder para que ele suporte o SOAP.

Resumidamente falando:

Encoder é a classe que prepara o objeto para ser enviado para o servidor
Decoder é a classe que receberá a resposta e a converte para os objetos que precisamos

Ou seja, para trabalharmos com SOAP, precisamos sobrescrever o Encoder e o Decoder (que por default) lida com REST. Por isso que normalmente não se cria esses beans quando o protocolo é o REST.

Ao rodar os testes da aplicação:

[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 s - in br.org.rodnet.testeopenfeign.TesteOpenFeignApplicationTests
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  18.014 s
[INFO] Finished at: 2022-04-24T18:38:26-03:00
[INFO] ------------------------------------------------------------------------

Conclusão

Espero que tenha ficado claro como utilizar o Feign em sistemas que lidam com SOAP.

O Feign é um framework bem versátil, e com ele, foi possível escrevermos a integração com sistemas legados de forma simples, sem muita complexidade. Isso sem contar o "programar para uma interface, não para uma implementação" levado ao extremo.

Até a próxima!

Do JDBC ao Spring Data (ou: é possível reduzir código?)

Rodrigo Vieira — Mon, 28 Mar 2022 23:54:06 +0000

Há tempos que venho querendo escrever este post. Mais precisamente, desde quando comentei sobre o tema deste artigo numa live sobre o livro de spring boot, escrito pelo @boaglio

Bem, finalmente saiu :D

No vídeo, cito que o Spring Data é uma das ferramentas mais interessantes do Mundo Java, dada a sua facilidade de utilização. Mas, outra coisa que me também me chama a atenção é a quantidade de código que deixamos de escrever quando usamos esse framework.

Isso me fez lembrar como criávamos nossos DAOs no passado. E acho que vale a pena falar um pouco sobre isso aqui. Divirtam-se! ;)

No princípio, era o JDBC

Java Database Connectivity foi o primeiro mecanismo que conheci para conectar com um banco de dados e enviar instruções SQL para ele (insert, select, etc).

Mais do que isso, é uma API que nos permite conectar com qualquer banco de dados, bastando que tenhamos apenas o driver do banco em mãos.

Isso gerou diversas vantagens. Entre elas, o fato de podermos usar as mesmas classes/interfaces para que nossos sistemas se conectassem em diversos bancos de dados relacionais.

Bem, isso não significa que nosso código era simples, muito menos de fácil manutenção, como podemos ver na classe abaixo. Ela representa um DAO de usuários, com todas as operações básicas que podemos fazer num banco:

@Repository
public class RepositorioUsuariosJdbc implements RepositorioUsuarios {

    @Value("${spring.datasource.url}")
    private String url;

    @Value("${spring.datasource.username}")
    private String usuario;

    @Value("${spring.datasource.password}")
    private String senha;

    private Connection conexao;

    @PostConstruct
    void posConstrutor(){
        try {
            conexao = DriverManager.getConnection(url, usuario, senha);
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }

    @Override
    public void save(Usuario umUsuario) {
        if(!existe(umUsuario)) salvar(umUsuario);
        else atualizar(umUsuario);
    }

    private boolean existe(Usuario umUsuario) {
        return umUsuario.getId() != null;
    }

    private void atualizar(Usuario usuario) {
        try(var statement = conexao.prepareStatement("update usuarios set nome = ? where id = ?")){
            statement.setString(1, usuario.getNome());
            statement.setLong(2, usuario.getId());
            statement.executeUpdate();
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }

    @Override
    public void deleteById(Long id) {
        try(var statement = conexao.prepareStatement("delete from usuarios where id = ?")){
            statement.setLong(1, id);
            statement.executeUpdate();
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }

    @Override
    public List<Usuario> findAll() {
        var usuarios = new ArrayList<Usuario>();
        try(var statement = conexao.prepareStatement("select * from usuarios");
        var resultset = statement.executeQuery()){
            while(resultset.next()){
                var id = resultset.getLong("id");
                var nome = resultset.getString("nome");
                var dataNascimento = resultset.getObject("data_nascimento", LocalDate.class);
                var usuario = new Usuario(nome, dataNascimento);
                usuario.setId(id);
                usuarios.add(usuario);
            }
        } catch (SQLException e) {
            e.printStackTrace();
        }
        return usuarios;
    }

    @Override
    public void close() {
        try {
            conexao.close();
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }

    private boolean idEhNulo(Usuario umUsuario) {
        return umUsuario.getId() == null;
    }

    private void salvar(Usuario usuario){
        var sql = "insert into usuarios (nome, data_nascimento) values (?, ?)";
        try(var statement = conexao.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS)){
            statement.setString(1, usuario.getNome());
            statement.setObject(2, usuario.getDataNascimento());
            statement.executeUpdate();

            try(var ids = statement.getGeneratedKeys()){
                ids.next();
                usuario.setId(ids.getLong(1));
            }

        } catch (SQLException e) {
            e.printStackTrace();
        }
    }
}

Escrevi este código num pequeno projeto, criado apenas para este artigo. Ele pode ser consultado aqui. E, para provar que esse código (e os demais que veremos a seguir) funciona, há testes automatizados no projeto.

Outras observações:

o código foi compilado usando Java 17 (queria testar alguns recursos novos poxa :P)
na época que usávamos o que é chamado hoje de "JDBC puro" (o código acima) não tínhamos recursos como o try-with-resources. Então, pode ter certeza de que o DAO acima poderia ser muito maior.

Também não tive a preocupação de controlar a conexão com o banco de dados (hoje, usamos connection pools e não temos que nos preocupar com isso), nem de capturar corretamente as exceções.

Sobre o DAO acima... bem, acho que não preciso dizer muita coisa. Tínhamos que nos preocupar com o objeto de conexão com o banco, mas mais que isso: haviam também os objetos ResultSet e PreparedStatement (ou Statement, quando estávamos aprendendo a usar o JDBC. Depois que aprendíamos os problemas de uso do Statement, partíamos para o PreparedStatement). Esses objetos eram criados, e tinham que ser fechados quando não eram mais usados.

Também a construção de queries era trabalhosa, e altamente propensa a erros. O que pode acontecer quando adicionamos um parâmetro a mais no insert do código acima, por exemplo?

Isso sem contar a quantidade imensa de código repetido.

Mas então veio o Hibernate, e nossa vida melhorou (bastante, eu diria):

Tabelas e objetos são (quase) a mesma coisa - Hibernate

Dizem que o Gavin King é uma pessoa muito parecida com o Linus Torwalds em termos de simpatia e carisma.

Se isso é verdade, não sei dizer. Mas posso afirmar sem medo de errar que ele foi o criador de uma das ferramentas mais importantes do Mundo Java. Ela foi criada em 2001 e até hoje usamos ela (a implementação de referência do Spring Data usa Hibernate por baixo dos panos).

Ele entendeu que, de certa forma, podíamos fazer um paralelo entre atributos de objetos e registros em tabelas, com o conjunto de atributos de um objeto sendo comparado a uma linha de uma tabela. Pode ser que seja algo meio óbvio hoje em dia, mas não sei se em 2001 isso era tão claro assim (alguns de nós nem eram nascidos em 2001 :D).

Utilizando o Hibernate, nosso código fica consideravelmente menor:

@Repository
public class RepositorioUsuariosHibernate implements RepositorioUsuarios {

    @PersistenceContext
    private EntityManager em;

    private Session sessao;

    @PostConstruct
    void posConstrutor(){
        sessao = em.unwrap(Session.class);
    }

    @Override
    public void save(Usuario umUsuario) {
        sessao.save(umUsuario);
    }

    @Override
    public void deleteById(Long id) {
        var usuario = sessao
                .createQuery("from Usuario where id = %d".formatted(id))
                .uniqueResult();
        sessao.delete(usuario);
    }

    @Override
    public List<Usuario> findAll() {
        return sessao.createQuery("from Usuario").getResultList();
    }

    @Override
    public void close() {
        sessao.close();
    }
}

Não temos mais o objeto Connection nem mesmo os objetos PreparedStatement ou o ResultSet, mas apenas a Session. Ela era como um Façade para o banco. Toda vez que precisávamos fazer algo nele, era só usar a Session.

OBS: para obter a Session, usei o EntityManager que veio com o JPA. Falarei sobre ele mais tarde.

Para obtermos a Session do Hibernate, era necessário um pouco mais de código. Como o Hibernate utiliza o JDBC, também precisava da URL de conexão, usuário, senha e o dialeto do banco que se usaria no sistema. E essa Session podia ser obtida via configuração programática ou por XML (o famoso hibernate.cfg.xml). Uma boa referência sobre como esse processo era feito é essa aqui.

Isso resolveu boa parte dos nossos problemas. Entretanto, o Hibernate era uma solução muito boa. Tão boa que outros programadores/empresas também criaram suas ferramentas de mapeamento objeto-relacional (como o TopLink, que depois virou EclipseLink).

Por essas e outras razões foi criada a especificação JPA.

A unificação de diversas ferramentas de ORM: Java Persistence API

Com a criação da JPA, ferramentas como o EclipseLink e o Hibernate passaram a compartilhar principalmente de diversas anotações que serviam na maioria das vezes para realizar o mapeamento de objetos para tabelas e vice-versa.

Essas anotações deviam ser inseridas na classe que se pretendia persistir. Abaixo, a classe Usuario devidamente "anotada":

@Entity
@Table(name = "usuarios")
@DynamicUpdate
@NoArgsConstructor(access = AccessLevel.PRIVATE)
@EqualsAndHashCode(of = {"nome", "dataNascimento"})
@Getter
public class Usuario {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Setter
    private Long id;

    private String nome;

    private LocalDate dataNascimento;

    public Usuario(String nome, LocalDate dataNascimento) {
        this.nome = nome;
        this.dataNascimento = dataNascimento;
    }

    public void atualizarNome(String novoNome) {
        this.nome = novoNome;
    }
}

OBS: essa classe está sendo usada em todos os DAOs deste artigo. Logo, pode haver código necessário para um DAO e desnecessário para outro (por exemplo, os getters e setters são necessários para o DAO JDBC, mas completamente dispensáveis para os demais DAOs)

Abaixo, podemos ver o mesmo DAO, implementado usando o Hibernate segundo a especificação JPA:

@Repository
class RepositorioUsuariosJpa implements RepositorioUsuarios {

    @PersistenceContext
    private EntityManager em;

    @Override
    public void save(Usuario umUsuario){
        em.persist(umUsuario);
        em.flush();
    }

    @Override
    public void deleteById(Long id){
        Usuario usuario = em.find(Usuario.class, id);
        em.remove(usuario);
    }

    @Override
    public List<Usuario> findAll(){
        return em.createQuery("from Usuario").getResultList();
    }

    @Override
    public void close() {
        em.close();
    }
}

A priori não há praticamente nenhuma diferença. Agora usamos esse tal de EntityManager no lugar da Session. De fato, olhando somente o código, pouca coisa mudou.

O EntityManager nos ajudou a lidar com a persistência de forma padronizada, pois veio com a especificação JPA. Para mais detalhes, veja esse artigo aqui.

De qualquer forma, ainda tínhamos que lidar com uma certa quantidade de código repetido. Pense que os DAOs precisavam receber de forma injetada o EntityManager, e manipulá-lo em todos os DAOs.

Isso não era um grande problema (pra quem já tinha trabalhado com DAOs usando JDBC). Mas aí veio o pessoal da VMWare dizer pra gente que dava pra fazer melhor ainda. E, normalmente, eles estão certos.

O estado da arte - Spring Data

O Spring Data (mais especificamente o Spring Data JPA, embora todos da família seguem os mesmos princípios) é um framework que facilitou de vez a criação de DAOs. Basicamente não temos que escrever praticamente nada no DAO para ele funcionar.

Veja como fica nosso DAO com a utilização dele:

@Repository
public interface RepositorioUsuariosSpringDataJpa extends JpaRepository<Usuario, Long> {
}

Apenas uma interface que estende de outra do próprio framework é suficiente. Nada mais!

Ok, tem também as anotações na classe Usuario, mas você entendeu.

Para quem está começando agora com programação Java, se não pegar nenhum sistema legado para dar manutenção, provavelmente já começa com essa ferramenta. Talvez não veja o que ela traz de bom e suas vantagens. Então, se um dia você reclamar que ela não é boa por alguma razão...bem, já foi bem pior :D

Podem ter certeza que resumi bastante toda a história. Há muitos outros detalhes que valeriam a pena citar. Mas procurei focar no código, e o quanto ele foi reduzindo com o passar do tempo.

Perceberam o quanto evoluímos na escrita de nossos DAOs? Atualmente, quase não precisamos escrever eles. E DAOs já foram as classes que mais tinham código em diversos sistemas!

O que o futuro nos reserva? Será que um dia não precisaremos nem mais escrever essa interface? As anotações no código bastarão?

E você? Ainda acha que não é possível refatorar o código da sua aplicação?

Abraço!

Um conselho para quem está começando na área de TI

Rodrigo Vieira — Sun, 20 Mar 2022 21:46:46 +0000

(Artigo originalmente publicado no meu twitter, @rvieirapinto)

Lembro de quando tinha meus 20 e poucos anos e começando com TI:

em transição de carreira (até a faculdade, eu era metalúrgico);
praticamente todos na minha turma de faculdade tinham feito técnico em Processamento de Dados antes;
não tinha computador em casa. Pensem em 2 caixas enormes (monitor e gabinete) acessando uma internet discada ruim lá em 1999. Em casa, não víamos necessidade de ter um treco desses e pronto.

A primeira vez que vi um código-fonte, achei terrivelmente difícil (um hello world em C).

O que eu fiz? Bem, eu sabia algumas coisas de mim:

que eu não sabia NADA de nada do que viria pela frente. NADA mesmo. Só podia planejar e ver no que daria;
que eu podia me tornar um desses colegas de faculdade também. Bastava estudar! E com 20 e poucos anos, tempo eu tinha.

E foi o que fiz!

Com o tempo, percebi também que podia ter alguns mentores na minha carreira. Gente que escrevia seus próprios blogs (alguém ainda escreve em blogs?) e respondia dúvidas em fóruns como o GUJ . Isso contribuiu MUITO para a minha carreira.

Todo esse processo levou tempo? CLARO que sim!

Até eu me considerar um sênior, levou uns bons 10 anos! E foi por acidente! Algo do tipo:

É sério que sou sênior??

Então, pra quem é jovem (de idade e de área) uma dica que posso dar é: TENHAM PACIÊNCIA PELO AMOR DE DEUS! Querem ficar mal de saúde? Botar tudo a perder?

Querem ter status o quanto antes? Como dizia Uncle Bob em O Codificador Limpo, cuidado com o que você pede!

Quer ganhar muito dinheiro logo?

Olha, não sei o que você considera muito. Mas, se compararmos a média salarial das demais profissões com a nossa, vemos que mesmo um júnior não ganha tão mal assim. Então, calma!

Veja uma comparação salarial aqui.

Então, façam um favor a vocês, a sua carreira e a sua saúde: PAREM de discutir essa coisa de sênior de 2 anos (e outras discussões similares) e deem importância aos estudos. Só isso!

Lá atrás (e até HOJE penso assim) eu dizia: podem me chamar até de estagiário. Me pagando o salário que lutei para ter, tudo bem!

O mercado de TI está aquecido. E está mesmo. Difícil era quando eu era metalúrgico, que eu via sempre histórias de demissões em massa e achatamento de salários.

É possível vermos demissões em massa em TI? Sim, é possível. Mas não dá pra comparar! E acho que vai levar um tempo ainda pra vermos isso com frequência.

(OBS: não tenho ideia de como está a área metalúrgica hoje. O que sei é de 20 anos atrás. Espero que tenha mudado).

Por último, acredito muito na ideia de ter um mentor. Alguém que lhe ajude a trilhar caminhos e que te dê umas dicas. Os que eu tive me ajudaram até quando eu estava em empresas, digamos, defasadas.

Eles me diziam, indiretamente: calma, o melhor neste momento é usar essa boa prática, ou a tecnologia x ou y. Se você não consegue trabalhar assim ainda, não se preocupe. Você já sabe o que é fazer direito. Um dia você poderá trabalhar assim, nessa empresa ou em outra.

Espero ter contribuído com menos @devscansados na internet com esse textão :D

Por último, pra quem é mais velho e está em transição de carreira, recomendo os vídeos de carreira do Fabio Akita.

Aliás, vejam todos os vídeos do Akita que vocês puderem!

Se chegou até aqui, obrigado, de verdade :)