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.

1. Como fazer um
bom design de
código em Java
Paula Santana

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

3. O que eu diria para o
meu eu junior?

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

5. JAVA 25 ANOS
O porquê do Design
1

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.

8. JAVA 25 ANOS
Boas práticas Para
Orientação a Objetos
2

9. Java == múltiplos paradigmas
JAVA 25 ANOS

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

11. Programe
voltado a
interface
JAVA 25 ANOS

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.

13. Voluntário é uma Pessoa
Herança

14. Projeto tem um Responsável
Composição

15. Favoreça imutabilidade
e simplicidade
JAVA 25 ANOS
forma =
forma =
forma é mutável

16. 1
Ela deve ser final
para evitar que
filhas permitam
mutabilidade.
Os atributos devem
ser privados.
2 3Os atributos devem
ser final.

17. Classe
imutável
Classe
mutável
4
Caso sua classe tenha composição
com objetos mutáveis, eles devem
ter acesso exclusivo pela sua
classe, devolvendo cópias
defensivas.

19. JAVA 25 ANOS
Effective Java nos
Métodos
3

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

21. JAVA 25 ANOS
Divisão de Camadas
4

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

23. JAVA 25 ANOS
Estrutura de Pacotes
5

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

26. JAVA 25 ANOS
Exceptions
6

27. Verificada
s
JAVA 25 ANOS

28. Não
Verificada
s
JAVA 25 ANOS

29. JAVA 25 ANOS
Overengineering
7

30. O que o
desenvolvedor fez
O que o projeto
pediu
O que o usuário
queria
O que é?

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

32. JAVA 25 ANOS
Fonte: Effective Java
Exemplo do que NÃO fazer

33. JAVA 25 ANOS
Qualidade em Testes
8

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
{

36. JAVA 25 ANOS
Code Style e
Ferramentas de análise
estática
9

37. Code Style
PersonalizadoQualidadePadrão
JAVA 25 ANOS
Modelos mais utilizados:

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

39. Ferramentas de
análise estática
JAVA 25 ANOS
Identificar e corrigir problemas rapidamente.
Facilita a implementação do Code Style

40. JAVA 25 ANOS
Pair Programming
10

41. Fonte: https://martinfowler.com/articles/on-pair-programming.html

42. >
Rotação dos pares
Planejamento
Presencial - Espaço fisico
Remoto - Ferramentas
O que fazer

43. >
Distrações
Microgestão
Impaciência
muitas horas de pareamento
O que NÃO fazer

44. JAVA 25 ANOS
Code Review
E
Pull Request
11

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.

49. JAVA 25 ANOS
Documentação e
Configuração
12

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

51. FONTE : GIST.GITHUB.COM/PURPLEBOOTH/109311BB0361F32D87A2

52. JAVA 25 ANOS

53. Esta tudo conectado...

54. @psanrosa13
github.com/psanrosa13
linkedin.com/in/paula-macedo-santana-dev/
JAVA 25 ANOS
JAVABAHIA.GITHUB.IO/COMO-FAZER-UM-BOM-DESIGN-CODIGO-EM-JAVA/