Lendo um artigo do Phil Haack essa questão veio novamente à tona. No artigo ele diz (tradução livre): “Nós não estamos aqui para escrever software, estamos aqui para desenvolver produtos e entregar valor. Escrever código é só um meio para esse fim”.
Nessa frase ele vai direto ao foco da questão, escrever o software não é o objetivo, é apenas um meio para prover valor ao cliente. O cliente não paga pelo software em si, mas pelo benefício que o software proporciona.
Nós como desenvolvedores muitas vezes esquecemos que a informática é apenas um meio. Ela por si só, não tem valor algum. O que tem valor é o que a informática pode fornecer às outras áreas e mais especificamente ao usuário.
Mas então, sabendo que o software por si só não tem valor, o que define a sua qualidade? Para responder isso eu separaria a qualidade do software em duas categorias:
- qualidade do produto;
- qualidade do código.
Qualidade do produto
Considerando que o software é um produto que visa prover valor ao usuário, a sua qualidade nada mais é que o atendimento das necessidades do seu usuário. Um software de qualidade é aquele que faz, de maneira correta, o que o cliente precisa que ele faça.Para definir a qualidade do software precisamos entender a necessidade do usuário e com isso verificar se o software está atendendo de forma eficiente e eficaz.
Qualidade do código
No lado técnico do software, podemos analisar sua qualidade pensando na capacidade de continuar provendo valor ao cliente no decorrer do tempo. Ou seja, o software poderá atender as futuras expectativas do cliente? Poderá continuar evoluindo de maneira eficiente?Muitos fatores contribuem para que o código possa ser considerado de qualidade. Alguns deles são:
- está legível e bem documentado – o desenvolvedor entende facilmente o que está acontecendo;
- tem baixa complexidade – deve ser fácil entender como ocorre a execução do código. Partes complexas devem ser destrinchadas em partes menores e mais simples (vide complexidade fabrica);
- há testes – ao desenvolver novas funcionalidades podemos verificar de forma fácil que as antigas continuarão funcionando;
- o sistema pode ser estendido – alterar um código existente sempre pode gerar problemas. Um sistema construído de forma extensível sempre será melhor para se trabalhar (vide Open/closed principle).
Podemos argumentar que um software que não será evoluído não precisa ter um bom código, basta atender ao cliente. Certo? Certo!! Porém, quantas vezes podemos ter a certeza que o software realmente não continuará a ser desenvolvido após a primeira versão? Quantas vezes um sistema começa pequeno e quando vemos ele já está gigante e totalmente desorganizado?
Acredito que ter um software bem escrito vale a pena, mesmo quando o sistema só terá uma versão. Um software bem escrito normalmente apresenta menos bugs, o que por fim melhora a percepção do cliente e reduz o custo de retrabalho.
Balanceando os diversos fatores
No desenvolvimento de software sempre temos que balancear diversos fatores. Custos, prazos, expectativas do cliente, tecnologias envolvidas, etc. A qualidade do produto é inegociável, afinal, é por isso que o cliente está pagando. Mas, infelizmente, nem sempre a qualidade do código tem a devida atenção.Precisamos ver que a qualidade do código acaba refletindo na qualidade do produto. Um software com difícil manutenção ou com bugs acabará reduzindo o valor provido ao cliente.
A questão é balancear os diversos fatores, tentado otimizar ao máximo os recursos para obtenção da qualidade máxima. E não esquecer de dar a devida atenção a qualidade do código, que influencia na qualidade do produto.
