Qualidade importa

Um argumento recorrente de quem não tem tanta preocupação com qualidade de software em geral é: "O cliente não quer saber dos padrões e métricas usados, quer que funcione e pronto". Isso é mais do que verdade, até porque, para boa parte dos clientes, não faz sentido explicar como os padrões do GoF, por exemplo, ajudam, quando usados de acordo, a gerar software de maior qualidade. Os clientes geralmente querem que os requisitos sejam cumpridos dentro de prazos e custos e não que se use o mais novo e balado framework. Mais ainda, apenas em casos que implicam manter compatibilidade, os clientes se preocupam com as tecnologias usadas no desenvolvimento.

Apesar de o argumento parecer extremamente lógico para boa parte dos casos, ele não é verdadeiro quando você olha para outro aspecto envolvido: a "empresa" que desenvolve. Em tempos de prazos cada vez mais apertados, desenvolver software sem se preocupar com seu futuro pode manter a empresa amarrada a um problema muito além do tempo necessário. É o típico caso de haver tempo para fazer duas (ou mais) vezes, mas não haver para fazer uma vez bem feita. Há, a meu ver, dois grandes problemas com software mal desenvolvido que, de uma maneira ou outra, irão criar outro conjunto de problemas. São eles:

1. Você passará muito tempo literalmente remendando erros e, provavelmente, criando outros. Isso toma parte da força de trabalho para algo que simplesmente não gera o lucro esperado se a gama de usuários for pequena. Para grandes empresas os custos para consertar o problema podem ser altos não apenas pelo conserto em si mas também para a marca, a percepção que as pessoas têm do produto ou empresa. Que o diga a Microsoft com o grande numero de service packs e com a falta de credibilidade que permeou o Windows por um bom tempo. E, pode acreditar, se você não tem qualidade ou credibilidade, alguém terá. No fim das contas, qualquer pessoa envolvida seriamente com qualidade, sabe que manutenção toma mais tempo do que desenvolvimento. Isso é fato e nos leva ao seguinte: bom desenvolvimento leva a um período de manutenções mais leves;

2. Outros projetos são afetados pela falta de qualidade do primeiro. Em especial, se algo não foi bem feito, provavelmente não será reusado, se for, o problema apenas aumenta já que temos uma propagação do erro. Se não é possível reusar, o tempo para desenvolvimento de novos projetos certamente crescerá e o retrabalho causado pela falta de reuso causará uma série de horas extras e daí para frente vc pode imaginar sozinho. Falta de reuso gera outro problema menos explicito que é o aumento na quantidade de erros e código a corrigir/refatorar;

Projetos com qualidade, por outro lado, têm, claro, uma série de aspectos positivos para a empresa e no fim das contas para os clientes. Para emparelhar com os problemas acima e ser um pouco chato, vou citar os mais óbvios e importantes:

1. Não passar meses corrigindo erros tem uma vantagem além da economia de tempo e dinheiro. Com bons produtos as chances de feedback e adesão de novos clientes crescem. Bom feedback é crucial para o amadurecimento não apenas do produto mas da empresa em si. Bom feedback lhe direciona para as necessidades mais importantes do cliente, lhe permite desenvolver funcionalidades não pensadas ou conhecidas antes e, então, estar hábil a conquistar novos clientes. Novos clientes, mais do que apenas mais grana, implicam mais popularidade, fortalecimento da marca e amadurecimento, agora especialmente da empresa que já pode pensar em lançar novos produtos com uma legenda do tipo "dos mesmos produtores de bla bla bla...";

2. Os tipos de vantagem trazidos pelo reuso são geralmente claras, imagine iniciar um projeto com 20% de código pronto, bonitinho. Mas, mais ainda, quando vc reusa código, percebe pontos nos quais ele pode melhorar, o contato mais freqüente lhe faz pensar sobre melhorias possíveis. É menos codigo para testar/corrigir/refatorar tambem. Sem reuso seu codigo/produto simplesmente não evolui e, novamente, daqui para frente vc pode imaginar sozinho.

Para finalizar, ficam algumas dicas simples:

1. Planeje! Mesmo planejamento mínimo é melhor do que nenhum e até metodologias ágeis como XP têm etapas para planejar o jogo. Planejamento geralmente passa por decidir escopo, atividades, como usar tempo e recursos disponíveis entre outras coisas, qualquer bom livro de gerenciamento de projetos explica como planejar. Depois, decidir e justificar, não se esqueça, quais tecnologias usar. Justificar lhe ajuda a fundamentar a escolha e evitar mudanças desnecessárias no decorrer do desenvolvimento;

2. Defina metas de qualidade reais baseadas nos recursos e tempo disponíveis. Metas irreais criarão atrasos e frustrações desnecessárias. Lembre-se da filosofia de não tentar "tirar leite de pedra". Tente criar metas gerais e, dentro destas, metas menores que devem ser alcançadas em etapas. Assim fica mais fácil...

3. ... controlar a qualidade, o que significa criar padrões e convenções a serem seguidas e verificar de maneira efetiva se são seguidas. Uma "convenção" interessante são testes. Obrigue-se a escrever testes. Só essa dica já daria para escrever outro post, testes praticamente gritam: "ei, isso aqui funciona".

4. Revise e tente fazer o codigo evoluir entre um projeto e outro. Só siga essa dica se vc seguir a 3 também. Procure identificar pontos fracos no código, pontos onde há tendencias de se usar um padrão e refatorar o que conseguir identificar. Uma boa maneira de se fazer isso é usar algumas ferramentas de inspeção de codigo como o PMD, Findbugs, Metrics e Checkstyle.

5. Faça todos os envolvidos pensarem em qualidades para não ocorrerem dissiparidades em partes do projeto. Mesmo que todos não estejam no mesmo nivel de conhecimento, boa comunicação entre os desenvolvedores pode garantir ou ao menos diminuir as chances de os menos experientes cometerem erros.

valeuz...