Introdução a qualidade de código de software

Olá Pessoal, tudo bom?

O artigo de hoje irá iniciar um extenso assunto sobre qualidade de código de software. Aqui apresentaremos alguns pontos básicos para ajudar na discussão. Veja na continuação.

Qualidade Interna e Externa

No artigo sobre dívida técnica, foi mencionada a importância de não criarmos como time de desenvolvimento muitas dívidas, pois isso impacta na produtividade da equipe. Assim já possuímos um pensamento de que a qualidade é importante, mas quando falamos em qualidade de software, na verdade estamos falando de vários aspectos diferentes. De forma mais ampla, podemos dividir as características de qualidade em dois grupos distintos: qualidade externa e interna, como mostra a Figura 01.

 

Quando falamos da qualidade externa do software, estamos falando de aspectos que podem ser percebidos pelo usuário como, tempo de resposta, quantidade de erros, usabilidade, corretude. Já a qualidade interna é representada pelas características internas como manutenibilidade, reusabilidade, flexibilidade. Um software com boa qualidade interna tem código coeso, desacoplado, responde facilmente a mudanças e não possui defeitos.

A qualidade interna pode influenciar diretamente na qualidade externa, um software com baixa qualidade interna dificilmente terá alta qualidade externa.

Quando falamos de dívida técnica, estamos falando principalmente da qualidade interna do software. Este tipo de qualidade está diretamente sob a responsabilidade da equipe que desenvolve o software.

 

Por que devemos nos preocupar com a qualidade?

Devemos nos preocupar com a qualidade porque somos bons profissionais, desenvolvemos produtos de qualidade, nos sentimos bem com isso. Devemos ser como artesãos! Dominar as técnicas e ferramentas, mas também conhecer profundamente o produto para desenvolvê-lo com a melhor qualidade possível. Infelizmente esta responsabilidade moral vem se perdendo ao longo do tempo.

No entanto, existe outro motivo: a prática tem demonstrado que quanto mais qualidade interna o software tiver, menor é o custo de mantê-lo.

Existe uma noção de que a qualidade interna é algo que você possa negociar para ganhar velocidade (trade-off). Desenvolvedores podem discordar do que é exatamente uma boa qualidade interna, mas eles são a favor de que ela favorece a sua produtividade. Atividades de controle de qualidade certamente tomam tempo e esforço, mas elas se pagam porque elas fazem com que a evolução do software fique mais fácil no futuro.

Você pode até momentaneamente poupar tempo negligenciando a qualidade interna, mas o acúmulo de dívida técnica fará sua produtividade piorar no futuro. Colocar esforço na qualidade interna de seu software melhora a estamina (capacidade vital de resistência, manutenção por longo tempo de uma atividade ou esforço) do seu projeto, permitindo ir mais rápido por mais tempo. Esta é a hipótese levantada por Martin Fowler em seu artigo “Design Stamina Hypothesis”. E como mostra a Figura 02.

 

Inicialmente o projeto com pouca qualidade interna é mais rápido. O problema é que com o passar do tempo, o código se deteriora e se torna difícil de ser modificado, o que diminui a produtividade.

Uma boa qualidade interna mantém a produtividade mais constante (porque o código existente funciona como uma plataforma para novas funcionalidades, é fácil mudar ou adicionar novas funcionalidades) até que, em algum momento (design payoff – linha onde a qualidade interna se paga) supera o número de funcionalidades entregues do projeto com pouca qualidade interna.

Isso representa um axioma para muitos desenvolvedores, pois eles têm vivenciado esse cenário. A questão é identificar onde essa design payoff line está. Na visão de Martin Fowler, é muito menos do que as pessoas pensam: normalmente semanas e não meses.

Isso traz consequências para a análise da Dívida Técnica. Para decidir por negligenciar a qualidade interna, não devemos considerar apenas se o valor entregue é maior do que o pagamento de juros, mas também julgar se a entrega está acima da design payoff line.

finally {

Em futuros artigos veremos como utilizar a qualidade de software à nosso favor.

Duvidas ou sugestões? Deixe seu feedback! Isso ajuda a saber a sua opinião sobre os artigos e melhorá-los para o futuro! Isso é muito importante!

Até a próxima!