Code Review + RubocopFerramentas, mentalidade
e evolução do processo
[email protected]
Lucas UyezuDedicado -> IaaS -> Eng. Produto
● 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
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
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/
https://github.com/bbatsov/rubocop
4 tipos principais de cops
LINTPossíveis erros e más práticas:
● useless_assignment● debugger/pry
METRICMétricas (configuráveis) para se
aplicar ao código:
● Métrica ABC● Complexidade Perceptível
http://c2.com/cgi/wiki?AbcMetric
RAILSCops exclusivo para RoR:
● delegate● scope_args: scopes que não
estão encapsulados em procs/lambdas
StyleCops 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
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