Code Review + Rubocop
Ferramentas, mentalidade
e evolução do processo
lucas.uyezu@locaweb.com.br
Lucas Uyezu
Dedicado -> IaaS -> Eng. Produto
Motivadores
● Diluir conhecimento técnico e de negócios
● Rubberduck debugging
● 1 gem, técnica ou manha explicada num MR
ensina a todos
Rubberduck debugging
https://en.wikipedia.org/wiki/Rubber_duck_debugging
Rubberduck debugging
Evolução
1o. nível
Primeiros code reviews focaram em:
● tabs ao invés de espaços
● alinhamento
● if ao invés de unless
Não há impacto/valor real no produto
2o. nível
Com o tempo, passamos
naturalmente a focar em:
● sanity check
● arquitetura
● efeitos colaterais
● performance
● segurança
http://blog.fogcreek.com/effective-code-reviews-9-tips-from-a-converted-skeptic/
Arquitetura
Performance
Segurança
https://github.com/bbatsov/rubocop
4 tipos principais de cops
LINT
Possíveis erros e más práticas:
● useless_assignment
● debugger/pry
METRIC
Métricas (configuráveis) para se
aplicar ao código:
● Métrica ABC
● Complexidade Perceptível
http://c2.com/cgi/wiki?AbcMetric
RAILS
Cops exclusivo para RoR:
● delegate
● scope_args: scopes que não
estão encapsulados em
procs/lambdas
scope_args
scope_args
Style
Cops de estilo (duh)
● alinhamento de hash com n linhas
● Indentação
Plugins para Vim, Emacs,
Sublime & TextMate
● Todos os projetos usam o mesmo .rubocop.
yml
● Antes do commit, ele passa o rubocop nos
arquivos do diff.
● Se tiver erros, não rola commit.
Resultados
(Após 1+ ano)
● Conhecimento difundido: quase não existem
áreas em IaaS com 'pai'
● Cloud+Dedicado+Load Balancer + Becape +
Painel de IaaS + Client VLAN: 9 PRBs + 3
frozen
Moral da história
Muita gente ocupada,
atribuir um Deadline ao
MR e seguir em frente
Projetos antigos
rubocop -lR
Antes do "pente-fino"
Não seja xiita
(rubocop não passava no
nosso rubocop.yml)
Alarmar é mais
importante do que passar
tudo e ganhar estrela de
bom menino
Dúvidas?
Obrigado!

Tech talkrubocop