O documento fornece 12 fatores para um bom design de código em Java, incluindo: 1) o porquê do design, 2) boas práticas de orientação a objetos, 3) uso efetivo de métodos, 4) divisão adequada de camadas, e 5) testes de qualidade. O documento enfatiza a importância de um código limpo, legível e fácil de manter através do uso correto de padrões, práticas e ferramentas de desenvolvimento.
2. Paula
Nas paradas da tecnologia desde 2008
Pagando os boletos com Java desde 2014
Organizadora do Devs JavaGirl e SouJava
Microsoft MVP
Analista de Sofware Sênior na Invillia.
JAVA 25 ANOS
4. Doze fatores da Paulinha
O porquê do
design.
Effective Java
nos métodos
Boas práticas
Para Orientação
a Objetos
Divisão de
camadas
JAVA 25 ANOS
Estrutura de
pacotes
Over engineeringExceções Qualidade em
Testes
Pair Programing Code Review E Pull
Request
Documentação e
Configuração
Code Style e
Ferramentas de
anaĺise estática
6. • Modificações com:
⚬ facilidade
⚬ segurança
• Evolução com:
⚬ Menor investimento
O porquê do
Design
JAVA 25 ANOS
7. JCP
Decisões que foram tomadas ao longo dos anos
e sobre como o uso de especificações permitiu
que não houvesse vendor lock-in com bibliotecas
e apis no ecossistema Java.
10. Getters e Setters
Frameworks usam a api de
Reflection para executar
parse de dados, então não
é necessário que você crie
eles até mesmo para
objetos anêmicos, se não
for necessário.
ENUM
Use enums no lugar de
constantes, isso permite
deixar o código mais limpo.
Além Enum podem ser
classes bem ricas e podem
facilitar muito a
implementação de alguns
padrões de projeto.
Nomes
Não economize com o
tamanho do nome, desde
que ele descreva bem o
propósito do que está no
método, variável, classe,
etc.
JAVA 25 ANOS
Pequenas Grandes Ações
12. Evite herança,
favoreça
composição Não permite mudança de
comportamento em tempo de
execução
Acoplamento forte
Alteração na superclasse
impacta nas subclasses
JAVA 25 ANOS
Encapsulamento fraco
Herança
Composição
Permite definir comportamentos
complexos.
Comportamentos diferentes em
runtime.
Melhor encapsulamento.
20. public boolean helpToMethod(){
Faça Cópias
Defensivas quando
necessário
JAVA 25 ANOS
Verifique a validade dos
parâmetros
Utilize Sobrecarga com
critério
Projete assinatura de
métodos com cuidado
Retorne coleções
vazias em vez de nulas
22. Um dos grandes problemas que
desenvolvedores enfrentam no começo de
carreira é sobre a divisão de camadas da
aplicação.Existem dois conjuntos de
padrões que são essenciais para entender
estas divisões.
Possui um conjunto de princípios que
norteiam sobre a responsabilidade das
camadas no desenvolvimento de
software.
GRASP
Conjunto de responsabilidades de
classes que criamos ao longo do
desenvolvimento do software.
Patterns of Enterprise Application
JAVA 25 ANOS
24. Simples de implementar e de
entender. Não é boa em grande
escala, a medida que o projeto
cresce pode ficar complicado de
organizar e encontrar o código, além
disso não permite uma boa coesão.
PACKAGE BY
LAYER
JAVA 25 ANOS
25. Permite uma alta coesão dos
recursos e visão das
funcionalidades do sistema.
Porém sua desvantagem é sua
curva de aprendizagem, já que para
este modelo é necessário bom
conhecimento do negócio.
Escopo amplo.
PACKAGE BY FEATURE
JAVA 25 ANOS
31. Principio KISS
Keep It Simple Stupid, que
significa Mantenha de forma
estupidamente simples.
Fazer algo simples pode
demandar mais tempo do que
fazer de forma complexa.
Principio YAGNI
You aren't gonna need it, ou
seja, você não vai precisar
disso.
Este princípio afirma que uma
funcionalidade não deve ser
adicionada até que se faça
necessária.
Novas Features do Java
"Me segura que eu quero
usar ...<complete>"
disse o programador que
adora "inovar".
Cuidado no Use de Streams,
use novos recursos quando
realmente fizer sentido.
JAVA 25 ANOS
34. Quer saber se um teste vai
garantir um comportamento?
Image que haja modificação na
estrutura do seu código, em caso
que mude o comportamento seu
teste deverá quebrar, certo? Pois
então, em muitos casos os testes
continuam passando.
Passar o teste
não significa
que você tem
qualidade
JAVA 25 ANOS
35. BDD
TDD
Testes de Mutação
Testes de Unidade
Testes de Contrato
Testes de Integração
JAVA 25 ANOS
Testes de Componente
Testes end-to-end
Testes de Performance
{
38. Itens do
Code
Style do
Twitter
JAVA 25 ANOS
● ESTILO DE CODIFICAÇÃO
● FORMATAÇÃO
● DECLARAÇÕES DE CAMPO, CLASSE E MÉTODO
● NOMENCLATURA VARIÁVEL
● OPERADORES DE BLOCO DE ESPAÇO E IGUAIS
● IMPORTAÇÕES
● USE ANOTAÇÕES COM SABEDORIA
● USE INTERFACES
● ESCREVENDO CÓDIGO TESTÁVEL
● OBJETOS DE SUPORTE
● TESTANDO CÓDIGO MULTITHREAD
● TESTANDO ANTIPADRÕES
● EVITAR ALEATORIEDADE NOS TESTES
● MELHORES PRÁTICAS
● PROGRAMAÇÃO DEFENSIVA
● CÓDIGO LIMPO
● USE BIBLIOTECAS MAIS NOVAS / MELHORES
45. Pull
Request
JAVA 25 ANOS
Coloque uma boa descrição.
Motivo de algumas decisões
foram tomadas e abordagens
verificadas antes da tomada de
decisão.
Impacto das alterações.
Métricas de análise da modificação
ou links de referência.
Cards e tarefas relacionadas ao PR
46. JAVA 25 ANOS
Code
Review
Faça perguntas e comentários que agreguem.
Automatize o que for possível.
Dados e fatos técnicos substituem opiniões e preferências pessoais.
integrar ao processo existente da equipe
Melhora o nível técnico do Time.
Identificar e corrigir problemas rapidamente.
Melhora futuros planejamentos.
47. O que
analisar?
JAVA 25 ANOS
● O CÓDIGO ESTÁ BEM PROJETADO?
● O CÓDIGO ESTÁ MAIS COMPLEXO DO
QUE PRECISA SER?
● O CÓDIGO POSSUI TESTES
APROPRIADOS?
● OS TESTES ESTÃO BEM PROJETADOS?
● OS NOMES SÃO CLAROS?
● O CÓDIGO ESTÁ DOCUMENTADO
ADEQUADAMENTE?
● O CÓDIGO ESTÁ EM CONFORMIDADE
COM O GUIA DE ESTILOS ?
48. Comentários
JAVA 25 ANOS
● SEJA ATENCIOSO.
● EXPLIQUE SEU RACIOCÍNIO E USE
ORIENTAÇÕES EXPLÍCITAS, APENAS
ABORDANDO O PONTO EM QUESTÃO E
DEIXANDO O DESENVOLVEDOR
DECIDIR.
● MOTIVE OS DESENVOLVEDORES A
SIMPLIFICAR O CÓDIGO, EM VEZ DE
APENAS EXPLICAR A COMPLEXIDADE
PARA VOCÊ.
● ESPERE EXPLICAÇÕES SOBRE OS
PONTOS LEVANTADOS.
50. JAVA 25 ANOS
Documentação deve ficar no projeto.
Melhor documentação é o código.
README do projeto deve descrever o que
, onde, como e porquê.
Código > Javadoc
Externalize configuração da aplicação