quarta-feira, 29 de agosto de 2012

Avaliando a Qualidade de Software

Recentemente participei de algumas consultorias internas na Dextra e externas em clientes com o objetivo de validar arquiteturas e designs de software, tentando apoiar as equipes de desenvolvimento na evolução dos sistemas que estão sendo desenvolvidos. Este, no entanto, não é um trabalho que pode ser realizado sem que alguns conceitos sejam devidamente esclarecidos. Sempre que julgamos alguma coisa levamos em consideração, obviamente, sensações e sentimentos que não controlamos. Por isso precisamos entender este fenômeno humano tentando compreender quais são os conceitos mais essenciais que estão por trás daquilo que molda a nossa percepção à cerca do que estamos analisando. Esta percepção, após alguma reflexão, é o que quero relatar neste post.

Antes de continuar, vamos esclarecer algumas coisas:

Arquitetura = Design = Código-fonte

Como Guilherme Silveira esclarece em How to stop writing next years unsustainable piece of code, a arquitetura e o design de um sistema computacional só existem através de seu código-fonte. Ou seja, o código é a única fonte confiável para a análise da qualidade de um software.

Documentação
A documentação é um instrumento de comunicação que, a meu ver, é muito pouco eficiente (e, em geral, é pouco utilizado efetivamente por desenvolvedores e demais envolvidos no desenvolvimento). Por isso, nunca considerei a documentação do software na análise de sua qualidade. E assim como a arquitetura e o design a documentação não faz sentido se o código-fonte não implementar o que nela está escrito. Portanto, a fonte primária continua sendo o código-fonte.

O que é um bom software?

Ainda antes de identificarmos quais fatores precisamos analisar para avaliarmos um sistema computacional, é preciso alinhar o conceito de "bom software". Colocando sob a perspectiva do cliente, um "bom software" é aquele que evolui de forma rápida e segura, potencializando o ROI (Return Of Investment), ou seja, o retorno do investimento realizado em seu desenvolvimento. Vale ressaltar que o cliente nunca está preocupado com qualidade. Normalmente a qualidade é um item delegado para a equipe de desenvolvimento. Isto não significa que o cliente não queira um "bom software", mas apenas que ele não se preocupa com os detalhes que permitem a criação de um "bom software".

Existem alguns casos em que um "bom software" para o cliente não requer boas práticas de engenharia de software e, nestes casos, avaliar seu código-fonte não será efetivo. Por exemplo, o código-fonte de um software de uma campanha de marketing que durará duas semanas. Apesar de conhecer este exemplo, eu nunca vi um sistema que não precise de manutenção. Que possa ser, simplesmente, "jogado fora".

Existe ainda uma forma de medir a qualidade do software usando o ROI. Já que um "bom software" potencializa o ROI, por que não usar esta métrica para medir a qualidade do software. Esta, me parece, a melhor das alternativas. No entanto, existe um problema complexo de ser resolvido. O ROI está relacionado com mais algumas variáveis além da qualidade do software (mercado, concorrência, gestão interna, outros softwares, etc). A não ser através de um estudo matemático destas co-variáveis é muito difícil medir o quanto cada variável influencia no ROI e, portanto, é difícil tirar uma métrica da qualidade do software pela medida do ROI. Normalmente um ROI baixo é o motivador para a realização da análise da qualidade de um software, mas nem sempre indica um software ruim.

Como saber se um software é bom?

Partindo da premissa do que é um "bom software", precisamos compreender o que nos leva (desenvolvedores) a acreditar que um software é bom. Para isso, é preciso se colocar na posição de um desenvolvedor que, sem nenhum conhecimento prévio sobre o sistema em avaliação, tem que realizar alterações funcionais de diferentes níveis de complexidade neste sistema. É importante ressaltar que estas alterações devem ser realizadas de forma segura, ou seja, é preciso que seja contabilizado nesta análise o tempo para a realização de testes das funcionalidades afetadas pelas supostas alterações.

Nesta situação, existem essencialmente três fatores que podem ser facilmente avaliados para a qualificação do código-fonte de um sistema computacional:

Testabilidade
Quanto mais fácil e rápido é testar um software, mais rapidamente e de forma mais segura alterações podem ser realizadas nele. Testabilidade, em termos técnicos, tem a ver com desacoplamento, com gestão de dependências, com separação de camadas, com mecanismos de integração, etc. A pergunta a ser respondida é: Quão fácil e rápido é testar o software antes e depois da alteração realizada? Esta pergunta deve levar em perspectiva os testes de regressão sobre todas as funcionalidades potencialmente afetadas pela alteração em questão.

Aderência ao Negócio
Se, mesmo desconhecendo o código-fonte e o negócio envolvidos, ao conversar com um usuário (não com um desenvolvedor) sobre uma nova funcionalidade, eu puder rapidamente e de forma segura encontrar no código-fonte o local apropriado para realizar a alteração desejada, terei a percepção de que o código e o negócio são coerentes. Os termos usados pelos usuários estão representados no software, assim como as relações, conceitos, etc. Tecnicamente, esta questão reforça características como reutilização de software, organização de módulos / componentes, orientação a objetos, etc. A pergunta a ser respondida é: Eu consigo encontrar rápida e seguramente no código-fonte o local onde uma alteração deve ser feita após uma conversa com o solicitante de uma nova funcionalidade?

Adaptabilidade
Um sistema é adaptável se é possível alterar a arquitetura de uma parte deste software sem a necessidade de reimplementar um volume muito maior de funcionalidades do que o estritamente necessário. Tecnicamente, esta questão reforça questões como componentização e protocolos de integração. A pergunta a ser respondida é: Eu consigo alterar a arquitetura de uma funcionalidade para ganhar, por exemplo, escalabilidade, sem ter que alterar a arquitetura de todo o sistema ou de uma grande parte dele?

Esta é uma abordagem simples, prática e abrangente para a avaliação da qualidade do código-fonte de uma aplicação. O que acham? Existem outras variáveis a serem consideradas?

Nenhum comentário:

Postar um comentário