rights reserved. Socializando ao redor do código e evitando o heroísmo Marcelo Palladino 8x AWS Certified | AWS Community Hero Senior Software Engineer Nubank
rights reserved. Premissas • Cada repositório possui os seus “donos(as)” • O PR deve ser atribuído automaticamente a uma pessoa que vai realizar a revisão • Deve ser impossível realizar alterações direto nos branchs que vão para produção
rights reserved. O que é um pull request? Pull request é uma ferramenta para revisar uma contribuição de código em uma base de código compartilhada antes de mesclá-la em produção
rights reserved. Como o pull request funciona? • Crie um branch no código fonte com base na versão que está em produção (normalmente main) • Implemente as suas alterações neste branch • Crie um pull request solicitando a mescla do seu branch para a branch main • Peça revisão de código aos seus pares • Após a aprovação, mescle suas alterações para o branch main
rights reserved. Por que fazer pull requests? Pull requests são a fundação da revisão de código. Revisões de código são essenciais durante o desenvolvimento de software por uma série de razões: • Minimizar riscos: Ter múltiplas pessoas olhando o código aumenta a chance de descobrir problemas mais cedo. • Melhorar qualidade e desempenho: Ter pessoas com diferentes habilidades e senioridade olhando o código contribui para que a solução final seja melhor. • Compartilhamento de conhecimento: Permite que as pessoas aprendam diferentes técnicas e as melhores práticas com base nas revisões de quem sabe mais. • Design consistente: Permite que todo time esteja alinhado com o design da solução.
rights reserved. Crie PR pequenos • Ter PR pequenos é o primeiro caminho para diminuir o tempo de revisão. • Não crie tarefas como “implementar a coisa toda no serviço x”, “Fazer”, “Testar”, “Corrigir”. • Tente seguir o princípio da responsabilidade única. Cada PR deve ser responsável por uma tarefa pequena. • É fácil criar PRs grandes. É difícil criar pequenos. Desafie-se a criar PRs pequenos.
rights reserved. Escreva descrições e títulos úteis Imagine que a pessoa que vai revisar o código não tem contexto algum sobre o que está acontecendo e que ela deve ser capaz de entender as alterações. • O título deve ser suficiente para entender o que está sendo alterado. • Escreva descrições úteis: ◦ Descreva o que está sendo alterado ◦ Explique porque o PR existe ◦ Torne claro como será feito, especialmente os efeitos colaterais
rights reserved. Adicione comentários ao PR para guiar a pessoa que fará a revisão Adicionar comentários ao seu próprio PR é uma ótima forma de fazer uma revisão e descobrir possíveis problemas antes dos seus pares. É importante notar que comentários em PRs não devem ser usados para explicar o código. Se você sentir que está explicando o código, provavelmente isso é sinal que você deveria tornar o código mais fácil de entender.
rights reserved. Por que eu deveria me preocupar em melhorar meu PR? Concluímos que PRs são uma ferramenta essencial durante o processo de desenvolvimento de software. Melhorar PRs traz benefícios a este processo: • Torna a revisão mais rápida • Melhora a mitigação de riscos • Otimiza o compartilhamento de conhecimento
rights reserved. Respeite o tempo das pessoas Seu par pode estar bloqueado e esperando pela sua revisão. Priorize a revisão de código antes de iniciar uma nova tarefa. Seja grato(a) pelo trabalho da pessoa que está submetendo a contribuição.
rights reserved. Forneça feedbacks construtivos Mesmo que você esteja revisando código, lembre-se que há humanos por trás do código. Tome cuidado com como você vai lidar com as emoções das pessoas, pois você estará falando sobre o seu trabalho. • Linguagem positiva ◦ Ao invés de: Isto está totalmente errado! Não use “_” antes dos nomes de métodos públicos. ◦ Você pode dizer: Eu sinto que estamos usando um padrão diferente do que usamos normalmente. Nestes casos usamos PascalCase (link), conforme pode ser visto aqui (link). • Compartilhamento de conhecimento ◦ Tenha certeza que você está otimizando o potencial de compartilhamento de conhecimento ao usar o PR para ensinar e aprender • Respeito às preferências ◦ Há uma linha tênue entre objetividade e subjetividade. Tenha certeza de não estar enviesado(a) pela forma que você faria uma determinada coisa ao fornecer um PR.
rights reserved. Converse com a pessoa que submeteu o PR Mesmo seguindo as melhores práticas para criação e revisão de PRs, ainda é OK ter dúvidas acerca do propósito de uma alteração. Não hesite em fazer questões diretamente para a pessoa que submeteu o PR.
rights reserved. MOB programming • Defina uma tarefa pequena • Cada pessoa vai passar uma certa quantidade de tempo no teclado (http://mobtimer.zoeetrope.com/) • As outras pessoas participam ativamente • Dívidas técnicas podem ser uma boa fonte de backlog
rights reserved. Tempo para melhorias contínuas • Defina um tempo recorrente para que o time defina como quer utilizar • Crie um backlog • Permita que as pessoas submetam temas que elas desejam compartilhar
mfpalladino
mitsuzono
oracle4engineer
yushin_n
trycycle
8maki
osyoyu
pauli
kkamegawa
layerx
wmsbill
foursue
hirotomotaguchi
andyhume
colly
myddelton
edds
destraynor
lemiorhan
thoeni
eileencodes
eitanlees
gr2m
keathley
