GIGO – Garbage In, Garbage Out

Profissionais de qualquer ramo de negócio geralmente conhecem o perfil de seus clientes e tomam as ações necessárias para mantê-los. Porém, nós, programadores, lidamos com um tipo de indivíduo um tanto quanto imprevisível: o usuário de software. Muitas vezes desconhecemos suas intenções, capacidades e raciocínio ao manipular os dados de um sistema e devemos considerar esse fato durante o desenvolvimento. Se não nos centralizarmos nessa questão, o produto estará suscetível ao problema de GIGO! Conhece essa expressão?

Introdução

Já vou iniciar o artigo fazendo analogias, haha. Quem leu os outros artigos, sabe que muitas vezes procuro elaborar analogias para facilitar a compreensão de determinados conceitos. Na verdade, essa é uma metodologia de compartilhamento de conhecimento que conheci ao ler o livro Resultados Previsíveis em Tempos Imprevisíveis, de Stephen R. Covey. O autor faz bastante uso de analogias, metáforas e comparações para captar a atenção do leitor.

Pois bem, without further ado, vamos ao que interessa!

Imagine que você esteja fazendo um bolo de sobremesa para alguns convidados em um domingo comum. Enquanto mistura os ingredientes, você assiste as notícias na TV e, por um ato de distração, acaba colocando sal ao invés de açúcar no recipiente. Claro, você não percebeu o erro, portanto, continua fazendo o bolo. Mais tarde, quando os convidados experimentaram o bolo, o gosto (logicamente) estava terrível.

Você mesmo experimentou um pedaço, sentiu algo estranho no sabor e se desculpou pelo inconveniente. Como são seus convidados, todos compreenderam o erro e você provavelmente terá uma nova oportunidade de fazer outro bolo para eles.
Agora imagine essa situação em um ambiente de negócios, ou melhor, imagine que isso tenha acontecido em uma confeitaria. O buraco é mais fundo, não? Na pior das hipóteses, a confeitaria perderia o cliente.

Em que essa analogia se aplica?
No caso do desenvolvimento de software, os papéis basicamente podem ser inverter. Se o software está gerando resultados ou estatísticas incorretamente, existem duas possibilidades: o software possui algum erro no processamento ou o usuário entrou com dados inconsistentes. A primeira possibilidade representa um bug e deve ser corrigido, ponto final. Mas, e a segunda possibilidade? Embora entrar com dados inválidos tenha sido um erro do usuário, por que cargas d’água o software permitiu que isso acontecesse?
E então, o GIGO entra na história! Olá, GIGO.

GIGO

Não, não é desse GIGO que estou falando. A expressão GIGO, no cenário de desenvolvimento de software, é um acrônimo para Garbage In, Garbage Out. Na prática, se “lixo” é colocado pra dentro, então o que sairá pra fora também será “lixo”. Nada mais justo: se eu entrar com dados inválidos em um software, evidentemente os resultados gerados por ele também serão inválidos.

Por exemplo, suponha que no cadastro de fornecedores há uma regra para definir a data de validade dos contratos baseada na data de emissão. Durante o cadastro de um fornecedor, o usuário, por um ato de distração (assim como na receita do bolo), informa uma data de emissão do ano retrasado ou uma data maior que a atual. Resultado: caso for necessário gerar um relatório com os status dos contratos ou informações daquele fornecedor em particular, a saída não será correta.

E vou ainda mais longe. Imagine que o usuário tenha digitado um valor muito extenso ou um valor negativo em uma tela de cálculo? Bom, nem preciso comentar…
O conceito do GIGO define que “só porque é um computador, não significa que ele necessariamente estará certo”. O computador apenas processa as informações que são dadas à ele, logo, a saída correta não depende somente dele. Veja o paradigma do GIGO:

  • Se dados inválidos forem submetidos à uma modelagem perfeita, a saída será inválida
  • Se dados perfeitos forem submetidos à uma modelagem inválida, a saída será inválida
  • Se dados perfeitos perfeitos forem submetidos à uma modelagem perfeita, a saída será válida

Evitando o GIGO

A melhor forma de evitar o GIGO é criar restrições extensivas para “proteger” o software destes eventos. Colocar máscaras em campos, forçar caracteres numéricos, restringir a quantidade de caracteres, definir intervalos de valores, validar datas e controlar a seleção de dados de entrada são medidas eficientes para aumentar a confiabilidade do software. No caso da receita de bolo, seria melhor se os potes de açúcar de sal tivessem rótulos na tampa ou algo tátil para diferenciá-los, concorda?

É fato que praticamente todos os desenvolvedores já tomam esse tipo de cuidado durante o trabalho. No entanto, erros dessa natureza são comuns e algumas vezes deixam de ser tratados. É importante destacar que o GIGO não envolve somente erros de digitação, mas também sequências de atividades (processo para emitir uma Nota Fiscal, por exemplo) ou ambiguidade de informações que conduzam o usuário a selecionar dados inválidos.

Além das restrições comportamentais, sugiro a criação de testes automatizados. Testes bem elaborados permitem submeter o software à diferentes cenários que possam causar inconsistências nos dados. A confiabilidade do software aumenta na proporção que o código-fonte é coberto de testes. Pensem nisso!

Se possível, procurem estudar e aplicar a técnica de TDD (Test Driven Development) durante a atividade de implementação. Além da cobertura de testes, o TDD permite que o código seja validado e refatorado na medida em que a implementação é criada. Vale a pena conferir essa técnica!

 

Obrigado mais uma vez pela visita, leitores, e… cuidado com o GIGO! 🙂
Abraço!


André Celestino