Salve, pessoal.

Muito se falou nos últimos tempos sobre qualidade em software, qualidade no desenvolvimento. Inclusive até com algumas perguntas que se tornaram quase bordões. Mas afinal o que é qualidade? Como podemos afirmar que nossas aplicações são, ou não, de qualidade? É mesmo fácil dizer que uma aplicação é ruim?

O que é um software ruim?

Por mais gente que eu tenha visto responder a essa pergunta, vi poucos diretamente responderem ao que eu acho pessoalmente. Um desenvolvedor experiente pode mencionar: um software que não usa padrões, ou que não é bem estruturado, ou que tem muitas chaves “hardcoded”… são inúmeros os defeitos que um especialista pode listar sobre software alheio.

Para este que vos escreve, software ruim é aquele de difícil manutenção – seja para o único desenvolvedor dele, seja para o resto do time atual ou futuro. Muitos dos motivos citados contribuem para que uma aplicação dificulte o desenvolvimento de uma equipe – mas o crucial é a não padronização do fluxo de desenvolvimento. Sim, quando digo “software”, não me refiro somente ao código, mas ao trabalho empenhado em desenvolvê-lo.

Poderíamos ficar discutindo sobre práticas, e más práticas, mas seria uma discussão sem fim. Muitas “más práticas” persistem por n motivos dentro de empresas e projetos por outros n motivos. Já vi alguns times que adotaram uma “má prática” como parte do fluxo – como isso funcionava naquele escopo, era reproduzido e o projeto continuava funcionando. Era uma falha? Possivelmente, mas controlada e de ciência de todos.

O que é qualidade, então?

Qualidade, em resumo, é uma gradação de qualquer coisa dentro de uma expectativa mensurável. Complicado? Podemos dizer que algo tem qualidade quando sabemos o que esperar desse “algo” e podemos apurá-lo quanto a isso – se essa apuração for positiva, esse “algo” é/tem qualidade. Pense na tela logo à sua frente: o que você espera dela? Que ela te entregue uma imagem nítida, sem deadpixels, com boa visibilidade nas possíveis variações de luminosidade, com ajustes precisos… se você puder medir esses quesitos e comprovar a eficácia da tela em cada um deles, se estes forem os critérios da definição de qualidade, então ela é boa.

E com software? Como aferimos a qualidade? Antes de mais nada, precisamos levantar quais critérios serão os crivos de avaliação do projeto. Vamos supor que um dos critérios seja baseado em Testes Unitários. Nosso projeto precisa ter uma cobertura de mais de 80% E (AND, +) devem passar por completo. Se unicamente esse critério for importante para você e seu time, e você conseguir aplicar isso, parabéns, você tem um software de qualidade – embora, ao entregar para produção, os usuários reclamem que é impossível navegar na sua aplicação. Então eu pergunto: aos olhos do usuário/cliente, sua aplicação é de qualidade?

Escolher critérios de qualidade é fundamental em qualquer projeto. Testes unitários são ótimos, mas isso tem algum valor palpável para quem vai usar? Podemos adicionar testes de comportamento, de usabilidade… se agregarem valor ao produto, por que não os incluir como critério? Uma pesquisa com cada camada interessada no projeto com relação à expectativa pode levar ao sucesso da estratégia de adoção de gestão da qualidade. O que os desenvolvedores esperam? O que a gestão espera? Os Product Owners? E, principalmente, o consumidor?

Temos os critérios, e temos como mensurar cada um deles. Ótimo. Como você sabe se a qualidade melhora, ou piora, a cada entrega? Você deve manter um histórico das medições realizadas, acompanhar esses resultados e ver se, entrega a entrega, eles melhoram. Idealmente, conhecendo as métricas, você pode traçar um plano de metas e melhoria contínua e acompanhar a evolução. Pode ser que o índice de cumprimento da meta possa ser um critério também – quem não curte recursividade?

Software bom e software de qualidade

Num caso hipotético, estamos em um projeto e temos diversas métricas, com metas sendo cumpridas. Temos um produto de qualidade? Dentro dos critérios, sim. Temos um bom software? Sim e não (quem me conhece pessoalmente provavelmente odeia essa minha resposta).

Sim, pois um projeto com muitos critérios de qualidade que estão sendo cumpridos tende a dar pouco do mau trabalho. Por mau trabalho entenda-se correções de última hora, novos deploys, estresse desnecessário. Tende, não necessariamente você vai ficar livre disso.

Por que não? Boas práticas de software não são facilmente mensuráveis. Por exemplo: como você sabe que está usando DDD olhando para o código? E Object Calisthenics? e SOLID? E Design Patterns em geral? Está aplicando bem? Posso estar cometendo uma grande gafe aqui, mas fora algumas práticas de Object Calisthenics, que podem ser mensuráveis via análise de estilo, não existe um “SOLID-Adherence-Detector” ou um “D4″ (Domain Driven Design Detector) – o que nos impede, em um primeiro momento, de mensurar o quão aderentes estamos a essas práticas.

Essas práticas/padrões são essenciais para tornar o código sustentável. Que essa base de código possa crescer sem problemas. Também evita problemas comuns na manutenção de código. Também permite que diversas pessoas interajam no código dentro de determinados padrões de maneira a evitar conflitos de compreensão. Esse tipo de cuidado ao desenvolver me mostra se um software é bom ou não, como mencionei no começo.

Enquanto não houver um D4 ou um SAD, infelizmente não podemos usá-los diretamente como métricas. Mas a aplicação dessas boas práticas, preceitos de arquitetura etc. nos traz benefícios e esses sim podem ser quantificados e aplicados à gestão da qualidade – número de bugs por release, redução de conflito entre produto e desenvolvimento, funcionalidades novas por release, entre outros.

Em resumo: faça um bom software, aplique as melhores práticas conforme se torna possível e tenha uma aplicação boa e sustentável. Enquanto isso, estude quais métricas são relevantes ao projeto e mensure-as continuamente, dando um controle de qualidade a ele. Expanda esses “conselhos” para além do código: torne seu time, seu projeto, sua empresa melhor e entenda e melhore a qualidade.

(postado originalmente em Essa tal qualidade de software @ iMasters)