problema 1:
- PRs grandes solução:
- 1 PBI as vezes pode virar mais de 1 PR que entrega valor (quando fizer sentido), exemplo CRUD pode ser 4 PR
- eh muito mais facil 4 pessoas terem tempo de revisar 1 PR de 30m, do que 1 pessoa revisar 1 PR de 2h
- mergear eventuais branch de release antes de ficarem muito grandes (vide cash-reserve ou gestão de contas)
- exceto quando for irrisório, nao implementar features que vão subir comentadas ou testes desligados pra adiantar algo
problema 2:
- muitas idas e vindas durante o review solução:
- se durante a implementação ficar duvida de padrões, arquitetura, etc, pergunte!
- usar boas praticas de programação, SOLID, DRY, YAGNI, etc
- auto-review antes
- apenas 2 pessoas pra fazer o review
- definir na daily os responsaveis do review
- cobrar reviews no privado dos revisores para não ter um 3º ou 4º revisores sem querer
- sinalizar oq eh sugestão e o q eh requisição
- sempre aprovar ou rejeitar após a rodada de review
- fazer mudanças que impactam muitos arquivos em PRs separados (ex: renames, mudanças de code-style, etc), pois fazer num PR de feature dificulta o discernimento durante o review do que foi alterado "de verdade"
problema 3:
- discussões de abordagem no PR (seja no macro ou no micro) solução:
- definir a solução tecnica (micro) durante o refinamento do PBI (afinal o melhor jeito q é obvio pra pessoa X nao eh pra Y)
- integrar o código aprovado e fazer sugestões de melhorias (quando grandes ou complicadas) em outro PR (no mesmo PBI)
- se as discussões de abordagem foram no inicio da codificação considerar antes de seguir, a fim de evitar retrabalho (ao inves de fazer A pra depois fazer B, se está no começo ja faz B direto)
problema 4:
- falta de integração continua (ex: problemas de rebase e chaveamento de branch em STG) solução:
- integrar na master a feature revisada e aprovada (ie., solução, codigo, testes, ta tudo ok, etc), porem com flag para não habilitar a feature em PRD
problema 5:
- code-style solução:
- sempre indentar a method chain cujo algum dos metodos tenha lambdas como parametros
- uso de uma ferramenta para formatação automatica pelo time (TODO)
- If a file happens to differ in style from these guidelines (e.g. private members are named m_member rather than _member), the existing style in that file takes precedence.