Abstração

O problema não podia estar mais claro. Era algo tão trivial, cotidiano. Fomos logo codificar. Afinal, porque perder tempo analisando algo que se vive no dia a dia? Era melhor aplicar a força intelectual na resolução.

Mas a análise não seria a premissa da solução? Bem, é sabido que todos analisam tudo antes de codificar (?), mas será que esta verdade se repete quando o problema é trivial? Quando desconhecemos o problema, tomamos um de dois caminhos: ou estudamos ou encontramos “o cara” que sabe das coisas, o analista de negócios, de processos, o expert no assunto. Tempo para nós mesmos decifrarmos a correção? Difícil...

Mas o caso era outro: era muito simples.

De imediato, surge a abstração, a forma com que esperamos levar a solução/problema para a máquina e virtualizar a resposta. Pensamos em objetos, nos orientamos a soluções e por fim materializamos uma idéia na forma de códigos e telas. Tudo pronto, uma formulação matemática pode resumir todo um pensamento. No entanto, orientamos o nosso pensamento proporcionalmente a complexidade do fato.

Isto significa que imaginamos soluções simples para problemas simples.

Eureka! Isto é maravilhoso.

Mas como julgamos a simplicidade de um problema? É possível imaginar uma solução simples para um problema que acaso imaginamos ser simples. Mas se o problema não era tão simples assim, nossa solução poderá ser falha, ou seja, haverá re-trabalho.

Vamos partir do ponto que, o bom seria soluções simples para qualquer tipo de problema. Pronto, desta forma nos orientamos que a resolução deverá caminhar para uma única estrada. Agora vamos nos ater ao julgamento do problema.

Sem querer pensar em Hume ou Descartes, o caso é que, constantemente, alternamos nossas decisões com base em conhecimentos adquiridos, ora empiricamente, ora racionalmente. Nossas decisões oriundas do pensamento racional, são aquelas em que agimos segundo um conceito adquirido num processo de busca intencional. Por exemplo, deverei usar o lambda para resolver isto porque, num dado momento, me houve uma necessidade parecida, precisei aprender lambda e, a partir daí, julgo ou sei os casos em que posso utiliza-lo. Este julgamento depende do quanto aprendi sobre lambda.

Quando algo é natural ao meu desenvolvimento, sem custo de aprendizado, julgo sua utilização conforme meu aprendizado ambiental, não necessariamente advindo de um fator externo ao meu meio.

Semana passada, no Coding Dojo Niteroi, foi levada uma proposta de problema bastante interessante: o caso do mijão. O problema era, quando um homem adentrasse em em banheiro público, ele procuraria o banheiro mais distante da porta; o próximo cara, ficaria o mais distante deste homem; e o próximo, so utilizaria um mictório caso houvesse a distancia de pelo menos um mictório entre os caras da direita e da esquerda.

Simples assim.

Pelo menos eu faço isto todo os dias, chego e se o banheiro está vazio, vou logo para o mais longe da porta. Onde trabalho tem três mictórios. Se já tem alguém, vou para longe dele, respeitando a “zona de respingo”. Se tem alguém no meio, espero.

É muito natural, tanto que eu nem saberia explicar quem ou mesmo se alguém me ensinou. É parte do meu meio de criação.

Assim, fomos direto ao código e, pessoalmente preocupei-me mais com a Linguagem de Programação aplicada do que com o problema em si. Intimamente já sabia que o primeiro ia para o ultimo, o segundo para o primeiro e o terceiro esperava. Sim, eu sabia. Dificuldade mesmo era na declaração de um array específico que quería-mos usar.

Até que uma boa alma pergunta: e se forem quatro ou cinco mictórios?

É preciso confessar que somente neste instante me deparei que o trivial não era tão simples quanto se mostrava. Divaguei em minhas reflexos, conversei com meus botões, tentei formulações matemáticas, e apenas descobri que um problema é sempre um problema. Nem difícil e nem fácil, apenas problema.

Em meus pensamentos pude notar um certo remorso, pois fui logo pensando em algumas soluções antigas que utilizei no passado, o quanto eu desrespeitei o problema em si. Sim, foi mesmo desrespeito e, claro, tive re-trabalho.

Sempre acreditei que, nestes casos, a análise era incompleta, mas na verdade era falha mesmo. O problema foi considerado simples e a análise foi apenas simples. Logo, no lugar de uma solução simples, produzi algo imaturo, que nem era solução.

Como julgar se o problema é simples ou complexo? Não julgue, problemas são problemas. Aliás, em termos de programação, não julgue nunca, tenha sempre certeza. E isto possível? Bom, encerro com uma outra questão: acaso duvida que 2 + 2 = 4?