“Software Team Leader announcing new Code Review Procedure.” by karburator.eu is licensed under CC BY-NC-SA 2.0
“Software Team Leader announcing new Code Review Procedure.” by karburator.eu is licensed under CC BY-NC-SA 2.0
Lead propondo novo procedimento de Code Review. Seria mais fácil entrar em acordo com um time menor :). (by karburator.eu is licensed under CC BY-NC-SA 2.0)

Muitas discussões, pesquisas e teorias existem sobre este tema. Encontrar o tamanho ideal para uma equipe costuma ser um desafio, porém já existe material e experiências suficientes que nos ajudam a indicar o melhor caminho e escapar de algumas armadilhas.

Podemos afirmar que o conceito de adotar equipes menores no desenvolvimento de software, por serem mais eficientes, foi popularizado com o Scrum. E do Scrum Guide temos:

Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver…


Muitos desenvolvedores assumem que uma API RESTful¹ se resume em usar os métodos POST, DELETE, PUT e GET com o retorno de códigos HTTP. Mas será que uma API assim pode ser considerada RESTful?

Quem cunhou o termo REST (Representational State Transfer) foi Roy Feilding que, dentre as várias características apontadas que definem o que é REST, a que considero uma das mais importantes é a de interface uniforme.

O que é bem comum de se observar em APIs pela Internet é que boa parte dos sistemas criam, na verdade, uma API RPC (Remote Procedure Call) em cima do HTTP…


Conhecer a linguagem de programação muitas vezes não é só essencial para criar um bom código mas também para criar bons testes.

Um destes conhecimentos que pode ser estranho para uma parte significativa dos desenvolvedores Java 8+ é a classe Clock.

Voltar no tempo com Java é bem mais simples

A classe Clock é responsável por providenciar o tempo atual, que no Java é chamado de instante (instant). Quando fazemos, por exemplo, um LocalDate.now(), o Java lê o instante do relógio do seu computador. Porém, podemos manipular este instante colocando um Clock diferente no lugar dele.

Usando o exemplo do LocalDate.now(), podemos “enganá-lo” quanto ao instante em que ele…


Recentemente fiz uma viagem para a Europa, especificamente visitando as seguintes cidades: Paris, Londres, Bruxelas e Amsterdã. Além das características mais óbvias destas cidades europeias, tais como segurança, limpeza, organização, etc, algo que me chamou muito a atenção foi a tecnologia, organização e automação empregada por eles para resolver problemas comuns a nós todos.

A ideia então é trazer um pouco do que observei e trazer a reflexão dos motivos de estarmos distantes deles em alguns aspectos. Vou distribuir tudo que observei por lá em mais de um texto, pois foram várias coisas e gostaria de comentar cada uma delas.

Check-in integrado entre as companhias aéreas


Photo by Luca Bravo on Unsplash

O PowerMock é um dos frameworks de teste unitário mais poderosos disponíveis para o Java. Seu objetivo é transpassar algumas limitações que os frameworks de testes unitários EasyMock e Mockito têm, fornecendo mais recursos para lidar com algumas situações específicas.

Estas situações incluem, basicamente, códigos que atualmente são difíceis de serem testados unitariamente. Códigos estes com algumas destas características, por exemplo:

  • Métodos estáticos que precisam ser evitados
  • Métodos privados que precisam ser testados, mas também precisam continuar como privados
  • Mockar a injeção de uma dependência quando está usando Field Injection

Entre outros.

O problema

Depois desta breve introdução, não é difícil reparar…


Photo by Chris Ried on Unsplash

Todo desenvolvedor Java que se preze, em algum momento da sua vida de programador, já criou alguma classe com o sufixo “DTO”. Normalmente estas situações incluem o transporte de informações de um ponto a outro. Nada mais justo, afinal o significado de DTO é Data Transfer Object.

Porém, existem vários contras no simples uso do sufixo DTO no nome de uma classe.

A primeira é que o sufixo “DTO” diz muito pouco sobre a responsabilidade da classe.

Por exemplo, digamos que temos um PedidoDTO usado para guardar informações de pedido. Até aqui, tudo bem. …


Por muito tempo que trabalhei com Java eu me conformei com a possibilidade de um NullPointerExceptionser um perigo iminente no código. Sempre à espreita, podendo aparecer em qualquer lugar a qualquer momento. Os nulls, indo e vindo no código, praticamente me diziam “Em algum momento você vai esquecer de me tratar!”, não havendo uma possibilidade de ter controle sobre eles sem apelar para uma programação defensiva, algo que costuma maltratar o código.

Muitos vêem o null com naturalidade no mundo da programação. …


No último texto que publiquei mencionei as vantagens de usar injeção de dependência por construtor. Entre elas estavam algumas relacionadas a criação de testes unitários. Segue o trecho mais relevante sobre o assunto no texto:

Mock é mais fácil e confiável: comparado ao injeção por campo, é mais fácil mockar as dependências em um teste unitário, porque você não precisa de nenhum contexto de mock ou uso de reflection para acessar a dependência dentro da classe. Também não será enganado por estas técnicas. Você apenas instancia a classe e passa as dependências no construtor: simples e fácil de entender.

Algumas…


Photo by Sergi Kabrera on Unsplash

Normalmente vemos nos projetos que a forma mais comum de injeção de dependências é a por campo, técnica mais conhecida como Field Injection. Veja um exemplo abaixo deste tipo de injeção usando Java e o framework Spring:

No exemplo acima, estamos injetando o serviço EnderecoService na classe PessoaService.

Basicamente, esta é a forma mais comum de injeção de dependência com Spring e, creio eu, também com outros frameworks.

Esta técnica é, sem dúvida, uma das mais usadas pelos desenvolvedores. Das possíveis explicações para a popularidade dessa forma de injeção de dependência, consigo apontar as seguintes como as mais plausíveis:


“Programming” by Fredrik Walløe

Uma boa prática conhecida (mas nem sempre aplicada) dentro do desenvolvimento de software é a de fazer testes unitários para cada bug encontrado no sistema.

O processo funciona mais ou menos assim:

  1. Identificar onde o bug ocorre;
  2. Fazer um teste para reproduzir o bug;
  3. Fazer a correção do bug;
  4. Verificar se o teste passa após a correção do bug.

Contudo, há vários questionamentos com relação a esta atividade:

  • Não é um exagero fazer isto para cada bug?
  • E se o cenário para reproduzir o bug for difícil?
  • E se o erro for oriundo de uma consulta ao banco de dados?

Dherik Barison

Java developer, Tech Lead, Stack Overflow enthusiast and contributor: https://dherik.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store