Revisão de Código

Revisão de Código

O processo de revisão de código é há muito defendido pela IBM, de facto desde 1974. Inicialmente designado por “inspecção de código”, um processo formal de análise estática para validar se o software vai ao encontro do requisitos. Este processo era lento mas mesmo assim a IBM conseguiu atingir significativas melhorias na qualidade do código entregue.

A empresa (IBM) quase duplicou o número de linhas de código entregues nos produtos de software do System/370 desde 1976, enquanto o número de defeitos por milhares de linhas de código foi reduzido em dois-terços – Michael Fagan

Graças a ferramentas colaborativas de controlo de versões, conseguiu-se agilizar este procedimento, tornando-o num processo de rotina diária. Na minha equipa, todos os dias, cada engenheiro lê, revê, avalia e comenta o código de algum colega. O objectivo é se aumentar a confiança no código que entrará em produção, reduzindo o número de bugs. O processo de revisão implica que o código poderá ser actualizado e novamente revisto. Esta troca de informação deverá ocorrer o número de vezes necessárias até que a equipa – quem produziu o código e quem reviu – esteja totalmente confiante com o resultado.

Não existem regras rígidas de como deverá funcionar este processo. Com a disseminação do procedimento, o bom senso imperou e começaram a surgir, de diferentes fontes, boas práticas aconselhadas.

A empresa SmartBear Software desenvolveu um pequeno white-paper com 11 boas práticas para um eficaz processo de revisão de código:

  1. Rever menos de 200-400 linhas de código (LOC) de cada vez.
    • Mais de 400 linhas de código exigirão maior tempo de atenção, além de ser desmoralizador para o revisor saber de ante-mão que irá passar o dia inteiro a rever “aquele” código.
  2. Apontar para um rate de revisão numa ordem inferior das 300-500 LOC/hora.
    • É preferível que se analisem menos linhas de código mas que se procura situações como bugs, possíveis falhas de segurança, possíveis falhas de optimização e até possíveis falhas no desenho ou arquitectura do código.
  3. Ter tempo suficiente para rever adequadamente, e com calma, mas nunca mais de 60-90 minutos.
    • Por ser uma tarefa que exige atenção ao detalhe, a capacidade de concentração irá decair drasticamente quanto mais tempo levar a tarefa a concluir. Por experiência própria, após 60 minutos de revisão eficaz de código, ou se faz uma pausa (ir beber um café, levantar da cadeira e fazer alguns alongamentos, ler um artigo, etc) ou se começa a ser complacente com algum código e deixa-se de se analisar situações sensíveis como questões de segurança, optimização e escalabilidade.
  4. Autores deverão anotar o código-fonte, antes do processo de revisão começar.
    • É importante que o autor do código encaminhe os seus colegas para quais os ficheiros que devem ser revistos, evitando que código já revisto seja novamente validado.
  5. Estabelecer objectivos quantificáveis para o processo de revisão de código e capturar métricas para se poder melhorar o processo.
    • É importante que a equipa de gestão tenha forma de quantificar se o processo de revisão de código é eficaz, como por exemplo, contabilizar o número de bugs reportados pelo cliente.
  6. Lista de validação melhoram substancialmente os resultados tanto para os autores como para os revisores.
    • O que rever? Sem uma lista, cada engenheiro poderá procurar por algo em particular e deixar ao esquecimento outros pontos importantes.
  7. Validar que os defeitos foram de facto corrigidos!
    • Não basta um revisor indicar onde estão as falhas ou sugerir melhorias. E não se trata de uma questão de confiança nos colegas. É importante verificar que, de facto, as alterações também foram bem implementadas.
  8. Managers deverão cultivar uma boa cultura de revisão de código, em que encontrar defeitos é visto como algo positivo.
    • É necessário evitar a cultura de “porque não escreveste bem à primeira?”. Interessa sim que não se encontrem bugs em produção. No desenvolvimento e no processo de revisão é onde se devem encontrá-los. É importante existir espaço para que um engenheiro possa errar. Só assim poderá aprender algo novo.
  9. Atenção ao efeito “Big Brother”.
    • Similar ao ponto 8, mas na perspectiva do engenheiro. É importante se ter noção de que as sugestões ou bugs reportados nas revisões de código são quantificáveis. Estes dados deverão servir aos managers para analisarem se o processo está a funcionar, se um engenheiro está com alguma dificuldade em particular, mas nunca deverão ser utilizados para avaliações de performance.
  10. O factor Ego: Fazer sempre alguma revisão do próprio código, mesmo que não tenham tempo para fazê-lo até ao final.
    • Saber que o nosso código vai ser revisto por terceiros alerta-nos para sermos mais cautelosos no que produzimos.
  11. As revisões de código feitas de forma “leve” são eficientes, práticas e eficazes em encontrar erros.
    • Não é necessário se entrar no procedimento descrito pela IBM há 30 atrás, onde 5-10 pessoas se fecham em reuniões periódicas com impressões de código e rabiscam a cada linha de código. Utilizando ferramentas como o Git, é possível se participar no processo de revisão de código, escrever comentários associados a linhas específicas, debater soluções através de mensagens assíncronas com o autor, etc.

Aconselho a lerem o documento para terem uma visão mais aprofundada de cada ponto.

Não é possível refutar que a revisão de código irá melhorar a qualidade do código produzido, diminuindo o número de bugs e melhorando o desenho. Existem algumas mais valias adicionais como a partilha de conhecimento entre colegas e a mentoria de elementos mais juniores da equipa.

É um facto que este processo, mesmo que feito de uma forma mais leve, consumirá tempo ao projecto. Ao processo de revisão, temos de adicionar o tempo de resposta do autor e novamente o tempo de nova revisão. Numa tentativa de agilizar este consumo de tempo, aconselho que, após duas tentativas de revisão sem sucesso, o autor e o revisor se sentem lado a lado e debatam o pedaço de código que está a causar o problema.

Mas é importante recordar uma frase que se encontra no site da IBM –  Slow down to go faster (abranda para ires mais rápido).

Gostaria de terminar com uma nota, que tenho como demasiado importante. O processo de revisão de código exige que toda a equipa de desenvolvimento demonstre uma elevada inteligência emocional. Regra geral os programadores têm um ego forte e sentem-se “pais” do código por si escritos. Por vezes não é fácil aceitar comentários menos construtivos. Comentário totalmente destrutivos, provocantes ou jocosos “farão mais mal que bem”, podendo mesmo destruir o espírito de uma equipa. É importante acompanhar esses elementos, tentar que modifiquem as suas atitudes ou, em último recurso, retirá-los da equipa.

Padrões de Código

És dos programadores que pensa que ter o código codificado numa espécie de cifra, a qual só tu entendes, para que ninguém te possa roubar o teu código, ou para que mais dificilmente te possam substituir numa equipa?

Espero que leias o artigo até ao fim pois tenho para ti algumas más notícias.

Aos restantes, leiam também que irão encontrar valor certamente.

A comunidade WordPress tem como slogan “code is poetry (código é poesia)“. Eu prefiro idealizar o código como uma boa prosa, escrita com atenção, com boas regras de pontuação e sem segundos sentidos. Basicamente, respeitando as máximas do “clean code (código limpo)“.

Padrão (substantivo masculino), o que serve de modelo ou referência.

Segundo a definição, tudo o que possa servir de modelo ou referência que permita consistência pode ser considerado um padrão. Assim, um padrão de código poderá ser somente um guia de estilo (coding style); como poderão ser fórmulas de resolver determinados problemas, designados por padrões de desenho (design patterns).

A utilização deste tipo de regras permite uma maior legibilidade do código. Ou seja, mais facilmente o código poderá ser lido e entendido por outras pessoas. Ao contrário da premissa do início do artigo, a existência de mais “olhos” sobre o código aumentará substancialmente a detecção de possíveis falhas de performance ou segurança. Com isto também se irá diminuir o sentimento de único proprietário do código, permitindo uma mais fácil partilha de conhecimento entre toda a equipa. Não, não te vão roubar o lugar…na realidade, terás mais oportunidades de evoluir enquanto programador, e isso sim, te fará manter na profissão que escolheste durante mais tempo.

(Fonte: Rose-Hulman – Institute of Technology)

Os padrões de desenho já existem há considerável tempo, existindo uma “bíblia” escrita pelo gangue dos 4 – Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides – “Design Patterns: Elements of Reusable Object-Oriented Software“.

No entanto, com este artigo pretendo me focar mais sobre os guias de estilo.

Diariamente, na log, utilizamos PHP e WordPress, JavaScript, CSS e HTML. Penso que todas as linguagens de programação terão algum tipo de guia de estilo.

Para PHP existe um projecto designado por “PHP Framework Interop Group” onde se debatem e decidem quais os padrões que deverão vigorar. As recomendações para guias de estilo são o PSR-1 (Basic Coding Standard) e o PSR-2 (Coding Style Guide). Existe uma proposta, ainda em estado de rascunho, para um guia de estilo alargado (PSR-12).

O WordPress, apesar do seu código-base ser PHP, sugere um guia de estilo diferente – WordPress Coding Standards – que contradiz alguns pontos do PSR-2. Se pretendes desenvolver plugins, temas ou participar na evolução do core do WordPress, então terás de respeitar o seu guia de estilo.

Na nossa equipa respeitamos o guia de estilo do WordPress, e adicionamos mais algumas regras. Podes ler, usar e contribuir no nosso github.

Muitas vezes, se não a maioria das vezes, este tipo de iniciativas nasce dentro de empresas que não estão directamente associadas à evolução da linguagem ou framework (ou CMS). Um bom exemplo disso é o guia de estilos para JavaScript escrito pela empresa airbnb. Uma das vantagens do código-livre, o projecto poder nascer dentro de uma empresa e passar a ser do Mundo quando existem mais pessoas externas a participar na manutenção e evolução do mesmo.

Para CSS existem várias metodologias como o BEM (Block Element Modifier) que nós utilizamos na log.

No fundo não interessa se vais adoptar o guia de estilo A ou B, mas sim se algum será adoptado dentro da tua equipa. Esse é o desafio maior e onde se sentirão os maiores benefícios. O sentimento de propriedade partilhado por toda a tua equipa fará aumentar a qualidade do código por vocês escrito. Melhor qualidade de código, menor o número de bugs reportados. Melhor código facilitará a sua manutenção. Melhor código permitirá um sistema mais estável e mais maduro. Terás orgulho em ter escrito parte de um bom sistema, assim como o teu empregador.

Como vês, os beneficios serão de toda a equipa, e de ti também.