Boas Práticas na Análise de Software

À medida que o software se torna mais complexo, aumenta exponencialmente a probabilidade de exposição dos utilizadores finais a problemas com as aplicações. No passado costumava-se modificar o código e submetê-lo a outros programadores para revisão. No entanto, esta prática deixava passar frequentemente problemas mais intrincados.

Actualmente, mesmo os problemas subtis de qualidade podem provocar falhas inesperadas, conduzindo potencialmente a perdas de negócio e a danos na reputação em termos de qualidade de produto. Para se poder ir além das revisões efectuadas por outros programadores e para diminuir o tempo de disponibilização ao mercado de aplicações complexas, existem agora no mercado várias ferramentas de análise estática, as quais podem detectar e corrigir automaticamente problemas comuns de código.

Evidentemente, as ferramentas de análise estática ainda podem ser melhoradas, mas já estão a fazer um bom trabalho na resolução de problemas. Uma dessas ferramentas é o IBM Rational Software Analyzer, que pode detectar automaticamente ? e corrigir, em muitos casos ? os problemas de código. Apresentamos a seguir 10 estratégias simples para melhorar a análise estática de software.

Boa prática 1. Acompanhe os estudos que têm sido feitos

Uma pesquisa rápida na Internet permitirá aceder a dezenas de estudos que corroboram a ideia de que a qualidade do software melhora com a utilização de ferramentas de análise estática automatizada. Dependendo do estudo e do tipo de análise utilizado, as ferramentas de análise estática podem encontrar entre cinco e 30 por cento de todos os defeitos existentes no código. Muitos estudos fiáveis já provaram que quando se espera que sejam os clientes a encontrar um dos problemas de código, a resolução poderá custar entre 15 a 20 mil dólares. Se estes problemas forem identificados durante o desenvolvimento, os custos serão muito menores.

Mesmo que adoptemos uma posição mais conservadora, acreditando que as ferramentas de análise estática são capazes de detectar apenas um por cento dos defeitos, podemos contabilizar facilmente aquilo que poupamos se tivermos um total de 1000 defeitos. Neste caso, poderemos poupar potencialmente 150 mil dólares num projecto normal. No entanto, as reduções de custos são apenas uma parte da equação. Também podemos melhorar a reputação da empresa fornecedora se esta tiver um histórico de disponibilização de código de baixa qualidade. No caso concreto da IBM, os índices de defeitos foram reduzidos em 33 por cento, graças à introdução de ferramentas de análise estática em algumas das suas aplicações chave. Segundo a própria companhia, num dos seus produtos conseguiu reduzir custos superiores a 250 mil dólares.

Boa prática 2. Estabeleça objectivos e expectativas

Não existem milagres na análise de software. Não podemos colocar código mau numa caixa mágica e depois obter código de alta qualidade. O mais certo é que o nosso código nunca venha a ser perfeito, independentemente das tecnologias que implementemos no processo de desenvolvimento. Para se estabelecerem expectativas realistas, será importante estabelecer alguns objectivos e parâmetros comuns que ajudem a garantir um nível razoável de qualidade.

Muitas ferramentas de análise estática forçam os programadores a seguir um determinado fluxo de trabalho, obrigando-os a trabalhar de acordo com as regras da ferramenta. Outras, pelo contrário, têm a flexibilidade necessária para se adequarem às organizações, não obrigando os programadores a modificarem o seu processo de desenvolvimento para beneficiarem da análise estática.

Boa prática 3. Utilize uma análise orientada

A ferramenta Rational Software Analyzer fornece cerca de mil regras para várias formas de análise. Apesar de existir a tendência de as seleccionar todas e realizar a análise estática de uma só vez, deverá evitar-se este procedimento. Será melhor concentramo-nos num conjunto muito mais pequeno, de modo a que os resultados produzidos sejam mais fáceis de gerir.

Por exemplo, se estivermos a executar uma revisão de código básica, podemos seleccionar o subconjunto de regras orientado para o desempenho, em vez de todo o conjunto de regras. Desta forma, obtêm-se resultados que serão mais fáceis de compreender, bem como resultados mais imediatos, uma vez que poderão ajudar a eliminar código que possa estar a introduzir problemas de desempenho. Além de se obterem resultados mais orientados, a utilização de pequenos subconjuntos de regras também exigirá menos tempo para a realização das verificações do código.

Boa prática 4. Comece com blocos de código pequenos

Podemos ter milhões de linhas de código e querermos obter um conjunto completo de resultados. No entanto, devemos evitar a verificação de todo o código, sobretudo quando estamos a iniciar a utilização de ferramentas de análise estática. Apesar da ferramenta poder verificar todas essas linhas de código, será muito complicado lidar com os resultados. Se o código a verificar for código já existente e nunca tiver sido exposto a uma ferramenta de análise estática, a verificação poderá gerar enormes quantidades de dados, ao ponto de submergir qualquer equipa de desenvolvimento.

Será melhor analisar um conjunto de código muito mais pequeno ? por exemplo, o projecto, o pacote, ou mesmo o ficheiro que está a ser modificado. A realização de análises de código em mais de alguns milhares de linhas de código de cada vez será geralmente pouco frutuosa. Consequentemente, será melhor analisar apenas o código que está a ser modificado, o que envolverá normalmente entre 50 a 1000 linhas de código.

Boa prática 5. Tenha em conta os falsos positivos

Quando se descrevem os resultados das análises estáticas, pode provocar alguma confusão a utilização da expressão ?falso positivo?. Os programadores podem afirmar que têm falsos positivos, mas o que querem dizer realmente é que não gostam da resposta. Um falso positivo genuíno é aquele em que a ferramenta de análise estática reporta algo que não é verdade.

Por exemplo, falha em fechar um fluxo (stream) que está realmente fechado. Este cenário só se verifica normalmente em análises mais profundas, como as de fluxo de dados e fluxo de controlo. A maior parte das formas de análise estática envolvem a detecção de padrões no código ou na execução do fluxo, mas raramente reportam um verdadeiro falso positivo.

Boa prática 6. Não se deixe escravizar pela ferramenta

Não seria muito sensato partir do princípio que qualquer análise estática irá encontrar e resolver todos os nossos problemas de código. As análises estáticas são simplesmente ferramentas que podemos utilizar para melhorar a qualidade global do código, através da identificação das partes do código que requerem atenção. Os programadores deverão verificar o código à medida que vão escrevendo e utilizar análises completas para as suas construções diárias, de modo a garantirem uma qualidade contínua do código.

Também não podemos partir do princípio que qualquer ferramenta de análise estática compreendeu completamente o nosso código, os processos ou práticas, ou que todos os resultados produzidos pela mesma devem preocupar toda a equipa de desenvolvimento. Em vez disso, devemos utilizar as ferramentas de análise estática como ajudas de aprendizagem para nos permitirem evitar problemas de código no futuro. Será, portanto, importante gerirmos os nossos esforços de codificação e não deixarmos que sejam as ferramentas de análise a controlar-nos.

Como regra básica, podemos assumir a seguinte postura. Se os resultados de uma dada regra não se aplicam ao nosso desenho ou não fazem sentido, o melhor será desactivar essa regra. Assim a ferramenta de análise não perderá tempo a destacar problemas que já compreendemos. As ferramentas de análise não se destinam a substituir completamente as análises de código efectuadas pelos humanos. Destinam-se antes a ajudar a melhorar as análises de código manuais, fornecendo análises consistentes de problemas de código comuns.

Boa prática 7. Prepare-se para uma grande quantidade de resultados

As análises estáticas automatizadas envolvem um conjunto complexo de processos destinados a detectar problemas de código comuns. Para obtermos a melhor experiência com este tipo de análise, devemos assegurar-nos que começamos com código razoavelmente limpo, de modo a que a ferramenta tenha a oportunidade de identificar os problemas reais. Recomendamos assim que analise manualmente o código e o limpe antes de utilizar qualquer ferramenta de análise estática. Quanto mais limpo estiver o código antes da verificação, menores serão os resultados iniciais com que será necessário lidar.

Um desenho e código relativamente limpos darão à ferramenta de análise maiores oportunidades para encontrarem os problemas reais, em vez de se limitarem a destacar problemas associados a um desenho pobre. A análise de código consome bastante tempo, e o código excessivamente complexo tenderá a aumentar o tempo do processo de análise. As primeiras verificações do código deverão gerar maior quantidade de resultados.

Boa prática 8. Assegure-se de que presta atenção aos resultados

Será importante ter em conta todos os problemas à medida que vão sendo descobertos, dado que um deles pode encobrir outros. Ao garantirmos que todos os resultados reportados que exigem correcção são registados como defeitos, estaremos a reduzir o número de resultados reportados e a melhorar claramente a qualidade global do código. O resultado serão menos bugs reportados no futuro.

É aconselhável fazer com que a análise estática seja parte integrante do trabalho diário e produzir relatórios continuados que destaquem os resultados das análises. Lembre-se que a detecção e resolução dos problemas de forma atempada é a chave para um desenvolvimento bem sucedido.

Boa prática 9. Utilize a análise estática como uma ferramenta e não como arma

Sempre que uma equipa de desenvolvimento é impelida a utilizar uma ferramenta de análise estática, existe a tendência para um enfoque nas suas potenciais implicações negativas. Os programadores costumam olhar para este tipo de ferramentas como um cronómetro que é utilizado para monitorizar o progresso do seu trabalho e para os penalizar quando algo corre mal. Os gestores que quiserem introduzir ferramentas de análise estática deverão apresentá-las de forma a encorajar a sua utilização. É importante enfatizar o objectivo de melhorar a qualidade global do software, e não o de monitorizar as capacidades de desenvolvimento individuais.

Os programadores podem utilizar as ferramentas de análise estáticas para melhorarem as suas capacidades. Estas ferramentas fornecem muito conhecimento codificado num processo para reportarem problemas de software comuns. Os programadores poderão assim utilizar esse conhecimento para melhorarem as suas técnicas de codificação, algo que poderá ser benéfico para toda a equipa. Por um lado, os programadores passarão a escrever código melhor e, por outro, passará a existir uma maior consistência entre os vários programadores.

Boa prática 10. Preste atenção às coisas simples

É muito fácil ignorar os problemas mais simples do código, apesar destes poderem resultar em problemas sérios após a implementação.

Boa prática 11. Comece hoje mesmo a melhorar a qualidade do seu código

As vantagens da análise estática automatizada são bastante evidentes. Pode reduzir o esforço, melhorar a qualidade e poupar dinheiro. O desenvolvimento de software coloca bastantes desafios e os sistemas estão a tornar-se cada vez maiores e mais complexos. Neste contexto, o processo de escrever código com qualidade e dentro dos prazos exigidos está a tornar-se cada vez mais difícil. As velhas técnicas já não são suficientes e já não podemos concentrar-nos apenas num aspecto da qualidade do código.

Baseado num documento com o título ?Best practices for software analysis? publicado no site da IBM Rational.