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.
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.
…
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:
Entre outros.
Depois desta breve introdução, não é difícil reparar…
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 NullPointerException
ser 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…
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, com outros frameworks.
Esta técnica é, sem dúvida, a mais popular entre os desenvolvedores. Das possíveis explicações para esta forma de injeção de dependência, consigo apontar as seguintes como as mais plausíveis:
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:
Contudo, há vários questionamentos com relação a esta atividade:
…
Java developer, Tech Lead, Stack Overflow enthusiast and contributor: https://dherik.com