4 de outubro de 2011

Programe menos

Muito se fala sobre a necessidade de treino, muito treino, para alguém se tornar um bom programador. Apóio totalmente essa ideia. Mas, nesse artigo, gostaria de chamar a atenção para uma habilidade que poucos bons programadores chegam a adquirir: a habilidade de não precisar programar. Não, não estou me referindo a "habilidade" que alguns tem de se esquivar do seu trabalho. Estou falando sobre realizar um trabalho de qualidade, mas usando pouco ou nada do seu próprio código.

Quando aprendemos a escrever código

No começo, tudo é uma beleza. Com algum material de estudo e pouco tempo de prática, podemos ver nosso primeiro Hello World! funcionando, seja qual for a linguagem. Nesse ponto, não há a pressão das boas práticas ou da economia de recursos; precisamos apenas descobrir como fazer as coisas funcionar. Qualquer um que passa algum tempo nessa fase aprende a programar, ainda que não possa ser considerado um bom programador.

Quando aprendemos a deletar código

Passada a fase inicial de aprendizado, descobrimos que há algumas boas práticas que nos ajudam a criar programas mais estáveis e fáceis de manter. É a fase em que aprendemos a deletar código. Pegar um código grande e complexo e torná-lo mais simples e eficiente é fonte de grande orgulho e prazer para muitos programadores. Com algum tempo praticando essa "arte", aprendemos quais códigos valem o esforço de refatoração e como executá-la de maneira responsável, sem quebrar a estabilidade do software. Muitas dessas refatorações dão origem a bibliotecas que podem ser reaproveitadas em outros projetos, gerando uma grande substituição de código ruim e duplicado por código mais eficiente e estável. Que maravilha, hein? Só não é melhor porque a maioria dos bons programadores estaciona aqui.

Quando aprendemos a não escrever código

Muitos programadores se tornam tão bons na codificação que acreditam que seu código é a melhor forma de resolver todo tipo de problema. Isso não seria ruim se não fossem pequenos detalhes:

  • Tempo é um recurso caro;
  • Todo código novo é propenso a bugs e leva tempo para que se torne estável e confiável;
  • Existem inúmeras bibliotecas, componentes e frameworks de qualidade que resolvem uma infindável quantidade de problemas;
  • Nem todo problema se resolve com código.

Esses pontos óbvios são frequentemente ignorados por causa de uma cultura existente em muitas empresas e indivíduos: a cultura do Not Invented Here (Não Inventado Aqui).

"Not Invented Here (HIH) é um termo usado para descrever uma cultura social, corporativa ou institucional em que se evita o uso ou compra de produtos, pesquisas, padrões ou conhecimento existentes por causa da sua origem externa." (Wikipedia)

As razões para se preferir escrever seu próprio código podem incluir o medo de não entender as soluções de terceiros ou a indisposição de valorizar o trabalho de outros. Seja qual for o motivo, reinventar a roda raramente é a melhor alternativa.

Há uma história interessante que posso contar sobre isso. Muitos anos atrás, uma empresa onde trabalhei precisava tornar seus aplicativos desktop capazes de serem atualizados automaticamente. Desenvolveu-se então um aplicativo que, integrado aos aplicativos que seriam atualizados, cuidaria da verificação da existência de uma nova versão, do download e da instalação dela. O aplicativo era bem sofisticado para a época, podendo até continuar um download interrompido, se necessário. Seu desenvolvimento ocupou alguns meses de trabalho contínuo de um desenvolvedor e levou mais de um ano até que a primeira versão fosse testada em um cliente real. No primeiro teste real, bam! O cliente usava um proxy de internet com um protocolo de autenticação que não havia sido previsto. O desenvolvedor dessa solução não estava mais na empresa e o problema caiu no meu colo.

Ao pesquisar uma solução pronta que resolvesse essa questão da autenticação, descobri uma biblioteca que não apenas poderia cuidar desse problema específico, mas também poderia substituir praticamente todo o trabalho do aplicativo de atualização! Então, propus "jogar fora" o trabalho realizado até aquele momento e substituí-lo por um novo projeto baseado numa biblioteca de terceiros. Para encurtar a história, em dois dias eu tinha um protótipo funcional da nova solução e, em duas semanas, sua versão funcional. Até onde sei, essa solução, que ocupou uma pequena fração do tempo de desenvolvimento da primeira, usando uma biblioteca de terceiros, atualiza milhares de aplicativos até hoje.

Quanto dessa solução foi resolvida com meu código? Talvez cinco ou dez por cento. O código principal não era meu e não tenho receio algum de admitir isso. Tive sucesso graças ao trabalho de outros desenvolvedores que tornaram sua solução disponível a terceiros. Se essa abordagem tivesse sido utilizada originalmente, teria-se poupado muito tempo e dinheiro.

Qual a lição aprendida aqui? Não defendo que você utilize uma biblioteca, componente ou framework de terceiros para resolver todo tipo de problema. Da mesma forma, não defendo que faça o contrário, usando seu próprio código para resolver todo tipo de problema. A grande lição é:

Aprenda a escrever bom código e faça isso quando necessário; mas aprenda também a escrever pouco ou nenhum código, quando está a sua disposição uma solução adequada, confiável e pronta para o uso.

Pra fechar, segue a tradução do tweet que me serviu de inspiração para escrever esse artigo:

"O código que você escreve te torna um programador. O código que você deleta te torna um bom programador. O código que você não tem que escrever te torna um grande programador". (Mario Fusco)

Que achou desse artigo? Já teve alguma experiência relacionada? Deixe seu comentário.

Créditos pela foto do bicho-preguiça a Guilherme Jófili.

Postar um comentário