Code review: Ensinando as pessoas a entenderem a qualidade de um código
Quando iniciamos no mundo da tecnologia da informação como desenvolvedores, é muito comum termos que lidar com um processo que é fundamental para a qualidade do produto mas que os usuários comuns não conhecem: O Code Review.
Para quem não conhece este termo, todo código de programação é salvo em repositórios que mantém um histórico das alterações que fazemos. Para exemplificar imagine você tem um arquivo de TCC chamado “TCC_V1.doc” e após você passar pelo orientador você precisa realizar uma V2 mas não quer perder esta V1, geralmente você realiza as alterações que necessita e salva o arquivo como “TCC_V2.doc” certo? Nós como desenvolvedores mantemos o V1 mas temos acesso as diferenças entre eles e a V2. Abaixo um exemplo de diferença.
Na imagem a cima, estou adicionando um código ao código base, ou seja, estou fazendo uma inserção de código que irá chegar ao usuário final (mesmo que nesse cenário seja algo invisível) mas para chegar no código base é necessário algo muito importante: A revisão dos meus colegas de time para determinar que o código está bom.
O que é um código bom?
Esta é uma pergunta muito feita pela comunidade de desenvolvedores de software, o que determina que o código é bom ou ruim? Robert C. Martin (conhecido como Uncle Bob) diz que existe um coeficiente para determinar se um código é bom ou ruim na hora da revisão: O coeficiente “WTF p/ minuto”.
Este coeficiente determina de uma forma muito resumida que, ao revisar o código quanto menos “o que está acontecendo aqui?” o desenvolvedor fazer para sí mesmo mais o código está claro e sucinto para resolver um problema, adicionar uma funcionalidade ou simplesmente para fazer alguma coisa diferente.
Chegar na melhor versão desse coeficiente, leva tempo e esforço dos desenvolvedores na incessante busca do aprendizado e auto conhecimento e isso só é atingido através da maturidade de conhecimento próprio e da vontade de se aperfeiçoar.
Robert Martin (este senhor é um guru nesta prática, ao final do post tem alguns links sobre o trabalho dele) fala que desenvolvedores são artesões e que devemos sempre aperfeiçoar nosso código que é em uma comparação simples nossa arte, mas isso deveria ser mais simples do que aparenta dado a importância que esta arte tem para os dias atuais. Isto está relacionado a diversos problemas mas eu vou abordar o que na minha opinião é crucial e que está relacionado a isto.
O problema estrutural
Você que é experiente em desenvolvimento de software deve estar se perguntando: “Qual é o problema? Existe uma literatura enorme na comunidade sobre o assunto, basta procurar sobre.” e é aqui que está parte do problema.
A comunidade de fato cria uma documentação fantástica sobre o assunto mas para o estudante do primeiro semestre de tecnologia não sabe disso, ele sabe copiar e colar código funcionando é sucesso, não funcionando volta ao estágio inicial. Este processo é eficiente para ensinar uma pessoa a programar mas acaba criando um ciclo vicioso na comunidade, muito mais quando realizamos processos seletivos e temos que tirar as pessoas que estão em busca de oportunidade, mas isto é assunto para outro dia.
As universidades/faculdades focam em ensinar lógica da programação, orientação a objetos, como bits e bytes se resolvem, como um processador computa 0/1 num operador lógico entre outras coisas e isto é importante sem sombra de dúvidas mas deixa de lado algo que talvez seja fundamental: Preparar para o mundo real e corporativo/open source. Se uma pessoa júnior escrever um código extenso e complexo para um trabalho da faculdade, o professor analisa se funciona, qual foi a lógica aplicada entre outros pontos, no mundo real, além de todos estes fatores um desenvolvedor vai analisar se o código faz sentido, se tem cobertura de testes, se segue um padrão de limpeza e reaproveitamento e é aqui que um desenvolvedor júnior se frustaria em receber um “Denied” e sem entender o que se esperava do código.
As instituições de ensino deveriam focar em qualidade de código e ensinar seus alunos a irem buscar estas boas práticas, ou seja, instigar estas pessoas a entenderem sua importância, o que buscar para entender a boa prática entre outras coisas, assim, a curva de aprendizado quando o desenvolvedor buscar seu espaço ao mundo será muito mais rápida.
Ensinando desenvolvedores a lerem a qualidade de código
A primeira coisa e fundamental para um código bom é a necessidade de cobertura de testes unitários para o código a ser alterado, isto garante que o que você está propondo não irá gerar efeitos negativos aos usuários,ou seja, a integridade do produto não irá se alterar.
A segunda questão e talvez pouco mais complexa, é respeitar princípios e conceitos de boas práticas de programação, como SOLID, Clean Code, boas práticas da linguagem, alinhamento de código entre outros pontos da literatura de desenvolvimento e boas práticas que irei deixar ao final do post algumas sugestões.
A terceira e talvez fundamental boa prática de revisão de código é ser claro no que você está buscando, ficar claro para si o que o código propõe, já foi dito por vários especialistas que ao contrário do que se imagina, desenvolvedores leem muito mais do que escrevem códigos, então o bom entendimento é fundamental para isto e aqui entra o coeficiente WTF, se uma pessoa júnior está fazendo muito WTFs para entender um código que para você é simples, talvez o código não esteja tão simples ou talvez a complexidade esteja muito alto.
Uma prática que eu recomendo é o Pair Review, que é pegar uma pessoa que esteja iniciando no mundo de desenvolvimento e revisar PRs junto, pedindo a opinião dele, o que ele acha sobre o código e já sabendo o que ele irá comentar ou se abster pela falta de conhecimento e mostrando como o mundo funciona fora da vida acadêmica.
Conclusão
A revisão de código é a ferramenta mais básica de desenvolvimento, antes de escrever, ler e compreender é fundamental para a qualidade do produto e do crescimento da marca e do desenvolvedor, desenvolvedores que não tem essa consciência acabam caindo no limbo do mercado de trabalho ou indo para outras áreas, empresas não tem essa oportunidade, se o produto é falho elas são falhas e acabam morrendo, então, nos dias de hoje, desenvolvedores são o coração, pulmão e todos os outros órgãos de uma empresa.
Sugestão de leitura
- Clean Code (Robert C. Martin) — Livro
- Clean Architecture (Robert C.Martin) — Livro
- Clean Coder (Robert C.Martin) — Livro
- SOLID (Padrão de programação)
- TDD (Prática de desenvolvimento)