Como reduzir esses problemas?<\/p>\n
<\/a>Nem todos os code reviews s\u00e3o iguais<\/h2>\nOs code reviews s\u00e3o uma excelente pr\u00e1tica para melhorar a qualidade do c\u00f3digo e diminuir o n\u00famero de erros<\/a>.<\/strong> Mas um outro benef\u00edcio, t\u00e3o importante quanto estes, \u00e9 o compartilhamento de conhecimento entre os desenvolvedores.<\/p>\nQuando eu reviso um PR (Pull Request ou Change request, dependendo da ferramenta), sinto que conhecendo o seu contexto fica mais f\u00e1cil fazer uma revis\u00e3o mais aprofundada e assertiva. D\u00favidas do tipo:<\/p>\n
\n- Essa solu\u00e7\u00e3o realmente resolve o problema?<\/li>\n
- Existem maneiras melhores de resolver o problema?<\/li>\n
- Essa funcionalidade faz sentido do ponto de vista de neg\u00f3cios?<\/li>\n
- \u00c9 vi\u00e1vel prosseguir com essa funcionalidade agora?<\/li>\n<\/ul>\n
Ficam mais mais f\u00e1ceis de serem enxergadas e respondidas. Mas, para ter essas respostas, ter um bom conhecimento sobre o neg\u00f3cio \u00e9 fundamental. Por isso, as vezes acabamos revisando apenas os PRs nos quais j\u00e1 temos contexto, sejam eles da nossa equipe ou de partes do sistema que j\u00e1 conhecemos. Se pensarmos no n\u00edvel organizacional, esse tipo de comportamento pode resultar nos problemas citados, muitas vezes dif\u00edceis de serem diagnosticados.<\/p>\n
<\/a>Apresentando a Pir\u00e2mide de Code Reviews<\/h2>\nUma pr\u00e1tica que pode ajudar a resolver esses problemas \u00e9 a Pir\u00e2mide de Code Reviews.<\/p>\n
![\"pir\u00e2mide](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2018\/07\/pyramid-1024x545.png\")
<\/p>\n
<\/p>\n
<\/p>\n
Essa pir\u00e2mide, inspirada na\u00a0Pir\u00e2mide de Testes<\/a>, nos ajuda na prioriza\u00e7\u00e3o do que devemos fazer.<\/p>\nPull Requests da nossa equipe s\u00e3o a base da pir\u00e2mide, pois s\u00e3o neles onde dedicaremos mais tempo. Como j\u00e1 possu\u00edmos o conhecimento necess\u00e1rio para fazer um bom code review, \u00e9 prov\u00e1vel que essas revis\u00f5es sejam feitas mais rapidamente. Dessa forma, ajudamos os outros desenvolvedores a entregar seu trabalho com mais qualidade mais rapidamente.<\/p>\n
No segundo n\u00edvel da pir\u00e2mide temos dois grupos de PRs: aqueles em que j\u00e1 possu\u00edmos contexto e os chamados “PRs cr\u00edticos”.<\/p>\n
Os PRs que j\u00e1 possu\u00edmos contexto s\u00e3o mais \u00f3bvios: eles envolvem uma parte do c\u00f3digo ou do neg\u00f3cio j\u00e1 conhecida pelo desenvolvedor, fazendo com que ele(a) se sinta confort\u00e1vel na revis\u00e3o. Eles n\u00e3o diferem muito dos Pull Requests do pr\u00f3prio squad, por\u00e9m como s\u00e3o externos, consideramos que haver\u00e3o outras pessoas da squad envolvida ajudando na revis\u00e3o. Por isso gastamos menos tempo neles.<\/p>\n
J\u00e1 os chamados “Pull Requests Cr\u00edticos” s\u00e3o um pouco diferentes. Esses PRs podem implementar diferentes tipos de funcionalidades, desde resolver um erro cr\u00edtico at\u00e9 mudan\u00e7as na arquitetura, e \u00e9 essencial que os desenvolvedores estejam alinhados com suas altera\u00e7\u00f5es. Esse tipo de Pull Request geralmente requer uma aten\u00e7\u00e3o imediata dos desenvolvedores, por isso \u00e9 importante separar um tempo para revis\u00e1-los.<\/p>\n
O que a pir\u00e2mide traz de diferente \u00e9 tornar expl\u00edcito que devemos inserir no nosso processo de trabalho as revis\u00f5es explorat\u00f3rias. Ou seja, n\u00e3o precisamos mais nos sentir restritos a(s) parte(s) do sistema onde trabalhamos. Pelo contr\u00e1rio, tendo a pir\u00e2mide em mente, nos sentimos incentivados a revisar outras partes do c\u00f3digo e expandir nosso conhecimento do neg\u00f3cio.<\/p>\n
Mas como come\u00e7ar por esse caminho? Ser\u00e1 que meus code-reviews ser\u00e3o bem aceitos?<\/p>\n
<\/a>Come\u00e7ando os code reviews explorat\u00f3rios<\/h2>\nAo revisar uma parte do c\u00f3digo ou do neg\u00f3cio que n\u00e3o estamos familizados \u00e9 natural nos sentir desconfort\u00e1veis ou inseguros. Podemos nos sentir desestimulados a discutir, com medo de fazer perguntas “est\u00fapidas” ou redundantes. E se n\u00e3o conhecermos muito bem os desenvolvedores envolvidos no PR isso fica ainda pior. Resumindo: sa\u00edmos da nossa zona de conforto.<\/p>\n
J\u00e1 apresentamos os benef\u00edcios dos code reviews explorat\u00f3rios, por\u00e9m como devemos proceder na hora de revisar c\u00f3digo desconhecido, onde supostamente nossa efetividade vai ser menor? E como devemos reagir quando uma pessoa de fora revisa o c\u00f3digo e come\u00e7a a fazer perguntas ou questionamentos?<\/p>\n
Como o pr\u00f3prio nome j\u00e1 diz, estamos explorando uma parte desconhecida do projeto, por isso ter uma atitude curiosa \u00e9 essencial. Fazer perguntas, dar dicas e sugest\u00f5es e compartilhar experi\u00eancias s\u00e3o \u00f3timos pontos para se ter em mente nessas revis\u00f5es. Ter bom senso tamb\u00e9m \u00e9 importante aqui, pois n\u00e3o precisamos entender todo o contexto de neg\u00f3cio logo de cara na primeira revis\u00e3o. Identificar o contexto m\u00ednimo que precisamos para fazer a revis\u00e3o \u00e9 vital para n\u00e3o onerarmos demais o nosso tempo nem o dos demais participantes.<\/p>\n
E quando recebermos esse tipo de revis\u00e3o \u00e9 importante ter uma atitude respeitosa e did\u00e1tica nos coment\u00e1rios. Perguntas devem ser respondidas sempre educadamente e com um n\u00edvel suficiente de detalhes(o bom senso vale aqui tamb\u00e9m). Respostas atravessadas ou incompletas podem prejudicar as revis\u00f5es e desestimular os revisores a continuarem com essa pr\u00e1tica. Lembre-se: ningu\u00e9m \u00e9 dono do c\u00f3digo, o c\u00f3digo que voc\u00ea est\u00e1 fazendo agora ser\u00e1 usado por outros desenvolvedores no futuro. E vice-versa. Um ambiente amig\u00e1vel durante as revis\u00f5es vai tornar essa pr\u00e1tica muito mais proveitosa para todas as partes envolvidas.<\/p>\n
E quais crit\u00e9rios devemos usar para escolher aonde vamos explorar? Bem, a decis\u00e3o final fica por sua escolha. Mas se voc\u00ea souber de alguma parte do projeto que carece de revis\u00f5es, pode ser uma boa id\u00e9ia dar uma explorada por l\u00e1.<\/p>\n
Quanto tempo devo me dedicar aos code reviews explorat\u00f3rios? Isso varia de cada contexto. Se voc\u00ea tem bastante tempo livre para explorar outras partes do c\u00f3digo, fa\u00e7a isso! J\u00e1 se voc\u00ea n\u00e3o tiver tanto tempo assim, tente dedicar pelo menos algumas horas por semana para explorar. Um bom come\u00e7o seria fazer pelo menos uma revis\u00e3o explorat\u00f3ria por semana.<\/p>\n
E voc\u00ea, como organiza seu tempo para revisar PRs? Voc\u00ea se sentiria confort\u00e1vel em adotar essa pr\u00e1tica onde voc\u00ea trabalha? Deixe seu coment\u00e1rio logo abaixo.<\/p>\n","protected":false},"excerpt":{"rendered":"
Prioriza\u00e7\u00e3o \u00e9 sempre algo complicado, n\u00e3o \u00e9 mesmo? O tempo est\u00e1 sempre contra a gente, e as vezes precisamos fazer escolhas dif\u00edceis sobre onde devemos focar a nossa aten\u00e7\u00e3o e o nosso esfor\u00e7o. Com code reviews n\u00e3o \u00e9 diferente. Por isso \u00e9 muito importante tra\u00e7ar uma estrat\u00e9gia para investir seu tempo de revis\u00e3o de maneira … \u00bb<\/a><\/p>\n","protected":false},"author":46,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[3],"tags":[255,60],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7675"}],"collection":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/46"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=7675"}],"version-history":[{"count":4,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7675\/revisions"}],"predecessor-version":[{"id":7681,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7675\/revisions\/7681"}],"wp:attachment":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=7675"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=7675"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=7675"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Quando eu reviso um PR (Pull Request ou Change request, dependendo da ferramenta), sinto que conhecendo o seu contexto fica mais f\u00e1cil fazer uma revis\u00e3o mais aprofundada e assertiva. D\u00favidas do tipo:<\/p>\n
- \n
- Essa solu\u00e7\u00e3o realmente resolve o problema?<\/li>\n
- Existem maneiras melhores de resolver o problema?<\/li>\n
- Essa funcionalidade faz sentido do ponto de vista de neg\u00f3cios?<\/li>\n
- \u00c9 vi\u00e1vel prosseguir com essa funcionalidade agora?<\/li>\n<\/ul>\n
Ficam mais mais f\u00e1ceis de serem enxergadas e respondidas. Mas, para ter essas respostas, ter um bom conhecimento sobre o neg\u00f3cio \u00e9 fundamental. Por isso, as vezes acabamos revisando apenas os PRs nos quais j\u00e1 temos contexto, sejam eles da nossa equipe ou de partes do sistema que j\u00e1 conhecemos. Se pensarmos no n\u00edvel organizacional, esse tipo de comportamento pode resultar nos problemas citados, muitas vezes dif\u00edceis de serem diagnosticados.<\/p>\n
<\/a>Apresentando a Pir\u00e2mide de Code Reviews<\/h2>\n
Uma pr\u00e1tica que pode ajudar a resolver esses problemas \u00e9 a Pir\u00e2mide de Code Reviews.<\/p>\n
<\/p>\n<\/p>\n
<\/p>\n
Essa pir\u00e2mide, inspirada na\u00a0Pir\u00e2mide de Testes<\/a>, nos ajuda na prioriza\u00e7\u00e3o do que devemos fazer.<\/p>\n
Pull Requests da nossa equipe s\u00e3o a base da pir\u00e2mide, pois s\u00e3o neles onde dedicaremos mais tempo. Como j\u00e1 possu\u00edmos o conhecimento necess\u00e1rio para fazer um bom code review, \u00e9 prov\u00e1vel que essas revis\u00f5es sejam feitas mais rapidamente. Dessa forma, ajudamos os outros desenvolvedores a entregar seu trabalho com mais qualidade mais rapidamente.<\/p>\n
No segundo n\u00edvel da pir\u00e2mide temos dois grupos de PRs: aqueles em que j\u00e1 possu\u00edmos contexto e os chamados “PRs cr\u00edticos”.<\/p>\n
Os PRs que j\u00e1 possu\u00edmos contexto s\u00e3o mais \u00f3bvios: eles envolvem uma parte do c\u00f3digo ou do neg\u00f3cio j\u00e1 conhecida pelo desenvolvedor, fazendo com que ele(a) se sinta confort\u00e1vel na revis\u00e3o. Eles n\u00e3o diferem muito dos Pull Requests do pr\u00f3prio squad, por\u00e9m como s\u00e3o externos, consideramos que haver\u00e3o outras pessoas da squad envolvida ajudando na revis\u00e3o. Por isso gastamos menos tempo neles.<\/p>\n
J\u00e1 os chamados “Pull Requests Cr\u00edticos” s\u00e3o um pouco diferentes. Esses PRs podem implementar diferentes tipos de funcionalidades, desde resolver um erro cr\u00edtico at\u00e9 mudan\u00e7as na arquitetura, e \u00e9 essencial que os desenvolvedores estejam alinhados com suas altera\u00e7\u00f5es. Esse tipo de Pull Request geralmente requer uma aten\u00e7\u00e3o imediata dos desenvolvedores, por isso \u00e9 importante separar um tempo para revis\u00e1-los.<\/p>\n
O que a pir\u00e2mide traz de diferente \u00e9 tornar expl\u00edcito que devemos inserir no nosso processo de trabalho as revis\u00f5es explorat\u00f3rias. Ou seja, n\u00e3o precisamos mais nos sentir restritos a(s) parte(s) do sistema onde trabalhamos. Pelo contr\u00e1rio, tendo a pir\u00e2mide em mente, nos sentimos incentivados a revisar outras partes do c\u00f3digo e expandir nosso conhecimento do neg\u00f3cio.<\/p>\n
Mas como come\u00e7ar por esse caminho? Ser\u00e1 que meus code-reviews ser\u00e3o bem aceitos?<\/p>\n
<\/a>Come\u00e7ando os code reviews explorat\u00f3rios<\/h2>\n
Ao revisar uma parte do c\u00f3digo ou do neg\u00f3cio que n\u00e3o estamos familizados \u00e9 natural nos sentir desconfort\u00e1veis ou inseguros. Podemos nos sentir desestimulados a discutir, com medo de fazer perguntas “est\u00fapidas” ou redundantes. E se n\u00e3o conhecermos muito bem os desenvolvedores envolvidos no PR isso fica ainda pior. Resumindo: sa\u00edmos da nossa zona de conforto.<\/p>\n
J\u00e1 apresentamos os benef\u00edcios dos code reviews explorat\u00f3rios, por\u00e9m como devemos proceder na hora de revisar c\u00f3digo desconhecido, onde supostamente nossa efetividade vai ser menor? E como devemos reagir quando uma pessoa de fora revisa o c\u00f3digo e come\u00e7a a fazer perguntas ou questionamentos?<\/p>\n
Como o pr\u00f3prio nome j\u00e1 diz, estamos explorando uma parte desconhecida do projeto, por isso ter uma atitude curiosa \u00e9 essencial. Fazer perguntas, dar dicas e sugest\u00f5es e compartilhar experi\u00eancias s\u00e3o \u00f3timos pontos para se ter em mente nessas revis\u00f5es. Ter bom senso tamb\u00e9m \u00e9 importante aqui, pois n\u00e3o precisamos entender todo o contexto de neg\u00f3cio logo de cara na primeira revis\u00e3o. Identificar o contexto m\u00ednimo que precisamos para fazer a revis\u00e3o \u00e9 vital para n\u00e3o onerarmos demais o nosso tempo nem o dos demais participantes.<\/p>\n
E quando recebermos esse tipo de revis\u00e3o \u00e9 importante ter uma atitude respeitosa e did\u00e1tica nos coment\u00e1rios. Perguntas devem ser respondidas sempre educadamente e com um n\u00edvel suficiente de detalhes(o bom senso vale aqui tamb\u00e9m). Respostas atravessadas ou incompletas podem prejudicar as revis\u00f5es e desestimular os revisores a continuarem com essa pr\u00e1tica. Lembre-se: ningu\u00e9m \u00e9 dono do c\u00f3digo, o c\u00f3digo que voc\u00ea est\u00e1 fazendo agora ser\u00e1 usado por outros desenvolvedores no futuro. E vice-versa. Um ambiente amig\u00e1vel durante as revis\u00f5es vai tornar essa pr\u00e1tica muito mais proveitosa para todas as partes envolvidas.<\/p>\n
E quais crit\u00e9rios devemos usar para escolher aonde vamos explorar? Bem, a decis\u00e3o final fica por sua escolha. Mas se voc\u00ea souber de alguma parte do projeto que carece de revis\u00f5es, pode ser uma boa id\u00e9ia dar uma explorada por l\u00e1.<\/p>\n
Quanto tempo devo me dedicar aos code reviews explorat\u00f3rios? Isso varia de cada contexto. Se voc\u00ea tem bastante tempo livre para explorar outras partes do c\u00f3digo, fa\u00e7a isso! J\u00e1 se voc\u00ea n\u00e3o tiver tanto tempo assim, tente dedicar pelo menos algumas horas por semana para explorar. Um bom come\u00e7o seria fazer pelo menos uma revis\u00e3o explorat\u00f3ria por semana.<\/p>\n
E voc\u00ea, como organiza seu tempo para revisar PRs? Voc\u00ea se sentiria confort\u00e1vel em adotar essa pr\u00e1tica onde voc\u00ea trabalha? Deixe seu coment\u00e1rio logo abaixo.<\/p>\n","protected":false},"excerpt":{"rendered":"
Prioriza\u00e7\u00e3o \u00e9 sempre algo complicado, n\u00e3o \u00e9 mesmo? O tempo est\u00e1 sempre contra a gente, e as vezes precisamos fazer escolhas dif\u00edceis sobre onde devemos focar a nossa aten\u00e7\u00e3o e o nosso esfor\u00e7o. Com code reviews n\u00e3o \u00e9 diferente. Por isso \u00e9 muito importante tra\u00e7ar uma estrat\u00e9gia para investir seu tempo de revis\u00e3o de maneira … \u00bb<\/a><\/p>\n","protected":false},"author":46,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[3],"tags":[255,60],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7675"}],"collection":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/46"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=7675"}],"version-history":[{"count":4,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7675\/revisions"}],"predecessor-version":[{"id":7681,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7675\/revisions\/7681"}],"wp:attachment":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=7675"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=7675"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=7675"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}