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?

Learn by Example

Alguns anos atrás pude conviver um pouco com minha cunhada arquiteta enquanto viajávamos por algumas cidades do interior da Itália. Uma das coisas que me surpreendeu na viagem foi a atenção que ela dava aos detalhes das construções, tirando fotos de calhas, paredes, janelas, portas, etc. Enquanto nos preocupávamos com um mundo novo que conhecíamos, ela ficava atenta a cada detalhe.

Fiquei, obviamente, intrigado com o comportamento dela. E fiquei ainda mais intrigado após entender por que ela observava o trabalho dos outros com tanto afinco. Na arquitetura, o processo de criação leva em consideração a observação do trabalho dos outros arquitetos.

O processo de desenvolvimento de software também é um processo criativo. No entanto, parece-me que neste processo a observação do software desenvolvido por outras pessoas não tem um papel tão fundamental. Pelo menos não tem o papel que deveria ter.

Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides (GoF) foram em um caminho parecido, ao utilizar a observação para identificar padrões de solução de problemas em software. Martin Fowler também é outro expoente deste tipo de observação e de sua aplicação na vida real. No entanto, a prática da observação realizada por estes grandes nomes da computação não foi absorvida pelos demais desenvolvedores (com exceções, claro). Apenas os resultados de sua observação é que se tornaram notáveis, e não o processo pelo qual estes resultados foram obtidos.

Os design patterns são exemplos de como a observação é efetiva. No entanto, o uso destes design patterns não é o benefício mais importante destes trabalhos. O benefício está no processo de observação e aprendizado. É este processo que precisamos exercitar constantemente e é nesta observação que devemos basear nosso aprendizado.

Segurança de Dados

A segurança de dados é um assunto que vem se tornando cada vez mais relevante no desenvolvimento de aplicações corporativas. Em geral, podemos proteger com relativa facilidade as funcionalidades de nossos sistemas, atribuindo permissões de acesso aos usuários e verificando estas permissões durante a sua execução. Mas isto não é suficiente em aplicações corporativas. Por exemplo, em um sistema acadêmico, somente um professor pode atribuir notas a um aluno, correto? Isso parece fácil de ser implementado. No entanto, pode um professor atribuir uma nota a qualquer aluno? Definitivamente não! Ou seja, precisamos garantir a segurança dos dados, que poderia ser definida como: “A capacidade de um sistema de garantir que as informações fiquem restritas a um contexto de negócio”.

Leia mais no Blog da Dextra Sistemas.