O documento discute o que é ser um programador, enfatizando a importância da atitude ao invés de habilidades técnicas. Um bom programador deve sempre se desenvolver, dar o melhor, e gerar resultados de qualidade. A principal mensagem é que ser programador requer foco contínuo no aprendizado ao longo da vida.
1. O que é SER UM
PROGRAMADOR?
lucas boeing scarduelli / @lucasscarduelli
bom
2. Arquiteto de software
líder setor de pesquisa e desenvolvimento (P&D)
Técnico em Informática industrial (#sqn)
bacharel em sistemas de informação
pós graduado em gerenciamento de projetos
9 anos de experiência
7 anos desenvolvendo software web
lucas boeing scarduelli
scarduelli.com
@lucasscarduelli
8. … ou ainda!!! #melhordetodas
“e aquele cara que muitas vezes tem que encontrar a
melhor e mais simples solução, para um problema de
uma área que ele não conhece e de que ele não faz a
mínima ideia do porque acontece”
9.
10. somos pagos para resolver problemas…
… muitos problemas, mais muitos mesmo, todos os
dias e quase sempre pra ontem!! #napressao
11. na real … ser programador não e fácil!
mais e massa pra caramba!!!
56. nomes significativos
nos escolhemos nomes para tudo E TEMOS QUE FAZER ISSO BEM
FEITO, por isso eles devem nos dizer...
- por que existe
- o que faz
- como e usado
63. não economize nas palavras!
evite a desinformação!
evite palavras que
não são palavras
se preciso use varias
palavras
evite palavras
reservadas
o tipo não precisa
estar no nome
evite trocadilhosevite palavras que
não são palavras
use boas praticas
64. classes e métodos
nomes de classes devem ser
substantivos e não conter verbos
Veículo, Pessoa,
Cliente, Fornecedor,
Estoque, ...
nomes de métodos devem
conter verbos
calculaCusto(),
lancaEstoque(),
geraNotaFiscal(),
...
65. devem ser pequenos
“a primeira regra dos
métodos e que eles devem ser
pequenos. a segunda e que
devem ser menores ainda.”
(uncle bob)
classes menores são mais
fáceis de ler e entender o que
estão fazendo.
classe = 200 a 500 linhas
métodos <= 20 linhas
linhas <= 100 caracteres
66. métodos devem fazer uma coisa só e fazer certo!
o difícil e definir o que é uma
coisa só.
tente extrair parte do código
e dar um nome a ele.
70. dry - don’t repeat yourself
evite duplicidade de código!
reutilize seus métodos.
71. srp - principio da responsabilidade única
uma classe deve ter uma, e
somente uma razão para
mudar
72. classes devem ser coesas
poucas variáveis
cada método deve manipular
uma ou mais variáveis quanto mais variáveis um
método consegue manipular,
mais coeso ele é
coesão e a co-dependencia
entre métodos e variáveis
73. comentários
podem ser mentirosos,
mesmo sem intenção
comentários não escondem
código ruim
comentário é sinal de
necessidade de refatoração
nunca deixe um código
comentado
76. comentários podem ser uteis
mostra a intenção por trás
de uma decisão tomada
avisa aos desenvolvedores
sobre a consequência de um
trecho de código
77. formatação
formatação é importante
para a comunicação
legibilidade é importante para
mudanças futuras
métodos com conceitos
parecidos devem ficar
verticalmente próximos
ordem dos métodos
influencia na legibilidade do
código
80. code smells - fique atento a eles
comentários pobres,
obsoletos ou redundantes
métodos mortos ou que
fazem muita coisa
código comentado
responsabilidades demais ou
fora do contexto
nomes pequenos e
inexpressivos
muitos parâmetros ou
parâmetros booleanos
despadronização
números mágicos
duplicidade de código