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 funcionarem. 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 para 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.

19 comentários:

Anônimo disse...

Muito bom este artigo, valeu a pena ler vou repassar para a equipe de programadores que trabalham comigo.

Bruno disse...

O unico ponto, é tomar cuidado para não ser mal interpretado, e os novos programadores não entenderem que esse ponto de "não precisar programar", só deve ser atingido, depois de ter passado e muito bem pelos outros dois anteriores.

Dirlei Dionísio disse...

Opa Bruno, valeu pela visita e pelo comentário!

Sobre o ponto que você citou, apesar de a habilidade de não precisar programar ser geralmente alcançada por bons programadores, seria ótimo se os amadores, desde o começo, entendessem que seu próprio código não é a melhor solução para tudo. Espero que a "grande lição" que incluí nesse artigo ajude-os a comprender essa necessidade.

Grande abraço!

Luís Eduardo Jason Santos disse...

Grande Dirlei! Sempre um bom conselho e com uma abordagem muito cuidadosa, parabéns!

Dirlei Dionísio disse...

Tks grande Jason! []'s

Vinicius Santos disse...

Concordo com você Dirlei.

As pessoas somente devem tomar cuidado para não confundir "Não escrever código" com "Receita de Bolo".

As pessoas tem sim que utilizar código de terceiros que estejam mais maduras e sólidas, porém você sempre tem que ENTENDER a solução.

Muita gente simplesmente opta por usar algo que funciona bem, mas caso precise dar manutenção, não consegue, por não entender o código.

Abraços !

Dirlei Dionísio disse...

Muito bem lembrado, Vinicius. É preciso sim entender a solução adotada, seja ela um código ou não. No caso dos frameworks, por exemplo, é comum programadores utilizá-lo sem entender como funcionam e até se realmente são a melhor alternativa para seu trabalho.

Grande abraço!

Lucas Lopes disse...

Parabêns pelo artigo e a forma como foi feita a abordagem. Eu como programador antes de desenvolver uma solução sempre procuro pesquisar bastante por soluções que possam me atender nem que sejam apenas em partes ou em alguns casos, totalmente.

Dirlei Dionísio disse...

Essa pesquisa é sempre positiva, Lucas. Mesmo quando não encontramos uma solução ideal pronta para o uso, avaliar alternativas nos ajuda a entender melhor o problema e projetar uma melhor solucao, qdo necesario.

Obg pela visita e pelo comentário.

Abc!

Anônimo disse...

Dirlei ,

Bom Dia !

Estou me aventurando em desenvolver em linguagem Java , e percebo que a cada novo projeto que inicio , acabo usando varios componentes/classes de projetos anteriores , que acabam por encurtar o tempo de finalização do projeto.

Parabens !!! pelos posts , continuo acompanhamento.

Até mais.

Dirlei Dionísio disse...

Muito bom Rafael, então você já está na segundo estágio. A meta agora deve ser chegar no terceiro, o de "não escrever código".

Obrigado pela visita e pelo comentário.

[]'s

Thiago Leite Luiz disse...

Parabéns pelo artigo Dirlei. Complementando o que o Bruno disse o artigo pode ajudar bons programadores a passar para o nível de grandes programadores, mas pode deixar programadores iniciantes frustrados com a ideia de começar escrevendo muito código para terminar minimizando esforços, mas com o tempo entenderão o que você quis dizer.

Sem contar que a utilização de códigos de terceiros quebra a ideia de que programadores são rivais e não podem trabalhar juntos para construir algo maior ao invés de construir duas aplicações miseráveis para tentar solucionar o mesmo problema.

Dirlei Dionísio disse...

A ideia é essa mesmo, Thiago, fazer mais (em quantidade e qualidade) com menos. Talvez isso não seja exatamente "minimizar esforços", mas empregá-los de forma mais eficaz.

Grande abraço!

Paulo Porto disse...

Muito bom!

Porém gostaria expressar minha opinião e dizer que essa medida é uma faca de dois gumes.

O fato de escolhermos um componente ou framework para utilização pode não ser a melhor solução, apesar de ser em sua grande maioria. Imagine quando você adota a utilização de um componente em um determinado projeto e ao tentar mudar a versão da sua linguagem, aquele componente não é compatível. Sendo que você precisa atualizar a versão da linguagem que foi desenvolvida o projeto, para manter sua aplicação livre de bugs e furos de segurança que continha em sua versão anterior. Isso pode nos gerar um grande problema. Tudo bem, é raro disso acontecer, mas já aconteceu comigo.

Outro caso.

Um componente que eu utilizava era pago e ao utilizá-lo pela primeira vez, dias atrás ele tinha virado free (a empresa detentora abandonou o projeto), então o adotei, pois ele fazia o que eu havia procurado há muito tempo, que era uma coisa de alta complexidade que se eu fosse desenvolver iria precisar de meses e meses, conforme você levantou bem neste post.

Logo saiu uma versão nova da linguagem que eu utilizava, então efetuei a atualização, pois vinha com um recurso que alguns clientes já me cobravam e uma série de correções de bugs e vulnerabilidades. E quando fui instalar o componente nessa nova versão, adivinha, era incompatível. Então fui até o site, super tranquilo achando que a versão nova estava lá, e realmente estava, mas me deparei com uma outra empresa que havia comprado os direitos do componente e agora voltou a ser pago, custando uma grana preta, inclusive. Assim, fiquei preso a versão anterior do sistema. Logo, minha alternativa agora era comprá-lo ou continuar com a versão antiga da linguagem o que custaria ainda mais pra eu entregar o que o cliente sempre desejava e também eu sabia que agora a versão da linguagem que eu usava estava com várias falhas de segurança (o que me deixou paranoico).

Enfim, isso é um dos exemplos que eu passei, mas posso levantar outros possíveis. No seu exemplo, foi muito bacana, pois resolveu o que outra pessoa tinha demorado meses pra fazer. Lhe proporcionou um grande conforto no momento, mas a questão é, o quão isso se torna sustentável!? Vai depender de vários fatores, se a empresa ou equipe desenvolvedora (opensource, por exemplo) mantiver em dia suas versões conforme mudanças das versões da linguagem atrelada, vai ser um sucesso, do contrário, pode se tornar um grande problema.

Por fim, não quero dizer que sou contra, mas que o uso de componente ou framework seja feito com muita cautela. Que fiquemos sempre atentos se a equipe ou empresa que estão envolvidas no desenvolvimento estão realmente comprometidas em manter o componente/framwork sempre atualizado.

Esse é só um detalhe a mais que espero ter agregado em seu interessante post.

Parabéns pelo blog!

Deixo aqui uma máteria polêmica (leiam os comentários também) para que todos possam expressar suas opiniões:
http://www.infoq.com/br/news/2011/09/frameworks-emburrecem

Até mais!

Dirlei Dionísio disse...

Você levantou um bom ponto, Paulo. Há casos em que é importante avaliar soluções de terceiros num horizonte de longo prazo. Dependendo do grau de controle que seja preciso ter sobre determinado recurso e do quanto esse recurso é importante para o negócio, pode ser uma boa ideia desenvolvê-lo "em casa". É verdade que casos como esse não são a maioria, como você mesmo disse, mas é preciso saber identificá-los. Temos que compreender os prós e contras de cada abordagem (escrever código/usar código) e trabalhar com elas dependendo do cenário.

Sobre o artigo que você compartilhou, a discussão é realmente interessante (inclusive, o primeiro comentário é o meu). Há algumas coisas que gostaria de escrever sobre esse assunto e talvez eu as expresse num artigo futuro. Pra adiantar, acredito que há dois perfis de programadores: os criadores e os pilotos de frameworks. Às vezes precisamos do primeiro, às vezes do segundo. Mas isso é assunto para depois.

Muito obrigado pela visita e pelo comentário.

Grande abraço!

Paulo Porto disse...

Dirlei,

Passei recentemente por um caso bem parecido com o que você aborda neste texto. Com isso, me lembrei em passar aqui para escrever meu testemunho.

Como eu havia comentado anteriormente, tem que ter muito cuidado ao utilizar coisas de terceiros, como plugins, componentes, ou seja lá qual for aquilo que você pega pronto que foi feito por outro(s) e passa a utilizar em seus projetos. Porém há casos, que inclusive nosso amigo Dirlei replicou muito bem, que dependendo do grau de controle do que é preciso, um Plugin/addon/componente pode resolver o seu problema numa velocidade incomparável e cair como uma luva, que foi o aconteceu nesse caso que vou mostrar agora.

Entraram em contato comigo solicitando um trabalho de freela pra desenvolver uma galeria de fotos em um site legado, que inclusive estava bem tosco - estrutura de tabela ainda, mas enfim, a exigência principal dessa galeria era que o upload das imagens fossem feitos de forma múltipla, ou seja, a pessoa não queria fazer o upload foto a foto. Foi aí que surgiu uma ideia que foi crucial para a entrega rápida e ainda obter um alto nível de satisfação da pessoa que solicitou.

A ideia foi fazer com que ele fizesse o upload das fotos no Picasa web e na página da galeria do site, apenas renderizasse as fotos carregadas de lá através de sua completíssima API (viva o Google!).

Com isso, a solicitação foi atendida, pois o Picasa web não só permite o upload múltiplo de arquivos, como também a geração automática de thumbnails das imagens, drag and drop e ainda por cima um excelente controle de cache que é feito em seus servidores parrudos, o que garante uma velocidade sem igual no carregamento das fotos.

Para isso, utilizei um plugin jQuery e não precisei programar praticamente nada, exceto algumas adaptações que foi preciso no código do plugin, apenas para efeito de melhor visualização de algumas coisas. No mais, foi só passagem de parâmetro e pronto. O site já se encontra renderizando as imagens obtidas via API do Picasa web e a pessoa que solicitou está satisfeitíssima com a solução.

O que não entendi nessa história toda foi porque que eles não pediram para o desenvolvedor do site que trabalham lá dentro. Bom pra mim, que faturei e entreguei o que me foi pedido em curtíssimo prazo (2 horas de trabalho).

Por fim, fica a dica. Se é algo simples, que não vai ter impacto na estrutura geral do projeto e que não necessite de atualizações constantes, a utilização de plugins/componentes é uma excelente alternativa. Mas volto a falar que é sempre bom analisar bem o grau de controle de uma forma geral, pois nem todo caso essa é a melhor saída. Neste caso foi e viva os plugins e o Google. :)

Até mais!

Dirlei Dionísio disse...

Obrigado por mais esse depoimento, Paulo. Talvez o mais importante a extrair dessas experiências seja: programe menos sempre que possível e programe mais quando necessário.

Unknown disse...

Olá! Acabei de ler seu artigo e achei muito interessante o que você escreveu. Eu estagiei em um lugar onde a filosofia era: Está pronto? Então, não precisamos fazer. Isso é bacana, economiza tempo. Mas, lendo o seu artigo, cheguei a conclusão que a palavra chave para ser um bom programador é: ANALISAR. Se você acha um cogido na internet que te sirva, primeiro, deve-se entender o código e pensar: Se eu fosse fazer, ficaria melhor do que pegar de outra pessoa? Segundo, analisar se o código não irá dar problemas futuros. Em resumo: Tudo tem que ser analisado. Esse papo de está pronto e não preciso fazer, nem sempre é uma boa ideia. Muita das vezes, você pode fazer melhor. Essa é a conclusão que eu tiro do seu texto. Abraços.

Dirlei Dionísio disse...

É isso mesmo Victor. Precisamos saber trabalhar com os dois cenários (usar ou fazer) e analisar quando é hora de atuar com um ou outro. Abraço!