Qualidade de Software: dicas para escrever um código de qualidade

Veja neste artigo como manter um código de qualidade, refatorando e nomeando corretamente.

por Stephany Henrique de Almeida Batista

Em um projeto de software, utilizar rotinas é algo comum e sem ela é praticamente impossível desenvolver um software complexo. Independentemente da arquitetura e utilizando ou não orientação a objeto, as rotinas tem grande importância. A Rotina pode ser um método ou procedimento que são ativados para um único propósito (execução dos nossos desejos em relação ao software). Desenvolver uma rotina de qualquer maneira pode afetar o processamento da aplicação ou então confundir outro colaborador que mais tarde poderá efetuar severas manutenções. Neste artigo demonstrarei os passos necessários para construir um código de qualidade.

Olá a todos! Para escrever este artigo estou sendo guiado por duas grandes obras da área de qualidade de software: CODE COMPLETE de Steve McConnell e CÓDIGO LIMPO de Robert C. Martin. O objetivo do texto é mostrar alguns passos que podem favorecer o desenvolvimento de códigos com qualidades. Este processo irá facilitar manutenção e a vida dos colegas que tiverem que alterar seu código.

As razões para desenvolver uma rotina são extensas, como eu falei no começo é praticamente impossível desenvolver um software sem ela, mesmo assim vou listar algumas das razões para se trabalhar com elas:

• Reduzir complexidade: Crie uma rotina e automaticamente você está ocultando parte do código em um único lugar. Isso torna seu código menos complexo, pois, a leitura e entendimento são mais fáceis. Sem contar na manutenção.
• Evitar código duplicado: Imagine o código repetido em várias partes do sistema. Com a utilização das rotinas você evita a duplicação de código e ainda economiza no tamanho do sistema.
• Simplificar testes booleanos complexos: Desenvolver rotinas que testem as validações necessárias para executar algum propósito ajuda muito no entendimento do código.
• Melhorar desempenho: Na manutenção é muito mais fácil mudar em um único lugar e resolver o problema do que mudar em vários outros locais e ainda ter a possibilidade de esquecer algum local.

Em meus estudos cheguei a algumas conclusões de como desenvolver com qualidade (Posso estar errado, claro!), porem, acho melhor mostrar um método que tenho certeza que não possui as qualidades necessárias para receber elogios.

Figura 1: Exemplo de código

A rotina acima não é complexa e mesmo assim em uma rápida visualização não é possível ter entendimento do que o código realmente faz. Normalmente quando isso acontece é por que o código não está legível. Apesar do nome do método ser claro sobre uma possível intenção, o código da á sensação de executar além. Nesta rotina, em uma eventual manutenção, o programador terá que entender o código para atacar o problema. Abaixo listo os principais problemas deste método em relação à qualidade:

• O nome do método não condiz com o algoritmo.
• O código não está limpo o bastante para ser explicativo.
• O comentário feito engana o programador, pois ele poderá achar que o método faz apenas o que é dito e não dará a atenção necessária.
• O que a variável “retorno” faz? Nada!
• O teste feito na linha 623 é confuso.
• Falta de refatoração.

Abaixo irei listar o resumo dos meus estudos que são os passos para promover rotinas a terem qualidade.

Mesmo operações simples devem ser convertidas em rotinas.

Muita gente acha que por uma operação ser simples (duas ou três linhas de código) não precisa ser refatorada e acabam copiando o bloco de código em varias partes do sistema. O que os programadores devem saber é que uma rotina simples torna o código simples e legível.

O código a seguir é um exemplo.

Figura 2: Código que deve ser convertido em rotina

O código acima é utilizado em alguns lugares do sistema. São executados alguns testes e caso algum deles falhem a rotina para por ai. Se esse bloco de código for refatorada para outra rotina, acaba com a duplicação de código, pois todas as rotinas que utilizem esse código iram chamar a nova rotina e caso seja inserido um novo teste, a manutenção será em um único lugar.

Não importa o tamanho da rotina, mesmo que tenha apenas uma linha evite a duplicação de código.

Coesão

Procurando o significado da palavra coesão em um dicionário online encontrei o seguinte texto: “União; harmonia; associação íntima: a coesão das partes de um Estado”. Coesão na programação de computadores é tudo isso, união e harmonia são os significados perfeitos que as rotinas devem expressar para quem as lê. As operações de uma rotina devem estar intimamente relacionadas e a única maneira de alcançar esse conceito é ela executar apenas um tipo de serviço ou atividade.

Rotinas que executam várias atividades diferentes deixam os programadores confusos e isso traz como consequência um alto tempo de manutenção para resolver o problema.

O método Math.Sin() é claro e coeso na atividade desempenhada por ela. Mas e se existir-se o método (é só um exemplo e loucura minha) Math.SinAndCon() com certeza a manutenção seria mais árdua no segundo método do que no primeiro, pois até onde sabemos a segunda executa duas atividades e a primeira executa apenas uma atividade.

Obviamente que existirão rotinas responsáveis por executar varias atividades diferentes e um exemplo são os métodos de inicialização dos formulários, contudo esta rotina deve ser responsável por chamar (não executar) as rotinas necessárias. O próximo código exemplifica esse cenário.

Figura 3: Trecho de código simples

Desenvolver métodos coesos significa programar rotinas que estejam relacionadas e que executem apenas uma atividade.

Saiba escolher um bom nome para sua rotina

Martin em seu livro constantemente fala que duas coisas são importante em um código de qualidade:

1. Torne o código simples, legível e pequeno.

2. Perca tempo e saiba escolher um bom nome para suas rotinas.

Saber escolher um nome que reflita na atividade desempenhada pela rotina é tão importante quanto saber escrever bons códigos. Não é facil escolher nomes que digam o que as rotinas fazem, mas tornar as rotinas responsável por uma atividade torna o trabalho mais fácil.

McConnell elaborou algumas dicas para escolher um bom nome:

• Descrever tudo o que a rotina faz.
• Evite verbos sem significados.
• Não diferencie nomes de rotina unicamente pelo número.
• Torne os nomes das rotinas tão longos quanto necessário.
• Para dar nome a uma função, use uma descrição do valor do retorno.
• Para dar nome a uma procedure, use um verbo forte, seguido de um objeto.
• Lembra-se, perca tempo mas de um bom nome para suas variáveis, métodos e classes. Esse tipo de cultura irá fazer com que você não tenha mais duvida no outro dia sobre qual é a função de determinada variável.

Tamanho da rotina

Discutir tamanho que uma rotina pode ter é o mesmo que discutir sobre futebol e religião. Certa vez me passarão a tarefa de criar um padrão de codificação e assim todos os programadores teriam que obedecer. Depois de montado fiz uma apresentação para os colegas e todos os itens foram aprovados, exceto o item que falava sobre o tamanho máximo que uma rotina poderia ter.

Coloquei um limite no corpo do método de 15 linhas. Na minha opinião é possível desenvolver em 15 linhas porem para outras pessoas são necessárias 30 linhas. Eu costumo falar que um método pode ter 60 linhas desde faça apenas uma tarefa e esta tarefa esteja muito bem relacionada para precisar de 60 linhas de código. Um CASE que contemple todas as letras do alfabeto é um exemplo, essa codificação poderá passar do limite estipulado, porem a atividade desempenhada pela rotina é apenas uma e está bem relacionada e nesse caso não importa se passou do limite das 15 linhas. O que não pode acontecer é uma rotina ter 150, 200 ou mais linhas de código. O trabalho para efetuar manutenção fica tenso e a chance de consertar o erro e arrumar outro é muito grande.

Não existe um limite de tamanho que uma rotina poderá ter (Nenhum autor vai falar isso por que depende da linguagem e da complexidade do sistema), mas é importante que o método tenha o menor tamanho possível.

Parâmetros

Sobre este item nem tem muito o que se falar, acho que todos sabem que os parâmetros do método é algo que deve ser muito bem organizado e simples. Parâmetros tem mistério? Claro que não! Mas eu achava isso.

Logo hoje quando termino esse artigo encontro em uma manutenção de sistema algo que me fez perder quase quatro horas para “tentar” entender o que eram e para que serviam os parâmetros X, Y, Z, B, P, U e A. E no fim chegar a conclusão que os parâmetros Y e U não estavam sendo utilizados para nada. Mas afinal, o que são os parâmetros Y e U?

Entender o que o Y ou U faz é muito mais difícil do que entender a função dos parâmetros NomeCliente e Sexo. Então para que colocar um nome que não significa nada? (Para dificultar a vida do outro programador) Pare e pense um pouquinho, ajude o seu colega ao lado e insira um nome que de significado para quem lê.

Um outro item importante é que todos os parâmetros enviados para um método obrigatoriamente devem ser utilizadas, se não, por favor, exclua esse parâmetro que no fim só gera lixo para a rotina que recebe.

Documentação

Muitas pessoas acham que código de qualidade envolve um alto nível de documentação. Para cada método é necessário escrever detalhadamente o que o código faz. Eu sempre tive esse tipo de pensamento até por que quando entrei na faculdade para cada declaração em um programa era necessário escrever qual a função daquele código (Não estou discutindo essa metodologia e sei que isso é necessário para melhor praticar quando se esta começando a programar).

Quando comecei a estudar qualidade de software constatei que vários autores preferem que o código não seja documentado. Martin informa em seu livro que prefere gastar tempo fazendo um código que por si só se explique do que pensar em um comentário que explique a função do código. Esse pensamento é a mais pura verdade por que talvez na primeira vez que o código for escrito o comentário diga exatamente sobre a atividade, mas à medida que as manutenções acontecerem o comentário pode não ficar condizente com o código. Certa vez vi uma frase que representa esse cenário: “O comentário pode até mentir, mas o código sempre fala a verdade”.

Alguns devem estar pensando que sou contra qualquer tipo de documentação no produto e isso não é verdade. Acho que a documentação é importante, mas em nível de código, escrever comentário significa que o código não é fácil e muito menos legível. Um código de fácil entendimento não precisa de nenhum tipo de documentação, qualquer desenvolvedor por menor a experiência consegue ler. Claro que existem momentos que não conseguiremos deixar o código legível (Isso se deve por vários motivos e também por estar lidando com código de terceiros) e nesse caso documentar o trecho de código facilitará a outra pessoa a entender melhor sua função.

Conclusão

Alguém olhar o seu código é algo tenso, pelo menos para mim. Isso porque tento fazer o trabalho da melhor forma para que as pessoas gostem, mas fora disso tenho a meta de tornar meu código objetivo, rápido e claro. É chato quando desenvolvemos algo que as pessoas falem mal do código. Uma vez que li que desenvolver código podre faz com que outras pessoas a encontrem por causa do mau cheiro que é sentido em outros módulos, já o código limpo ninguém a encontra por que seu funcionamento é perfeito e por causa disso ninguém a vê. Achei isso perfeito e sempre tento guardar este ditado.

Desenvolver rotinas de qualidade tem o benefício de ajudar na hora da manutenção e ser a própria documentação do produto. Traz benefícios até para você que desenvolve, pois, você e suas gerações passadas não serão xingados (Confesso que hoje fiz uns “elogios” a pessoa dos parâmetros Y e U). Como mostrei no primeiro código visualizado um dos passos para saber se um código é de qualidade é ser simples e legível. Conheço uma galerinha que ainda curte código complicado. Quanto mais complicado e difícil de entender mais eles acham ser superiores, quanta tolice!

Claro que desenvolver um método para ser legível não é algo fácil e requer prática, mas com o tempo isso vem quase inconscientemente. Para isso, uma boa prática é ler bastante código de outras pessoas. Existem muitos projetos abertos e que valem a pena estarem sendo olhados a forma que o produto foi desenvolvido.

O artigo termina aqui e espero ter ajudado e que tenham gostado.

Blog do autor: http://stephanyhenriquebatista.wordpress.com/