Refactor nosso de cada dia — The Boys Scout Rule
Senhoras e senhores, excelente dia para todos! Sejam muito bem vindos!
Gostaria de falar hoje, sobre um tema que tem muito a agregar para qualquer profissional da nossa área de desenvolvimento de software: “The Boys Scout Rule”.
É uma regra (isso mesmo, REGRA!) que nos incentiva a seguir uma das rotinas dos escoteiros:
“Always leave the campground cleaner than you found it” (“Sempre deixe o acampamento mais limpo do que você achou”).
Mas o que isso tem a ver com desenvolvimento de software?
O Robert C. Martin (carinhosamente chamado de “tio Bob” pela comunidade de desenvolvedores), autor do clássico “Clean Code” (*recomendo a leitura para todos!), faz uma referência a essa regra para nos ensinar uma boa prática para desenvolvimento de software.
“Leave the code cleaner than you found it” (“Deixe o código mais limpo do que você achou”)
Ou seja, deixe sempre o campo (o código) que você acampou (que você mexeu) sempre limpo para que os próximos escoteiros possam acampar também!
Isso significa que o código não é só seu! Tenha sempre em mente que o código, ou melhor, o produto é do time inteiro! Por isso, o espiríto de colaboração do “The Boys Scout Rule” é essencial para o nosso dia a dia!
E agora segue algumas sugestões de atividades para reforçar e incentivar essa regra no nosso dia a dia:
- Escreveu, funcionou? Legal! Agora revise o código — veja se dá pra “limpar o campo”, ou seja, a região de código que você acabou de mexer — vale lembrar que na hora de revisar não tem essa de “fugir de um pedaço do código” só porque ele não foi escrito por você. O CÓDIGO É DO TIME!:
- nome da variável, função, classe esta fazendo sentido?
- Tem código duplicado?
- Tem funções ou classes muito grandes?
- Será que não tem como fazer a mesma coisa escrevendo menos código?
2. Code Review: revise com seu time o código que você escreveu para reforçar o espiríto de colaboração. Uma coisa que gosto de incentivar: em vez de fazer aquele push ansioso para branch de development do projeto, trabalhar com pull-requests para todos revisarem o código que vai ser mergeado.
3. Menos é mais! É muito legal fazer coisas engenhosas de forma engenhosa (faz muito bem para o nosso ego, não é mesmo? kkk), mas não podemos cair na armadilha de sair criando “canhões para matar baratas”. Tente ser o mais simples possível! Sempre olhe para o código e pergunte (isso mesmo reflita!): “Será que não dá pra ser mais simples?”.
4. Tomem cuidado também para não refatorar demais! Não pode ficar muito tempo refatorando a ponto de atrasar as entregas nossas do dia a dia. Via de regra, tente focar no “pedaço” (campo) que você está mexendo. Trechos de códigos onde sua funcionalidade vai impactar. Caso perceba uma necessidade de refatorar algo mais global e mais profundo que não tenha ligação direta com a funcionalidade, deixa para outro momento (até pra não deixar seu PR gigante com coisas que não tem a ver com funcionalidade! prefira trabalhar numa outra branch e conseguir avaliar esse refactor maior/mais profundo em outro momento — não misturar com momento de revisar sobre funcionalidade)
E por hoje ficamos por aqui, pessoal!
Gostaram da filosofia? Vocês adotam no trabalho de vocês? Como vocês fazem?
Referências:
- Clean Code (Robert C. Martin)
- https://medium.com/@biratkirat/step-8-the-boy-scout-rule-robert-c-martin-uncle-bob-9ac839778385
EDIT (12/07/2020): Acrescentei mais uma sugestão sobre “o quanto refatorar”