04.06.2015

Elevando a qualidade do seu código

Elevando a qualidade do seu código Imagem via Freepik

Qualquer pessoa que trabalhe com software sabe: Requisitos mudam, idéias novas surgem. Mas o principal é: alterações precisam ser feitas. Linhas de código devem ser adicionadas naquele arquivo que nenhum desenvolvedor jamais ousou alterar (afinal, o requisito funciona e isso é tudo o que importa, certo?). É então que discussões surgem, dedos são apontados, desenvolvedores fingem estar ocupados com qualquer outra tarefa que não envolva alterar o temido arquivo. Se você já passou por isso este post é para você. Se você ainda não passou por isso, não custa nada se prevenir desse grande mal que tanto aflinge os desenvolvedores.

Guias de estilo de código

Uma frase muito comum no mundo da programação é: ’Se você tem uma base de código na qual consegue abrir um arquivo e dizer qual pessoa da sua equipe o digitou, você tem um problema'. Coisas simples, como indentação, formatação, pular ou não a linha depois de abrir chaves têm um grande impacto no desenvolvimento da sua equipe.

"Code is read much more often than it is written" - Guido van Rossum

Traduzindo a frase acima à grosso modo, um código é escrito uma vez e depois ele é lido milhões de vezes. Então escreva direito. Cada vez que você tem que ler um código macarrônico - por código macarrônico, leia-se um código que tem 40 linhas, 10 cláusulas condicionais (algumas delas aninhadas, é claro) - o cérebro gasta muito mais processamento do que deveria. Perde-se muito tempo tentando compreender todos os possíveis caminhos de execução do código.

Se tem algo que aumenta mais rápido que o preço de ônibus é um código complexo mal escrito. O que vai acontecer quando o próximo desenvolvedor precisar adicionar uma funcionalidade? Mas é claro, ele vai seguir o padrão adicionando mais um IF! Ou seja, o feio e macarrônico é um padrão. E ele será copiado.

É aí que entram os guias de estilos de código. A comunidade costuma adotar um estilo de código para uma determinada linguagem (ou ferramenta de versionamento, existe estilo de código para ferramentas como o git também!). Existem também diversas ferramentas que auxiliam o desenvolvedor analisando o código automaticamente - linting - e informando ao desenvolvedor quais ‘regras’ ele estaria infringindo. Um exemplo seria o Rubocop, que ficou extremamente popular na comunidade de Ruby.

Para quem acha que padrões de código limitam um desenvolvedor ou tenha qualquer outra opinião negativa do tipo, existe uma das melhores respostas já dadas sobre isso aqui: Why does JavaScript need a style guide?.

Revisões de Código

The only vacid measurement of code quality: WTFs/minute

Uma revisão de código pode ser uma revisão de equipe ao subir o código novo, seja ela feita até chamando o colega do lado para dar uma olhada no código antes da submissão.

A maioria das pessoas pode imaginar que uma revisão de código servirá para encontrar bugs no sistema. Mas essa nem de longe é a maior vantagem que essa abordagem proporciona a uma equipe. Qualidade de código é uma coisa muito subjetiva e, mesmo que você siga todos os padrões de SOLID, o seu ponto de vista pode ser muito diferente do de outro desenvolvedor.

A maior vantagem de uma revisão de código bem feita é a troca de informação entre os desenvolvedores. Uma equipe fica a par de todos os problemas encontrados. Conhecimento é melhor difundido quando um desenvolvedor mais experiente comenta possíveis problemas no código de outro. Discussões são criadas quase que automaticamente dentro de uma equipe, buscando melhores soluções para se resolver um problema.

Caso você esteja desenvolvendo sozinho e não tenha com quem compartilhar o seu código, existem excelentes ferramentas disponíveis que fazem um review automatizado do seu código seguindo regras pré-estabelecidas como tamanho máximo de um método ou duplicação de código. Uma dessas ferramentas é a gem RubyCritic, para ruby. Para python temos o PyChecker ou pylint.

RubyCritic é uma biblioteca open source que se utiliza de várias outras bibliotecas de análise de código e as reune em uma só, analisando o código de um projeto e retornando pontuações de acordo com a quantidade de código duvidoso, ou ‘malcheiroso’ - do inglês code smells - encontradas.

Ruby Critic Panel

Para finalizar

Você não foi a primeira pessoa a passar por problemas de código legado (seja código seu, ou herdado de terceiros), e não será a última. Porém, não importa a linguagem que você decida trabalhar, sempre confie na comunidade e nas ferramentas disponibilizadas por ela para te ajudar a escrever o seu código da melhor forma possível.

Se tudo der certo, na próxima mudança de requisito a sua equipe não estará arrancando os cabelos e sim focada pensando na solução do problema.

Rennan Oliveira

Lider técnico de desenvolvimento web da Universidade Federal Fluminense (UFF) e especializado em Ruby on Rails. Rennan ama programar, refatorar código, treinar novos desenvolvedores, movimentar a comunidade de Niterói, ler livros de boas práticas, assistir vídeos da Sandi Metz, escrever contos e cantar Backstreet Boys ou Molejo no karaokê.

< voltar a página de artigos