Code review

Quem é desenvolvedor sabe: Uma hora ou outra o code review chega. E não deve ser, nem se tornar um bicho de sete cabeças. Neste artigo vou mostrar como tornar o code review um processo natural para qualquer desenvolvedor.

Photo by NESA by Makers on Unsplash

São dois os pontos principais do code review, sendo que um deles pode ser substituído por uma ou mais ferramentas. As palavras chave aqui são: educação e padronização.

Boas práticas:

• Aqui deve ser avaliado o código do ponto de vista de boas práticas, ou seja, se ele performa bem, se não utiliza código possivelmente deprecado, se não apresenta problemas relacionados a uso de memória e processamento. Todo mundo está aprendendo. Se você vai fazer um code review e está com alguma dúvida sobre um determinado trecho de código, procure na internet sobre ou ainda questione o desenvolvedor. Ele pode achar a resposta antes de você e esclarecer mais sobre o problema.

Besteiras:

• Aqui vale um conhecimento de git. Você como desenvolvedor sabe que qualquer alteração feita no código é contabilizada pelo gerenciador de versão git? E que dois desenvolvedores atuando sobre o mesmo pedaço de código gera um conflito que terá de ser resolvido posteriormente entre os mesmos. Resolver conflitos é chato e pode vir a gerar bugs inesperados. A lição que fica é: altere somente o necessário. As vezes, surgem aqueles comentários de "linha em branco a mais", e eles existem justamente para evitar conflitos posteriores.

Comunicação:

• Code review é um processo de aprendizado, tanto para o desenvolvedor, que está colocando a prova sua capacidade, quanto para o analista que está de olho na nova funcionalidade que está para entrar. Nesse caso a comunicação é essencial. Escrever apenas coisas como: faça isso, troque por aquilo, coloque desse jeito, elimina o processo educativo do code review. Colocar os motivos pelos quais você está pedindo uma alteração dá sentido na cabeça do desenvolvedor e permite que ele aprenda e utilize esse conhecimento nas próximas coisas que vai ter que fazer.

Padronização:

• Se está todo mundo codificando em JAVA, não adianta você ir lá e começar a desenvolver em swift que as coisas não vão se encaixar, certo? A mesma coisa vale para a arquitetura do projeto. Se o projeto está utilizando uma arquitetura clean, com camadas de responsabilidade única estabelecidas e bem separadas, não adianta colocar as coisas de uma outra maneira, mesmo que funcione. Isso porque o mundo no desenvolvimento é rotativo. Vai chegar um desenvolvedor novo amanhã no projeto e é muito mais fácil para esse desenvolvedor aprender a trabalhar ali se casa estiver arrumada. Não é fácil, geralmente você vai encontrar uma ou mais possibilidades no momento de desenvolver alguma coisa. Converse com os desenvolvedores do projeto (preferencialmente com os que estão a mais tempo) para obter as respostas para suas perguntas.

Tempo:

• Está corrido pra você, assim como está corrido pra todo mundo. Então, se preocupe em fazer um código alinhado com as espectativas do projeto, não fugindo padrão e com qualidade que o code review será como uma brisa passageira na praia, bem tranquilo e com poucos comentários e changes. Você que está disposto a fazer o code review, faça direito e não apenas olhe por cima. Pode estar subindo algum problema grande e você fez vista grossa para ele. Pesa na consciência depois.

Qualquer dúvida, sabem aonde me encontrar: @eduardolomb no twitter, instagram e por aí vai, aproveita e dá uma olhada no meu app http://bit.ly/MegaWatchApp , e meu canal no youtube http://bit.ly/youtubdoedu .