WTF-Brasil

Publicado em outubro 29, 2009 – 3:22 pm | por GraveHeart |

Escrito em 2005 por Philipp Lenssen, um texto mostrava a importância de bons programadores terem condutas que muitos poderiam considerar ‘defeitos’. Dias atrás, tive o prazer de reencontrar esse mesmo texto, e percebi que muita coisa continua atual. O que se segue é uma tradução / adaptação do texto original, com alguns comentários pessoais sobre o assunto. Reflitam. WTF’s não vem apenas dos usuários, mas principalmente dos programadores…

Ao longo dos anos, percebi que, por mais paradoxal que isso possa parecer, bons programadores devem ser preguiçosos e burros.

Preguiçosos, porque apenas programadores preguiçosos irão pensar em escrever o tipo de código que no fim fará o trabalho por eles. Preguiçosos, porque apenas um programador preguiçoso evitará a todo custo escrever trechos repetitivos e monótonos de código – o que evita a redundância, principal inimigo da manutenção no código-fonte. Principalmente, as ferramentas e processos criados por esse comportamento de pura preguiça irão aumentar a velocidade de desenvolvimento.

Isso tudo faz com que o programador preguiçoso um bom programador. Claro, isso é apenas uma parte da verdade: para um programador preguiçoso ser um bom programador, ele (ou ela) também deve ser extremamente ‘não-preguiçoso’ quando se trata de aprender a como permanecer preguiçoso – ou seja, qual software faz sey trabalho mais simples, quais métodos evitam redundância, e como ele pode fazer com que a manutenção do seu código seja a mais simples possível.

Em segundo, (e vou elaborar um pouco mais a partir daqui, porque o conceito é bem menos claro que o primeiro) um bom programador deve ser burro. Por que? Oras, se ele for inteligente, e tiver a consciência de que ele é inteligente, o programador irá:

a) parar de aprender
b) parar de ser crítico com relação ao seu próprio trabalho

O primeiro ponto fará com que seja complicado para ele encontrar novas técnicas para que trabalhar mais rápido. Basicamente, o programador que para de aprender não busca novas soluções, não busca novas alternativas e permanece preso às ferramentas e métodos que ele já conhece. O segundo ponto fará com que ele perca muito tempo debugando o próprio código. Na interminável luta entre um programador e o compilador, é melhor que o programador desista logo e admita que a culpa é sempre dele, e não do compilador, e vá tentar entender o quê ele está fazendo de errado. (nota: OK, há casos em que a culpa É do compilador. Mas são tão raros que dificilmente você vai encontrar várias situações assim no seu dia-a-dia).

Mas há um ponto ainda mais importante sobre porque um programador deve ser burro. Para encontrar sempre a melhor solução para o problema, ele deve ser capaz de manter uma mentalidade fresca e aprender a “pensar fora da caixa”. Tem em mente que o problema nem sempre é o que parece, e a melhor solução nem sempre é o que você imagina, e saber pensar em soluções alternativas e fora do comum.

O contrário disso não seria muito construtivo: conhecer todos os parâmetros e funções, e aceitá-los. Quem garante que os limites que você conhece são reais? Quanto menos você souber, mais radicais serão suas soluções: assim, melhores serão as ferramentes que você criará, e melhores serão os produtos que você desenvolverá com essas ferramentas.

Um bom programador sempre se perguntará “Por que?”, porque ele é burro (ou suspeita de um problema maior).

Um bom programador, quando confrontado com um problema vindo dos usuários, vai adotar a mentalidade de ser burro: ele começará a fazer as perguntas mais simples e infantis possíveis. Isso é porque ele não aceita os parâmetros sugeridos pra ele do que alguém pensa que pode estar causando o problema. Por exemplo, veja uma conversa típica de desenvolvedores web frente a um problema:

“Desde ontem, nosso cliente não consegue ver o logo no site.”
“Ele reiniciou o navegador?”
“Sim.”
“Ele reiniciou o computador?”
“Sim.”
“Limpou o cache?”
“Sim.”
“Ele roda o Internet Explorer 6?”
“Sim.”
“Tem certeza de que ele não consegue ver o logo?”
“Sim.”
“Ele olhou para o site na tela?”
“Como assim?”
“Talvez ele tenha visto o site impresso em papel.”
“Não, ele estava olhando para a tela.”
“Ele não consegue ver outras imagens também, ou só o logo?”
“Como? Bom, vou perguntar pra ele.”

Para fins de argumentação, vamos dizer que o cliente na verdade tenha desligado a exibição de imagens no navegador. Ou o seu filho desligou. Ou um funcionário desligou. Em qualquer caso, a resposta não poderia ser encontrada da “maneira inteligente“. Nenhuma das questões levantadas pelo programador exigiam algum talento em programação. Nenhuma. Mas simplesmente pelo motivo ser tão estúpido, somente a estupidez pode lidar com isso.

Muitas vezes, a suposição de que alguma ação do programador gerou um problema não passa de uma suposição. Sempre que possível, ouça apenas os fatos antes de começar a debugar, e ignore o que as pessoas pensam que seja a razão do problema.

E isso se aplica a VOCÊ. Recentemente, tive um problema aparentemente simples: migrar um sistema de um domínio X para o subdomínio de um domínio Y. Coisa aparentemente simples, se o domínio Y não redirecionasse automaticamente para o domínio Z no Ning, e o subdomínio não estivesse fazendo a mesma coisa. Depois de várias horas batendo cabeça com o DNS e o CPanel, decidi deixar pra lá e fazer algumas atualizações no sistema em questão. Nos primeiros minutos, descubro que o redirecionamento era feito pelo sistema, em um trecho de código que eu havia colocado por questões de segurança. Removido o trecho, tudo funcionou como deveria desde o princípio. Por descuido, cansaço e vários outros motivos, havia perdido tempo e cabelo com um problema que não existia, na verdade….

Pode parecer complicado, ou até mesmo burocrático, mas esse é um processo investigativo simples: quanto mais informações reais você possui, mais fácil é o processo de chegar ao que realmente está causando o problema. Aceitar que o usuário diga apenas “Há um problema no site, e acho que pode ter sido causado pela sua última atualização” só fará com que você perca horas, talvez dias, até perceber que na verdade o problema era mais simples do que parecia.

(Nota: sim, meus caros usuários, nós não tratamos vocês como idiotas ou ignoramos completamente o que você fala do problema por acharmos que somos melhores do que vocês. Nós fazemos perguntas E chegamos à conclusões baseado no que você nos diz que está acontecendo, não no que você acha que pode ser o problema. Na verdade, muitas vezes o que você acha só nos atrapalha. Bons programadores vão ignorar suas sugestões, pelo menos em um primeiro momento…)

Pensem nisso. Sejam burros e preguiçosos. E sejam bons programadores.

Technorati Tags: dicas, programação, Sistemas