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 e capacidades 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?

Imagine que você esteja fazendo um bolo de sobremesa para alguns convidados. Enquanto mistura os ingredientes, você assiste as notícias na TV e, por um ato de distração, coloca 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) esta 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. A situação é mais séria, não? Na pior das hipóteses, a confeitaria perderia o cliente.

No caso do desenvolvimento de software, os papéis basicamente podem se 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 o software permitiu que isso acontecesse?

E, então, o GIGO entra na história.

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. O mesmo acontece se o usuário digitar um valor muito extenso ou um valor negativo em uma tela de cálculo.

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

Uma das formas 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 e 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 realçar 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 para evitar o GIGO. 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 pela leitura! Abraço!

Publicado originalmente no blog SubRotina

Imagem ilustrativa original em CrakGenius