Mergulhando no Caos

Programar um novo sistema é como projetar seu próprio mundo. É preciso descrever como as coisas vão interagir e como as mudanças vão se propagar no ambiente. Os programadores podem começar com nada mais que uma idéia, materializá-la em código e produzir algo vivo. Como bônus extra, suas criações podem ainda ajudar a resolver algum problema do mundo real. Ao projetar seus sistemas eles têm a oportunidade de experimentar a alegria da criação, a surpresa da descoberta, o prazer da invenção e tudo que houver no meio.

Ter seu próprio mundo de faz-de-conta e ainda usá-lo para resolver problemas do mundo real parece tão divertido que deve ser praticamente impossível de se tornar um trabalho chato.

Mas a verdade é que muitas vezes se torna. Afinal de contas a vida não é um conto de fadas. Mais cedo ou mais tarde, vem aquela vontade de repetir estruturas de código familiares, aplicar soluções não muito apropriadas e — pasmem! — copiar e colar código. O pior problema das soluções sujas é a capacidade de atrair mais janelas quebradas. Para se afundar na lama do código ruim, basta cometer a primeira transgressão. As demais virão naturalmente simplesmente porque o código já está sujo e as pessoas vão começar a pensar que uma gambiarra a mais ou a menos não vai fazer mal a ninguém.

A boa notícia é que existe um detector natural para quando se está fazendo besteira. Algo como um canário em uma mina de carvão. Este algo é o tédio. Escrever código repetido é chato. Tentar adaptar uma solução onde ela não se encaixa muito bem é chato. Copiar código de um lugar para outro é chato. Tédio é um subproduto natural do trabalho impensado, então basta eliminar suas causas para evitar boa parte dos danos ao código.

Programar pode ser um dos exercícios intelectuais mais desafiadores. Quando o desafio e a diversão são substituídos pelo tédio, alguma coisa está errada. A solução para boa parte dos casos é procurar uma forma de eliminar a repetição e — adivinhe só — computadores foram feitos justamente para isso. Se trabalhamos para evitar que os outros façam trabalho repetido, por que iríamos nós mesmos nos repetir? Por que se entediar quando a máquina pode executar a mesma tarefa indefinidamente sem cansar nem reclamar?

Eliminar repetição não é fácil e justamente por isso é divertido. Da próxima vez que estiver programando, imagine que você não pode repetir a mesma idéia duas vezes. Veja repetição onde ninguém está prestando atenção. Observe o que é chato de ser feito. Procure resolver estes problemas sem criar outros. A sua solução pode vir em vários sabores: talvez haja uma nova abstração pronta para ser codificada, uma biblioteca querendo nascer ou uma nova linguagem escondida em algum lugar. Tente descobrir o que se aplica ao seu caso. Enquanto estiver fazendo isso, tenha em mente que você não deve se entediar em nenhum momento.

Mantenha o ânimo em alta para manter a sujeira em baixa.

Eduardo Fiorezi publicou ontem o primeiro episódio do que espero que seja uma longa série de podcasts sobre desenvolvimento de software e eu tive a honra de ser o primeiro entrevistado do programa. Ele está bastante interessado em abordagens ágeis, tecnologias para aumentar a produtividadefelicidade do programador e novidades na área de desenvolvimento de software. Portanto, o conteúdo deve interessar a eventuais leitores deste blog.

Só que o podcast tem a vantagem de não exigir atenção exclusiva dos seus olhos. Dá para escutar a caminho do trabalho, ao fazer seu exercício diário e até enquanto programa alguma parte chata do seu sistema. Se bem que se há algo de chato no seu sistema, há algo de errado.

Então você pensava que receber atenção era uma necessidade exclusivamente humana ou no máximo do seu cachorro — ou gato, não quero começar uma guerra cães vs. gatos aqui. A novidade é que isso acontece com máquinas também. Olhe estes velocímetros, por exemplo:

O velocímetro da direita é uma dessas máquinas carentes. A graduação é confusa porque os trastes usados para as velocidades numeradas são apenas um pouco mais espessos do que os das intermediárias. O problema fica mais evidente depois que se passa de cem quilômetros por hora. Os números de três dígitos precisam ficar bem próximos uns dos outros e, se você olhar rapidamente, não vai saber se está a 130 ou 140. É preciso parar e se concentrar para diferenciar qual o traste mais espesso. É preciso dispensar mais atenção do que deveria ser necessário para um velocímetro. Sem falar que não dá para fazer isso e olhar para a estrada ao mesmo tempo.

O da esquerda é muito mais seguro de si. Os trastes intermediários são bem mais finos que os principais. Como se não bastasse, eles são mais curtos também e o espaçamento é muito maior. Ele é um velocímetro que não implora para ser olhado, apenas fornece a informação e sai do caminho.

Se você projeta algum tipo de máquina (e todo programador faz isso), tome cuidado para não fazer uma dessas máquinas carentes. As pessoas já estão suficientemente ocupadas dando atenção para outras pessoas. As máquinas não devem competir com isso.

Este é o último artigo de uma série de três derivados de uma palestra apresentada na FAPE em outubro de 2006.

---

Muita inovação acontece nas margens do sistema, pelas mãos de quem ainda não faz (ou nunca vai fazer) parte das panelinhas que todo mundo presta atenção.

Quem está em destaque tem uma certa obrigação oculta de continuar fazendo sucesso. Isto não está escrito em lugar nenhum, mas eles se sentem pressionados mesmo assim. Por causa dessa pressão invisível é que eles tendem a se concentrar em atividades de baixo risco. Uma das práticas de baixo risco mais comuns é repetir seu primeiro grande feito à exaustão. Se você já descobriu algo que faz sucesso, porque arriscar? Veja Dan Brown, por exemplo. Depois que ele escreveu O Código Da Vinci e o livro apareceu em listas de mais vendidos do mundo inteiro, ele já o reescreveu algumas vezes. Claro que o título e o enredo mudam toda vez, mas a estória é essencialmente a mesma. Ele faz isso porque dá certo. As pessoas compram os livros dele porque sabem o que esperar.

Repetição não é ruim. Repetição é um dos elementos fundamentais da evolução. Quando os animais se reproduzem eles basicamente se repetem, fazem cópias de si mesmos. Se essa repetição fosse exata, o que chamamos de clonagem, não haveria evolução porque não haveria mudança. Mas na vida real o que acontece é que a estrutura básica é repetida e mudam-se alguns detalhes menores como a cor dos olhos, a espessura dos pêlos e a estatura. A partir destas pequenas diferenças é que ocorre a evolução. O mesmo ocorre com as idéias de sucesso. Sua estrutura principal é repetida e alguns detalhes são modificados. De acordo com a receptividade, estes detalhes são novamente modificados e novas mutações são testadas.

Os veteranos em todos os ramos são muito bons nesse tipo de evolução experimental, eles podem mudar pequenas coisas de modo a gerar coisas novas mas extremamente parecidas com as antigas. Este processo é lento por natureza. Para chegar a um novo produto desse modo é necessário fazer várias modificações e cada uma das modificações precisa ser testada para a aceitação do público. Isto leva tempo.

Mas às vezes o que precisamos não é de evolução lenta. Às vezes precisamos de saltos evolucionários para não ficarmos presos em máximos locais. Para isso é necessário introduzir um elemento inesperado, uma fonte de aleatoriedade qualquer. Na natureza, a reprodução sexuada vem cumprindo muito bem esse papel e nos negócios sangue novo também é muito bom para isso. Os novatos não tiveram as idéias influenciadas pelas limitações atuais do mercado e da tecnologia, por isso têm facilidade para pensar em coisas completamente novas.

Essas limitações podem ser um grande problema. As idéias novas parecem preferir as cabeças mais frescas. Quando se está no meio da selva matando um leão por dia, fica difícil achar tempo para ter grandes idéias e pensar no futuro. Muita gente acaba queimando a língua por causa disso.

Há controvérsias, mas algumas fontes relatam que Thomas Watson, então presidente da IBM, disse em 1943 que talvez houvesse no mundo inteiro mercado para cinco computadores. Era a época da Segunda Guerra Mundial. Os computadores eram usados principalmente para quebrar códigos de mensagens militares e eram grandes a ponto de ocupar várias salas. Naquela época não havia a sala dos computadores, mas as salas do computador.

Nessa situação é fácil imaginar que o mundo teria poucos computadores. Era preciso ter muitos recursos para isso e as únicas entidades com recursos e interesse suficientes para obter um eram uma meia-dúzia de governos.

Já a revista Popular Mechanics, em uma edição de 1949 acertou em cheio. Eles publicaram que “no futuro, os computadores pesarão não mais do que uma tonelada e meia.” Algumas décadas depois realmente é difícil achar um computador com uma tonelada e meia. Mas é fácil encontrar um com alguns gramas no bolso de qualquer adolescente.

Em 1977, quando a Apple lançava seu computador pessoal Apple II, Ken Olsen, fundador da Digital Equipment disse que não via razão para alguém querer um computador em casa. A DEC produzia o que eles chamavam de mini-computadores que eram usados principalmente para pesquisa científica. Realmente, ninguém iria querer um desses em casa, mas hoje muita gente não sabe como iria viver sem um computador pessoal.

Os produtos realmente inovadores são surpreendentes porque ninguém acha que precisa deles antes de existirem. Ninguém precisava do computador pessoal antes dele existir. Ninguém precisava de celulares. Ninguém precisava de câmeras digitais. Ninguém precisava de mouses. Mas hoje tem muita gente que não sabe como vivia antes deles.

Todas estas pérolas são de gente que já estava envolvida em seus respectivos nichos há um certo tempo. Eles simplesmente não conseguiam ver os saltos evolucionários. Eles estavam muito ocupados resolvendo os problemas de hoje e não tinham tempo para pensar nos de amanhã.

Os novatos não têm essas limitações ainda. Eles não foram tão expostos à situação atual como os veteranos. O problema deles é outro: recursos.

Semana passada eu li sobre como as telecom estão querendo estratificar a Internet para cobrar direitos de transmissão sobre os meios de alta velocidade. Na ponta dos links da Internet estão os roteadores e eles têm uma fila interna. A idéia é que se você pagar mais, seus pacotes (suas mensagens) tenham prioridade de transmissão. Atualmente, a fila é mais ou menos justa: se você chegar primeiro, você é atendido primeiro. O que eles querem é que algumas pessoas possam furar a fila.

Se elas conseguirem fazer isso (e eu não tenho certeza de que seja possível), vai ser um grande golpe para a inovação. Muitas das idéias inovadoras de hoje saem das cabeças das pessoas comuns e elas não têm os recursos que as grandes corporações têm. Se as filas de transmissão não fossem igualitárias, não seria possível que um programador de São Francisco inventasse e testasse o BitTorrent. Se os grandes provedores de conteúdo tivessem preferência de tráfego, ele não poderia fazer suas experiências usando sua conexão residencial comum. Os pacotes dele teriam prioridade extremamente baixa e ficariam um bom tempo presos no congestionamento. Seria preciso convencer algum investidor com bom poder de fogo a financiar o projeto. E os investidores podem não ser muito receptivos à inovação.

Inovar é arriscado e quando você é velho e famoso, não pode se dar ao luxo de fazer papel de idiota. Mas se você é jovem e desconhecido, ninguém vai ficar sabendo do seu fiasco. Você pode ousar mais quando não tem medo de bancar o idiota.

Este é o segundo artigo de uma série de três derivados de uma palestra apresentada na FAPE em outubro de 2006.

---

Prática certamente é uma Boa Coisa™. Eu até acredito que tem algumas coisas que não dá para aprender sem praticar. Para estas (e elas são muitas) é mais interessante estudar um pouco, praticar um pouco, depois estudar mais um pouco e repetir o ciclo eternamente. Você não pode dizer que sabe sobre alguma coisa antes de usá-la de verdade. Mas conhecimento prático somente, não é suficiente.

Se eu quiser programar, por exemplo, não basta que eu devore o manual de alguma linguagem de programação e comece a escrever meus próprios programas. Eu até posso fazer isso, se eu quiser só programar. Mas se eu quiser fazer bem, é preciso estudar como quem já está nessa há mais tempo faz as coisas. Se eu simplesmente me trancar no meu quarto de madrugada para programar, a excelência vai ser um objetivo distante. Alcançável, mas bastante distante. É preciso ler código dos outros, procurar por construções comuns em vários programas e identificar boas práticas.

Mas isto não é o bastante. Se eu quiser mesmo ser Bom com ‘B’ maiúsculo, vou precisar estudar algumas coisas que aparentemente não têm nada a ver com o ofício da programação. Coisas como teoria dos grafos, protocolos de comunicação entre computadores e inteligência artificial. Mesmo que eu ache que não vá usar diretamente nada disso, é bom me expor pelo menos um pouco a estes assuntos.

Estudar tudo isso vai alargar meus horizontes de conhecimento. Eu não vou saber nenhum desses assuntos a fundo, mas vou saber que há outros mares para explorar, novas possibilidades. Assim podemos traçar paralelos e estabelecer analogias que podem levar a idéias geniais. Não é preciso mais do que uma breve exposição para isso.

Ter uma noção de cada assunto é ter conhecimento horizontal. É o conhecimento usado para chegar a uma dessas analogias que fazem a maior diferença. Também é o conhecimento usado para impressionar os outros. Você não precisa saber muito de comunicação de computadores para falar em rotedores, pacotes e protocolos.

Se tudo que você quer é ter assunto para conversar, conhecimento horizontal é o que você precisa. Para resolver problemas interessantes, é preciso conhecimento vertical. É preciso se aprofundar em algum nicho, se especializar.

Muitas tecnologias populares começam em pequenos nichos. São usadas por muito pouca gente no início, mas um dia alguém com visão resolve aplicá-las em um contexto diferente e a coisa explode. A Internet é um exemplo disso. Ela começou como forma de comunicação entre centros universitários e era usada também para troca de dados militares. No final da década de 80 e início dos anos 90, foi desenvolvida a base para a Web moderna e a partir daí a coisa explodiu. Claro que isso é uma simplificação da realidade (e o que não é?), mas ilustra o ponto de que um especialista que estuda um assunto a fundo pode ver oportunidades que os demais nunca vão imaginar.

Mas especialização demais também pode ser uma armadilha. Ela começa a ser perigosa à medida que se desiste do conhecimento horizontal pelo vertical. Fazer isso é desistir de idéias brilhantes ligando um campo do conhecimento ao outro. Especialização demais pode estreitar a visão a ponto de só permitir enxergar o próprio nariz.

Este é o primeiro artigo de uma série de três derivados de uma palestra apresentada na FAPE em outubro de 2006.

---

Previsibilidade é quase o oposto de criatividade. À primeira vista, podemos colocar criatividade e previsibilidade em dois extremos do mesmo eixo. Para aumentar uma, é preciso diminuir a outra.No extremo da previsibilidade temos organizações que têm somente capacidade de repetição. Suas atividades são facilmente gerenciadas por serem extremamente previsíveis. Uma forma de alcançar este grau de previsibilidade é inventar sempre a mesma coisa. O problema é que repetir a mesma coisa várias vezes não é inventar. Por isso que esses lugares altamente previsíveis são extremamente chatos para se trabalhar. Você está sempre fazendo as mesmas coisas. Escrevendo o mesmo relatório para o mesmo gerente.

No lado extremo da previsibilidade, temos fábricas tradicionais, com linhas de montagem e tudo mais, como as que Henry Ford projetou. Nestas fábricas tudo é extremamente previsível. Se colocarmos uma peça no começo da linha, podemos saber com uma boa precisão quando ela passará por cada um dos estágios. Essa previsibilidade é alcançada através de muita padronização e repetição.

No outro extremo estão as organizações que escolheram abandonar totalmente a previsibilidade em favor da criatividade. Essas inventam coisas maravilhosamente interessantes, mas não se pode confiar muito nelas para estabelecer prazos. Você sabe que dali vai sair alguma coisa surpreendente, mas ninguém sabe dizer quando. Estes lugares também são muito chatos para se trabalhar, porque parece que nunca vão acabar de construir nada. Sempre há um último retoque para ser feito. Sempre aparece um novo projeto interessantíssimo para deixar o anterior inacabado.

É deste lado que ficam alguns artistas, como Leonardo da Vinci. Ele era conhecido por atrasar as encomendas e tem gente que diz que às vezes ele até colocava alguns significados ocultos nas telas. Fazer uma encomenda a ele era receita certa para uma boa dor de cabeça. Ele não ia entregar no prazo e no final o que ele entregasse podia não ser muito bem aquilo que você tinha pedido. No entanto, ninguém pode dizer que ele não era criativo. O cara era a inovação em pessoa, inclusive foi pioneiro em muitas áreas de pintura, engenharia e anatomia.

É natural perguntar quantos carros uma fábrica pode produzir por dia. Mas não faz sentido nenhum perguntar a nenhum pintor que se preze quantos quadros ele pode fazer por mês. Cada quadro é uma obra única e o tempo de produção pode variar demais para que estimativa seja minimamente precisa.

Nenhum dos dois extremos é bom. A boa notícia é que não precisamos escolher entre preto ou branco. Há vários tons de cinza entre eles que podemos explorar.

Ao contrário do que possa parecer, não precisamos escolher entre uma e outra. Previsibilidade e criatividade não estão no mesmo eixo. As duas são ortogonais. Não precisamos necessariamente diminuir uma para aumentar a outra. Não é preciso ser imprevisível para ser criativo. Talvez as variáveis não sejam tão independentes como queiramos, mas também não são tão intrincadas que não dê para separá-las um pouco.

A menos que você esteja querendo reconstruir alguma coisa que já tenha construído, desenvolver software é um processo criativo. Só que nem todo programador pode se dar ao luxo de fazer como Da Vinci e desrespeitar prazos e demandas. É preciso ter algum grau de previsibilidade para agradar os clientes.

Para lidar com este problema é que foi inventada a iteratividade. O segredo é projetar o software em ciclos curtos chamados de iterações. No início de cada iteração, a equipe combina com o cliente o que deverá ser produzido durante um certo período de tempo e ao final deste período o cliente recebe um sistema funcional que pode ser testado. Pode ser que o sistema seja bem pequeno, minúsculo. Mas ele evoluirá ao longo do tempo até chegar uma hora que o cliente diga ‘está bom, era isso que eu queria’ e os programadores possam procurar um novo projeto.

Uma boa forma de se enganar é não entregar software rodando ao final da iteração. Você pode, no lugar disso, entregar um calhamaço de documentos, só para provar que não ficou parado o tempo todo. A idéia é que quem quer que esteja pagando pela sua empreitada possa validar esses documentos e dizer ‘continue, você está no rumo certo’ ou ‘não é bem por aqui, acho que devemos mudar de estratégia’.

Quando se usa um documento para esse tipo de comunicação, uma de três situações pode ocorrer. A primeira é o cliente validar seu documento e assinar embaixo, só que ele estava pensando em uma coisa quando leu e você estava pensando em outra bem diferente quando escreveu. A segunda é ele não concordar com o que você escreveu e implicar com as menores coisas para ter certeza que você entende o que ele está querendo. Essa segunda situação pode facilmente descambar para um fluxo eterno de remendos ao documento que impede que a coisa de verdade seja construída. A terceira possibilidade é que ele valide o que você escreveu e esteja pensando no mesmo que você. Mas é mais fácil ganhar na loteria do que isso acontencer.

Esse problema não acontece com software rodando. Quando o produto está vivo na frente do cliente, não há espaço para interpretações erradas. O sistema faz exatamente aquilo que está fazendo ali, ao vivo, na frente dele. Se algo estiver errado ou puder ser melhorado, o produto é um objeto concreto para servir de instrumento na discussão. Ninguém vai precisar adivinhar o que o outro está pensando.

A chave para o equilíbrio entre previsibilidade e criatividade através de iterações está em achar um tempo de iteração que seja pequeno o suficiente para que as estimativas não fiquem muito distorcidas e grande o suficiente para permitir que alguma coisa de útil seja feita. Tudo isto ainda permitindo que a equipe possa exercitar sua criatividade.

Grande idéia de Bill Seaver, blogueiro do Tennessee. Os quinze minutos de fama são passado. Hoje em dia 15 Mega de fama são muito mais comuns.

Anônimos de toda parte do mundo estão experimentando pequenos momentos de fama através da mídia digital. Quando todo mundo é especial, ninguém é especial.

Em filmes, novelas, livros e em qualquer outro meio que se conte uma estória, há personagens protagonistas e coadjuvantes. Estes últimos desaparecem em meio aos primeiros. Ninguém nota que eles estão lá, mas todos notam algo esquisito se eles não estiverem.

Do mesmo modo, os famigerados “processos de desenvolvimento de software” podem ganhar muito se forem tão naturais que nem se note sua presença. Eles podem funcionar como figurantes de um filme: são essenciais para que tudo corra agradavelmente, mas não prendem a atenção de ninguém. Na verdade, eles estão lá justamente para não chamar a atenção. Quanto mais apropriado o processo estiver para a realidade da equipe, mais as pessoas vão achá-lo natural e mais ele será confundido com o cenário.

Sob esta ótica, uma equipe com o conjunto de práticas ideal vai achar que não há nada além de pessoas trabalhando. Nada de processos ou metodologias.

Então vocês finalmente conseguiram um cliente. Ele está muito empolgado e tem muitas expectativas para o projeto. Naturalmente, vocês também têm. Por onde começar?

Nesse início de projeto é óbvio que todo mundo está cheio de idéias, tanto vocês quanto o cliente. Todo mundo quer colocar todas as idéias em prática, mas há um limite para o que vocês conseguem entregar. A questão do que fazer primeiro é vital.

Uma idéia é levantar alguns requisitos iniciais com o cliente e escolher as funcionalidades mais representativas do ponto de vista técnico. Ainda não é preciso saber tudo que ele vai querer, somente o suficiente para ter uma idéia geral. Desse modo pode-se montar um esqueleto inicial do sistema sobre o qual as funcionalidades futuras se apoiarão.

Esta não é necessariamente uma boa idéia.

Pelo menos não é desse jeito que os esqueletos vêm tradicionalmente sendo desenvolvidos. Os esqueletos humanos, por exemplo, são produto de alguns milhares de anos de mutação e seleção natural. Não ganhamos este esqueleto que temos hoje de uma hora para a outra, foram necessárias várias gerações e muito refinamento do projeto inicial. Assim como na natureza, é melhor que a estrutura básica de uma aplicação evolua a partir de um conjunto mínimo ao longo do tempo ao invés de ser inventado tentando prever o futuro. Programadores não são muito bons em prever o futuro, então é melhor evitar projetar coisas que não precisaremos e deixar os apêndices evolucionários que ocasionalmente surgirão desaparecer naturalmente.

Mas há um argumento ainda mais forte. Quando levantamos prioridades observando apenas o mérito técnico, ignoramos o valor de negócio. Pode ser que as funções com maior representatividade técnica coincidam com as funções de maior valor para o cliente. Mas isto em geral não acontece. O resultado de priorizar inicialmente o desenvolvimento de um esqueleto normalmente são projetos que iniciam com uma grande fase de infra-estrutura e que, durante este tempo, não atendem a nenhuma necessidade do cliente.

O lado oposto desta idéia é deixar o cliente completamente livre para ordenar as funcionalidades como ele queira. Nesta abordagem tudo se inverte. Ao invés da aplicação se adaptar à infra-estrutura inicial, é a infra-estrutura que vai se adaptando às necessidades da aplicação. Os clientes podem então escolher em que investir.

São eles que estão pagando a conta, é natural deixá-los escolher em que investir. Claro que o papel dos programadores, especialistas em desenvolvimento de software, é mantê-los informados sobre suas opções. Eles podem oferecer seu conhecimento — devem fazer isso — mas a decisão final é dos clientes. Escolher uma funcionalidade ao invés de outra com base somente em quesitos técnicos é privá-los desta decisão.

Essa nossa língua portuguesa é extremamente e rica e ainda mais extremamente incompreendida. Dia desses descobri uma ótima discussão em pelo menos dois blogs sobre o termo padrão de projeto, tradução já consagrada de design pattern. Os dois parecem concordar que a tradução tradicional tem atrapalhado a indústria brasileira porque as pessoas entendem “padrão” como “norma”. A palavra é realmente ambígua, mas com certeza não é a raiz da questão. A grande prova é que o problema não acontece somente aqui.

É verdade que é bem fácil encontrar no Brasil organizações que promovam uma “arquitetura” normatizada, independentemente do domínio do problema ou do contexto do projeto. Essas organizações realmente parecem gostar de dizer que têm uma “arquitetura” baseada em padrões de projeto. Aliás, a palavra “arquitetura” devia sempre vir envolvida em aspas, já que tem tantos sentidos para tanta gente diferente.

É verdade que é bem fácil encontrar alguns brasileiros integrando a gangue dos padrões. Você já conheceu pelo menos um destes: eles acabaram de sair da faculdade (ou em muitos casos, ainda estão lá) e acham que os padrões de projeto podem resolver todos os problemas do mundo, da guerra no Líbano ao açúcar do cafezinho.

Também é verdade que os brasileiros abusam do padrão Singleton. Mas todos estes problemas acontecem com a mesma freqüência no resto do mundo.

Desde o dia em que aqueles quatro caras popularmente conhecidos por Gang of Four (ou pelo acrônimo GoF) publicaram o Design Patterns: Elements of Reusable Object-Oriented Software (que aliás, é um ótimo livro: se você não leu ainda, corra para ler), as pessoas têm usado mal o padrão Singleton. Esta famigerada criatura não passa de uma variável global vitaminada e a primeira pessoa que abusou do coitado muito provavelmente não o conheceu por litetatura em português. Afinal, os termos foram cunhados originalmente em inglês.

Acontece que o Singleton é especialmente útil para quem tem a mente acostumada com o pensamento imperativo. Ele permite agrupar um conjunto de funções em algo parecido com um objeto e dizer que se usa programação orientada a objetos. É um dos modos mais fáceis de estar na moda (tanto na moda dos objetos quanto na dos padrões) e foi o que muita gente escolheu.

O problema é que algumas pessoas pegaram a febre dos padrões e começaram a vê-los como normas, quase leis, e entraram numa cruzada insana pelo Santo Graal dos padrões. Só precisamos encontrar a cura e o meu palpite é que ela vai levar uma boa dose do bom e velho senso crítico.