Tecnologia de Internet (Locaweb)

Existem algumas formas de mensurar a qualidade de um software, como performance, escalabilidade, segurança, usabilidade, manutenabilidade, reutilização, disponibilidade, etc. Mas existem algumas distinções sobre a perspectiva de qualidade.

Joseph Yoder, em sua apresentação “Software Patterns and Quality: Can Patterns Help Quality?” na QCon San Francisco 2008, distinguiu a qualidade de software em:

• Qualidade interna
• Qualidade externa

Com as seguintes perspectivas:

• Do desenvolvedor
• Do usuário final
• Do gerente (manager)
• Do CEO

Por exemplo, o valor da qualidade de um software para um usuário final (qualidade externa) é totalmente diferente da visão de qualidade do desenvolvedor (qualidade interna). A qualidade do código ou do design do software não faz sentindo para o usuário, se o software não atende suas expectativas ou suas necessidades.

Na grande maioria dos casos, o usuário final quer saber se o software funciona, não se foi feito utilizando as melhores práticas de desenvolvimento ou com um determinado tipo de arquitetura. Em muitas situações, o próprio CEO tem essa concepção de valor de qualidade do usuário final.

A qualidade interna nem sempre é alcançada facilmente. Pode haver dificuldades como algum custo adicional, prazo de entrega, investimentos na equipe, etc. Em cima dessas dificuldades, muitos pensam em qualidade de software de maneira quantitativa, tentando achar números para os tipos de qualidade: por exemplo, o quanto esse software é expansível, o quanto esse código e fácil de dar manutenção ou quão seguro é esse sistema.

Yoder usou o termo QWAN (Quality without a name), de Christopher Alexander para essas qualidades internas, as quais realmente não podem ser quantificadas. Os padrões de projeto (design patterns) ajudam a aumentar a qualidade interna do software, exatamente em cima das QWANs. Identificando o problema ou situação onde há necessidade de aumento de qualidade, escolhendo e aplicando o padrão adequado, a qualidade interna do software é afetada.

Algo que foi enfatizado na apresentação é a questão da definição dos padrões de projeto. Uma boa idéia de solução de um determinado problema de software não é um padrão. Essa idéia pode se tornar um padrão, depois de aplicada várias vezes. Os padrões vão de encontro com a experiência de utilização de soluções para problemas que se tornam comuns entre aplicações.

Padrões de projetos aplicados a uma determinada qualidade podem algumas vezes beneficiar outras qualidades do software. Um exemplo interessante mostrado foi a necessidade de aumentar a segurança em um sistema. Aplicando um padrão de segurança para essa necessidade, houve também um aumento de performance no sistema.

Existe uma série de padrões de projetos que vão muito além dos clássicos GoF. Em geral, todos os padrões de projeto no final das contas acabam se referindo ao aumento de qualidade de software. O livro Implementation Patterns de Kent Beck fala exatamente sobre padrões para criar código de qualidade.

Por outro lado, querer aumentar demais a qualidade, procurando a fórmula do código perfeito, pode gerar problemas. A perfeição no desenvolvimento do software acaba sendo inimiga da qualidade e, de fato é, inimiga da flexibilidade.

Em algumas situações é necessário usar a qualidade de “o bom o suficiente”, onde o software alcança os requisitos mínimos e atende as expectativas.

O que serve de lição é:
- Conheça sua necessidade de aumento de qualidade
- Estude os padrões
- Identifique os padrões que se adequam à situação em questão
- Aplique os padrões de forma concisa

Ah, e continue tendo boas idéias para aumentar a qualidade de seu código, mesmo que elas nunca se tornem padrão de projeto algum dia.

Tags: patterns, qcon, qconsf2008

Enviar por E-Mail

Este post foi feito em 21 de novembro de 2008 às 4:50 por Fernando Hamasaki de Amorim na(s) categoria(s) Técnicas de Desenvolvimento de Software. Você pode seguir estas respostas pelo feed RSS 2.0. Você pode deixar um comentário ou fazer um trackback do seu próprio site.