Mas o que é, exatamente, um software de qualidade? O que pode ser usado para medir a qualidade de um software? Beleza? Simplicidade? Quantidade de que merda! exclamados pelos usuários?
Acredito que há quatro fatores fundamentais para que um software possa ser considerado como de qualidade. Em primeiro lugar, sua corretude: o software deve fazer aquilo que o levou a ser feito, ou seja, deve atender às necessidades dos usuários.
Em segundo lugar está sua velocidade: de nada adianta fazer um sistema que faça o que o usuário espera dele, mas leve tanto tempo para isso que o usuário tenha tempo de ir à máquina de café.
Em terceiro lugar vem a facilidade de uso: a palavra está um pouco banalizada atualmente, mas a usabilidade de um sistema é um fator chave para o seu sucesso.
Por fim, sua facilidade de manutenção: este é um dos requisitos com o qual o usuário se importa pouco ou nada, mas que garante a sobrevida do produto, já que todos nós somos péssimos programadores e, uma hora ou outra, vamos precisar acrescentar a ele novas funções ou corrigir antigas.
Como garantir, então, que o software com o qual você está trabalhando tenha estas quatro características?
Corretude
Garantir que o sistema faça o que o usuário espera dele requer duas atitudes primordiais: entender e testar.
Entender significa que você deve realmente saber o que deve ser feito, quais são as expectativas do usuário. Aqui não há espaço para achismos. Por experiência própria, eu te garanto: na maioria das vezes em que você tenta adivinha o que o cliente quer, você quebra a cara, e feio.
Nada impede que você sugira idéias. Elas são bem vindas sempre. O que não dá pra fazer é simplesmente supor.
Já testar significa exatamente isto: testar se o que você fez funciona como era esperado. E, além disso, é preciso testar se o que você fez não quebrou alguma coisa que já estava funcionando antes. Eu tenho criado o saudável hábito de escrever uma série de verdade absolutas sobre as coisas que faço, e a cada alteração nos sistemas eu verifico se as verdades ainda estão valendo. Se não estiverem, alguma besteira eu fiz. Sim, eu sei que dá trabalho, mas lembre-se do que diz a regra nove do Padrão Marinato de Qualidade: os testes devem durar duas vezes e meia o tempo de programação.
***
Velocidade
Tem muita gente por aí que, pra tirar o próprio rabo da reta, sugere a compra de mais memória quando o cliente reclama da velocidade do sistema.
Sim, eu sei que há casos em que a culpa é realmente do cliente, que tenta enfiar o mais novo sistema operacional em uma máquina de oito anos atrás, mas é preciso lembrar, também, que todos somos programadores fracos, e é bem provável que você tenha feito alguma besteira, ou que tenha deixado de fazer algo a mais.
Não estou falando de fazer tuning no seu sistema, o que nem sempre é uma boa ideia, mas apenas de prestar atenção nos seus laços e repetições, nas configurações do compilador e no uso de threads, se sua linguagem de programação permitir isso.
Encarei esse problema recentemente no projeto em que estou trabalhando: nele, sempre que uma determinada janela é fechada nós gravamos um arquivo com os dados que estavam sendo exibidos. Este recurso já está pronto há meses, até que um cliente reclamou de um engasgo no sistema sempre que fechava a tal janela.
Fomos verificar e descobrimos que tínhamos feito a besteira de gravar os dados em etapas, abrindo e fechando o arquivo milhares de vezes ao invés de fazer a operação toda em uma pancada só.
***
Facilidade de Uso
De pouco adianta um sistema que faça mil e uma coisas se o usuário se sente como um cego perdido em meio a um tiroteio, diante de todos botões e menus, sendo obrigado a frequentar um curso intensivo de dois meses para usá-lo.
Para se construir um software fácil de usar é preciso estar sempre em contato com o usuário, obtendo seu feedback incessantemente.
E, embora possa parecer frescura, o trabalho de um designer competente é muito importante, já que animal mais raro que programador bom em design só mesmo advogado que não seja venenoso.
***
Manutenibilidade
Qualidade essencial porém invisível para o cliente, a facilidade de se dar manutenção em um sistema é essencial para que ele possa ter vida longa de uso.
Lembre-se que, assim como acontece nos livros de cartório, o que você escreve hoje será lido daqui a seis meses, um ano, dois anos, por você e, com certeza, por muitas outras pessoas, algumas das quais, é certo, não terão você por perto. Ou você não pensa em tirar férias?
Logo, é preciso sempre ter em mente a Grande Lei do Desenvolvimento: escreverás código que humanos sejam capazes de entender. E não apenas isso: adote padrões de projeto que estruturem o seu sistema de maneira que as pessoas, entendendo o padrão, possam saber onde estão pisando.
E, veja bem, querida leitora, quando falo em padrões de projeto, não estou falando só dos Padrões de Projeto que nos ensinam na faculdade, mas também em produzir código padronizado e consistente, com convenções bem estabelecidas e conhecidos por todos.
Estas recomendações culminam, por fim, em um ponto importante: documentação. É preciso registrar o raciocínio por trás de todas aquelas linhas de código. Entender porque determinadas decisões de projeto foram tomadas (ou não) é parte essencial do trabalho de mudar algo que já está pronto.
***
Aí estão, então, os quatro principais pontos com os quais me preocupo quando estou trabalhando na construção de um sistema.
É claro que volta e meia eu escorrego e deixo de seguir uma ou outra de minhas próprias recomendações, mas isso também faz parte do aprendizado.
Artigo inspirado por um outro, de Steve Feuerstein, da Oracle Magazine, escrito ao som das músicas religiosas de Elvis Presley.
Outros artigos meus sobre análise de sistemas
Nenhum comentário:
Postar um comentário