Category: Engenharia de software

Categories
Comunidade Engenharia de software Mercado

Programador “Religioso” x “Filósofo”

Há algum tempo atrás enquanto usava o GTalk encontrei uma mensagem sensacional que o Anselmo Alves havia colocado no seu status:

“Philosophy is questions that may never be answered. Religion is answers that may never be questioned.”

(“Filosofia são questões que podem nunca ser respondidas. Religião são respostas que nunca podem ser questionadas.”)

Quando li essa frase imediatamente lembrei do que acontece no dia-a-dia do nosso mercado; do ambiente de trabalho a conferências e listas de discussão. Sem querer entrar em detalhes profundos ou em opiniões/flames sobre assuntos não-técnicos, vejo que existem dois tipos de programadores: os Religiosos e os Filósofos.

A palavra “religião” vem do latim “religio”, que significa “prestar culto a uma divindade”. Os programadores Religiosos fazem exatamente isso: aproveitam todas as oportunidades que podem para louvarem a sua linguagem ou framework favoritos. Os Religiosos dificilmente aceitam “religiões” diferentes da sua e os mais extremistas acreditam que a sua linguagem ou framework resolve todos os problemas do universo e são a chave da salvação da humanidade. Eles aceitam tudo cegamente e nunca reconhecem ou questionam os defeitos desses projetos que apoiam (e em alguns casos mais extremos até transformam esses problemas em “features”). Quando aparece um problema pela frente não precisa nem pensar: ele usará a sua ferramenta favorita para resolvê-lo, não importa o que seja (um padrão também conhecido como “One Ring to rule them all”).

“Filosofia” vem do grego “philos” (que ama) + “sophia” (sabedoria), ou seja, “que ama a sabedoria”. Filosofia é a investigação crítica e racional de questões, ou seja, um programador Filósofo não está procurando defender uma linguagem ou framework mas sim em investigar várias delas, analisar como elas funcionam e refletir sobre como elas podem ajudá-lo a resolver problemas. Os Filósofos são curiosos; eles sempre querem compreender e questionar o funcionamento e utilidade das ferramentas que usam. Quando precisam resolver um problema eles analisam de forma racional todas as opções que conhecem e se nenhuma delas for boa o suficiente eles pesquisam e procuram uma opção mais eficiente.

Um programador precisa resolver problemas complexos com qualidade e precisa ser cada vez mais produtivo/veloz para atingir um objetivo (desenvolver um produto, terminar um projeto da sua empresa e por ai vai). A melhor ferramenta não é a sua preferida ou aquela que você escolheu para seguir e amar, e sim aquela que te faz ser mais rápido, mais produtivo, com mais qualidade e que te dá mais conforto para trabalhar. A melhor ferramenta é a que melhor atende os requisitos da sua profissão e do seu projeto, não o seu ego (ou sua religião).

Seja menos “religioso” e mais “filósofo”! Com a mente aberta e sem encarar ferramentas como “a verdade definitiva” (ou descartando-as sem ao menos testar e conhecer como funcionam) você terá muito mais chances de ser bem-sucedido.

Categories
Engenharia de software Open Source

Colaboração e Open Source dentro da empresa

O Github sem sombra de dúvidas mudou a forma como funciona a colaboração em projetos Open Souce. Já existiam alguns websites de colaboração nesse sentido (e até bem conhecidos) como o SourceForge, Google Code, Savannah e vários outros. Todos eles tem várias qualidades mas o Github na minha opinião foi o que conseguiu ser o mais bem sucedido: eles uniram uma interface bem agradável a uma rede social de programadores e o sistema de controle de versão Git.

Colaborar com outros projetos é bem fácil no Github, basta fazer um fork do projeto que eu pretendo colaborar, fazer minhas modificações e depois um “pull request” para o dono do projeto avaliar e integrar (ou não) o meu código ao dele. Antes do Github não funcionava muito diferente disso mas o que ele fez de bom foi facilitar esse fluxo e criar uma rede social bem interessante em torno desse mundo.

Isso é bem diferente de como as empresas normalmente funcionam. No caso da Globo.com, por exemplo, todos os repositórios sempre estiveram amontoados nos servidores CVS e Subversion e consequentemente “escondidos” (pouco visíveis) de possíveis colaboradores. Alguns até tinham permissão de commit restrita para um pequeno grupo e o processo de colaboração era ainda mais difícil. Não dá nem para abrir um branch seu, você tem que fazer as modificações localmente e mandar um patch por e-mail, e o merge geralmente não é muito fácil de fazer quando você tem um grande fluxos de merge para lá e para cá. Imagina então quando você trabalha na versão “v1” do código e enquanto você produz a “v2” um outro desenvolvedor pede merge antes de você? Era preciso esperar o merge terminar para dar checkout da versão nova e ficar mais uma vez fazendo o inferno do merge.

No início desse ano resolvemos experimentar usar o Gitorious, que é uma ferramenta similar ao Github porém Open Source e que você pode instalar num servidor da sua empresa. Isso tinha 2 objetivos: (1) criar uma cultura de “enterprise” Open Source e (2) facilitar a colaboração em projetos em que vários times trabalham e commitam ao mesmo tempo.

No início foi um inferno e houve uma rejeição muito grande de muita gente. O modelo de trabalho com o Git é bem diferente do que com CVS e Subversion. Você tem branches (e clones – que é um conceito um pouco diferente) que podem ser locais ou remotos, commits locais que não vão direto para o servidor e pulls/pushes. As pessoas tendem a fazer relações do tipo “o push é o que manda as coisas para o servidor, então ele equivale ao commit”. Mas então o que é o commit do Git? Enfim, não dá pra trabalhar pensando assim, é preciso dar um reset e entender a arquitetura desses sistemas de controle de versão distribuídos para entender que faz sentido sim ter um commit e só depois do push que o código está no repositório (no remoto, porque no local já estava). 🙂

Também foi difícil aprender a trabalhar com merges. No modelo antigo você evita fazer merges o máximo possível porque o trabalho para fazer isso é enorme. Geralmente você só faz quando acabou de fazer tudo para ter trabalho uma vez só. Ainda bem que existem ferramentas para ajudar (como as ferramentas das próprias IDEs) senão seria complicado. Se você trabalha da mesma forma com o Git geralmente vai se dar mal, porque não existem (não existiam mas estão começando a melhorar) as mesmas ferramentas de merge visual do CVS ou Subversion, e era um parto para fazer a coisa toda funcionar após fazer um merge de uma semana de fork. Com o Git funciona ao contrário: como o merge é automático (na maioria dos casos ele consegue se virar) então a estratégia é fazer merge toda hora, várias vezes por dia, o máximo que der.

Depois de alguns meses de “fricção” hoje já dá para ver um monte de frutos começando a aparecer. Por exemplo, no último sprint do meu time nós precisavamos usar um cliente Python para acessar a engine de busca da Globo.com. Como esse cliente era novo tinha uma série de problemas pequenos que precisavam ser resolvidos, mas o time que é responsável pelo projeto estava com vários compromissos e demoraria 2 semanas para trabalhar nisso. Então o Bernardo e o Andrews decidiram fazer um clone no Gitorious para contribuir com o projeto do time de busca, e eles não só resolveram os problemas como devolveram o código refatorado e com a cobertura de testes bem melhor. O outro time rapidamente integrou o novo código ao projeto e gostou tanto do trabalho deles que eles viraram commiters e agora podem fazer as modificações que forem necessárias em colaboração com o time de busca. Exatamente como funciona no mundo Open Source.

Além desse exemplo, no projeto que estou trabalhando (que é um framework para sites de publicação de conteúdo) temos vários times trabalhando no mesmo código ao mesmo tempo. Nesse momento tem cerca de 10 clones do projeto no nosso Gitorious e talvez cerca de 10 times trabalhando usando o mesmo código para fazer seus “add-ons”. O Git facilita o trabalho dos times para atualizarem constantemente sua base de código com o que entra de novo no branch master do mainline (o repositório principal do projeto) e o Gitorious torna isso tudo mais visível para todos.

Enfim, as vantages que nós passamos a ter com o Git e Gitorious são várias:

  • Todo mundo pode ver facilmente os projetos que existem e quando novos projetos são criados;
  • Todo mundo pode ver o que todo mundo está fazendo e em que estão trabalhando;
  • Todo mundo pode facilmente criar e gerenciar seus projetos (sem precisar do Sys Admin);
  • É bem facil de navegar nos projetos, ver e pegar código dos outros;
  • Todo mundo pode criar seus clones de repositórios para trabalhar em cima do seu código e do código dos outros;
  • Todo mundo pode colaborar de volta sem precisar de um processo complicado para isso;
  • É mais fácil de fazer merges constantes e gerenciar múltiplas colaboracoes simultâneas;
  • Fora as outras features interessantes que o Git tem e os sistemas de SCM antigos não como o stash, clones, merge automático e por aí vai.

Só para dizer um ponto negativo, a documentação de usuários do Git não é das melhores (mas tem melhorado bastante) e alguns comandos não são tão intuitivos (como deletar um branch remoto), mas nada que você não descubra e que não se acostume com o tempo.

Aconselho fortemente a todo mundo que puder que faça isso. Instale o Gitorious e fomente a colaboração entre os desenvolvedores da sua empresa! Se você estiver com muita grana também pode dar uma olhada no Github Firewall Install, que deve ser bem legal mas também é bem caro.

Categories
Engenharia de software

“50 in 50”, por Richard P. Gabriel e Guy L. Steele

Quem gosta de apresentações épicas vai gostar desse vídeo. Assisti essa apresentação ao vivo na QCon 2007 e foi incrível, certamente uma das mais interessantes que eu já vi! Ontem comentei isso com o Henrique que acabou achando esse video que eu sempre procurei loucamente!

Apresentada por Richard P. Gabriel e Guy L. Steele, a palestra 50 in 50 fala de 50 tópicos sobre linguagens de programação e 50 anos de história de computação em 50 minutos. Tem pérolas musicais como a sensacional “Eternal Flame” (também conhecida como “God had a deadline, so he wrote it all in Lisp”), representações teatrais de um programa escrito usando Shakespeare Programming Language e muito mais! É imperdível!

Para ver com qualidade melhor, acesse o video no Blip.tv da JAOO.

Categories
Engenharia de software

[Rails Conf] Conselhos do Uncle Bob

Excelente! 🙂

Uncle Bob Martin na RailsConf 2009 from Fabio Akita on Vimeo.

Categories
Engenharia de software Webservices

Arquitetura “pull” ou “push”: qual escala mais?

Apesar do que possa parecer, esse post não é sobre git. 🙂

Conversando com o Peleteiro esses dias ele me deu uma idéia interessante. Ia ser o máximo se houvesse um post automático no meu Twitter toda vez que eu ganhasse um achievement no Xbox! Os achievements são como se fossem medalhas: na medida que você vai jogando os jogos e passando de fase ou conquistando coisas, você vai ganhando mais pontos e mais medalhas. Resumindo, é totalmente inútil mas bem legal.

Como nos últimos tempos andei fazendo uma porção de robôs de Twitter para fazer uma porção de coisas, na mesma hora pensei em fazer mais um deles, que ficaria dando requests na API do Xbox Live até que aparecesse um novo achievement e então ele faria o post.

Na mesma hora me bateu a mesma sensação de ineficiência que tive quando fiz os outros robôs. Pra fazer essas coisas eu tenho que ficar fazendo polling no serviço de “n” em “n” minutos para saber das atualizações… Apesar de ser eficiente nao é lá muito eficaz.

Vou fazer uma brincadeira para mostrar o tamanho do problema. Somando só os robôs que fiz para a Globo.com, eu faço diariamente cerca de 72.000 requests para o Twitter (cerca de 25 robôs x 2 requests por minuto x 60 minutos x 24 horas). Ok, nem todo mundo faz robôs de Twitter, eu sei, mas vamos supor que uma pessoa em cada 100.000 faz robôs que nem eu. Isso significaria que só eu e mais uma pessoa fazemos isso no Brasil inteiro (o que não deve ser verdade, mas vamos continuar assim fazendo a conta por baixo). Então considerando que a população mundial é de quase 7 bilhões de pessoas, temos cerca de 70.000 pessoas fazendo o mesmo em todo o mundo. Sendo assim, pela minha conta de padaria o Twitter recebe algo em torno de 5,04 bilhões de requisições por dia, 210 milhões de requisições por hora, quase 60.000 requisições por segundo (só de robôs)!!!

Ok, o número deve ser bem diferente disso. O fato é que com certeza é muito alto.

Eu faço polling no Twitter para buscar por usuários que falaram uma determinada palavra (usando o RSS da busca do Twitter) e então adicioná-los. Funciona assim: quando uma pessoa escreve alguma coisa que eu estou procurando, eu adiciono ela como amigo(a). Apesar dessa quantidade imensa de buscas e requests, um robô adiciona apenas na faixa de 25 usuários por dia. Se houvesse alguma forma de saber que algum usuário escreveu alguma palavra que eu busco, nesse meu cenário só seria necessário fazer algo em torno de 625 requests por dia (menos de 1% da quantidade que eu faço).

O que eu estou propondo aqui não é nada novo. Além dos mecanismos tradicionais de polling (fazer “pull” de arquivos de tempos em tempos), estes tipos de serviços deveriam disponibilizar um mecanismo para o servidor avisar o cliente que alguma informação que ele deseja está disponível (“push”).

Depois da apresentação “Beyond REST? Building data services with XMPP” que rolou na OSCON 2008, o XMPP entrou na moda como uma possível solução para esse problema. Nessa arquitetura, os clientes se “inscrevem” em um serviço de mensagens instantâneas e mantém uma conexão aberta com o servidor para que, quando determinada informação estiver disponível, ela seja enviada ao cliente ao invés dele ter que ficar fazendo “polling”. Isso reduz consideravelmente a carga de requests recebida pela aplicação, mas é mais difícil de escalar para uma quantidade muito grande de usuários.

Uma solução que surgiu na nossa conversa foi um “pingback ao contrário”. Seria algo como o webhook do Github. Quando o usuário fizer um GET em um recurso, ele poderia mandar um header com uma URL, e quando houvesse alguma atualização do recurso o servidor poderia fazer um GET para esta URL com o objetivo de informar ao cliente que há informações novas disponíveis. Essa solução escala mais do que a primeira, mas tem um lado negativo: não funciona se o cliente não tiver um IP real disponível. No meu caso, por exemplo, que tenho robôs rodando no meu desktop da Globo.com (que não tem IP real), não seria possível usar esse tipo de serviço.

Também dá pra fazer algumas soluções mais criativas usando coisas que a princípio parecem esquisitas mas podem fazer sentido. Por exemplo, um servidor de e-mail como o Postfix poderia fazer esse trabalho com o pé nas costas. Quando o cliente acessasse um recurso, ele poderia informar em um header um e-mail para ser notificado quando houvesse atualização. É uma solução bem fácil de escalar e de fácil implementação – tanto pelo lado do cliente quanto do servidor – apesar de não ser muito comum.

Pelo que eu andei lendo o pessoal do Twitter já pensou nesse problema e para resolvê-lo criaram o Firehose, que é uma solução baseada em XMPP. Como eu falei, o problema não termina por aí – eles terão vários problemas novos para escalar XMPP para uma grande quantidade de usuários.

Enfim, esse problema é bem interessante… Na próxima oportunidade que tiver vou tentar fazer uma prova de conceito de todas essas opções para ver no que dá.

E para aqueles que ainda não entenderam, talvez fique um pouco mais claro agora: escalabilidade é muito mais uma questão de arquitetura de software e infra-estrutura do que de linguagens e frameworks.

Categories
Engenharia de software

Java é ruim?

Em tempos de Ruby on Rails parece que está na moda falar mal de Java. Na Rails Summit então meus ouvidos chegaram a doer de tanto ouvir falar que Java é ruim, Java é burocrático, bla bla bla e que Ruby on Rails é fantástico, produtivo e sexy. Calma, essa não é mais uma daquelas comparações ridículas de Java versus Ruby on Rails.

Mas ainda ficou a pergunta que não quer calar: Java é ruim mesmo? A resposta, como sempre, é que depende do caso…

Em um projeto de desenvolvimento de software, mesmo antes de começar o desenvolvimento você já tem algumas restrições para escolher tecnologias. A finalidade do software por si só pode já restrigir muito a tecnologia que terá que ser usada.

Por exemplo, se você estiver fazendo um website, provavelmente você não escapará de fazer uma interface em HTML, Flash ou qualquer outra coisa específica para desenvolver uma camada de apresentação web. Provavelmente você não vai querer usar Assembly para fazer a parte server-side, já que não seria muito produtivo (apesar de não ser impossível). Eventualmente esse site pode ser um portal como a Globo.com que têm milhões de acessos por dia e você terá que escolher uma plataforma/linguagem/arquitetura que priorizem performance e favoreçam escalabilidade. Ou então pode ser um site com pouquíssimos acessos e você nem precisará se preocupar com isso…

Ou então você pode precisar fazer um pequeno script para fazer backup automatizado de um banco de dados MySQL. Seria totalmente incoerente usar Delphi, Fortran ou Piet. Provavelmente você vai querer usar algo como Shell script e resolver o problema em meia dúzia de linhas. Alguns bancos como o SQL Server têm mecanismos de agendamento de backup automático que são super fáceis de configurar e usar, portanto nesse caso usar Shell script seria trabalho desnecessário.

Meu ponto aqui é que não dá para dizer que Java (ou qualquer outra coisa) é ruim por sí só. Java pode ser ruim ou bom dentro de um contexto. Por exemplo, em 2005 eu trabalhei num projeto de Call Center à distância via Internet onde precisei desenvolver um softphone e a melhor opção foi usar Java Applets. Além de existirem bibliotecas Java para trabalhar com IAX (que é um protocolo como o SIP, só que proprietário do Asterisk), o usuário não precisava instalar nenhum programa para falar com o Call Center, bastava acessar o site. Eu odeio Applets com todas as minhas forças, mas foi ótimo para esse projeto (eu diria até que foi relativamente fácil). Seria correto então dizer que Ruby on Rails é ruim só porque seria impossível de fazer esse projeto com tanta facilidade? É óbvio que não!!!

Jamais existirá uma única linguagem ou plataforma para resolver todos os problemas. O desenvolvedor de software precisa conhecer vários tipos de ferramenta e saber escolher a melhor delas para resolver cada problema. Que fique claro que eu não sou defensor de Java, Ruby ou de qualquer outra coisa. O caso é que é incoerente dizer que X ou Y é bom ou ruim por sí só; é preciso analisar as opções dentro de um contexto.

Categories
Engenharia de software

Simplicidade

Há mais ou menos um mês terminei de ler o livro Presentation Zen do Garr Reynolds. O livro é muito legal e tem excelentes dicas sobre como fazer apresentações baseadas nos princípios Zen. O Garr trabalhou durante muito tempo na Apple fazendo design de apresentações e é fato que a Apple arrebenta nesse quesito. Depois de assistir apresentações que foram verdadeiros shows na Apple WWDC decidí ler o livro e tentar aprender alguma coisa sobre o que eles fazem.

Quando eu estava lendo o livro, um trecho de um capítulo que fala sobre os princípios de design acendeu uma lâmpada na minha cabeça e me fez atentar para uma coisa que acontece diariamente no desenvolvimento de software:

“Design can make things easier for the viewer or the user. Design is not decoration. If anything, design is more about subtraction than addition. Visually, we do not want to include too much, nor do we want to exclude too much. Generally, people err on the side of including too much visual information, which often results in clutter and confusion.“

É verdade. Existe uma tendência grande das pessoas acharem que mais funcionalidades e complexidade é sempre melhor. As pessoas pensam exatamente como descreve o livro Getting Real da 37 Signals:

“Conventional wisdom says that to beat your competitors you need to one-up them. If they have four features, you need five (or 15, or 25). If they’re spending x, you need to spend xx. If they have 20, you need 30.

This sort of one-upping Cold War mentality is a dead-end. It’s an expensive, defensive, and paranoid way of building products. Defensive, paranoid companies can’t think ahead, they can only think behind. They don’t lead, they follow.“

Transportando para o mundo do desenvolvimento de software, eu vejo que muitos desenvolvedores adoram entulhar seus códigos com todos os design patterns que já ouviram falar, adoram usar EJBs em qualquer coisa, adoram inventar seus frameworks malucos… Enfim, adoram fazer tudo que é complexo e trabalhoso. Assim como no design, entulhar o código com essas coisas só fazem ele ficar muito mais difícil de ser mantido e entendido!

Talvez um dos motivos disso acontecer seja que nem sempre o desenvolvedor tem senso de urgência e visão do negócio. Nem sempre ele entende que não dá para perder 3 dias fazendo um menu JavaScript que abre e fecha, ou passar 80% do tempo tentando encaixar design patterns no código, ou criar uma arquitetura com 36 camadas para diminuir o acoplamento. Essas coisas podem ser extremamente prejudiciais para o projeto, porque o cliente está esperando triplicar o faturamento e o número de visitantes do seu site e essas coisas não vão ajudar em absolutamente nada. A oportunidade de usar design patterns, criar camadas no software ou qualquer outra coisa surgirá naturalmente no decorrer do projeto. Se isso não acontecer, então simplesmente não os use.

Uma dica para descobrir se você ou alguém está fazendo uma coisa útil ou não é tentar responder a seguinte pergunta: “Qual problema será resolvido com isso?”. Ultimamente tenho feito essa pergunta para todo mundo e percebí que muito mais da metade das coisas não são justificáveis. É incrível como as pessoas criam coisas sem nenhum motivo, que só deixam o software mais complexo sem necessidade, tanto internamente (código) quanto externamente (interface).

Por isso eu gosto e recomendo trabalhar sempre com uma das regras básicas do XP. Independente de usar XP ou não, a simplicidade é uma ótima regra:

“A simple design always takes less time to finish than a complex one. So always do the simplest thing that could possibly work. If you find something that is complex replace it with something simple. It’s always faster and cheaper to replace complex code now, before you waste a lot more time on it. Keep things as simple as possible as long as possible by never adding functionality before it is scheduled. Beware though, keeping a design simple is hard work.”

Se você é desenvolvedor e adora complicar tudo, pare de brincar de professor pardal e pense simples, ou é isso que vai acontecer com a sua empresa:

Categories
Engenharia de software

Cuidando para que o software não apodreça

Infeliz o sujeito que teve a idéia de comparar desenvolvimento de software a construção de prédios. Até hoje, em pleno século 21, algumas pessoas ainda acreditam que para fazer software você deve fazer exatamente como na construção civil: você deve ter “engenheiros” que fazem um grande projeto especificando exatamente como tudo vai ser, depois os pedreiros constroem e no final está tudo pronto e funcionando conforme a especificação.

Desenvolvimento de software não tem absolutamente nada a ver com construção!

No livro The Pragmatic Programmer, Dave Thomas e Andy Hunt fazem uma analogia muito mais apropriada: fazer software não é como constriur prédios mas sim como jardinagem. É muito mais “orgânico” do que “concreto”. Inicialmente você planeja muitas coisas para o seu jardim de acordo com as condições atuais de terra, clima, etc. Você precisa plantar as sementes, regar todo dia e cuidar para que as pragas não acabem com tudo. Você pode com o passar do tempo mover suas plantas de lugar para tirar vantagem de fatores como exposição ao sol, sombra ou até mesmo para fazer a rotatividade da terra. Você poda suas plantas constantemente e move alguns tipos de flores de um lugar para o outro para que o jardim fique melhor esteticamente. Se alguma planta cresce demais, pode ser que o espaço que você planejou para ela tenha ficado pequeno, e então é necessário movê-la de lugar. Enfim, não é uma coisa que você planeja, mas sim uma coisa que você tem uma idéia inicial e trabalha ao longo do tempo para fazer o melhor possível dentro daquela idéia.

Assim como o jardim, se o software não receber todos os cuidados necessários ele apodrece. Quando um software apodrece, é impossível implementar qualquer funcionalidade num tempo aceitável, é impossível colocar em produção sem que alguém tenha que ficar de babá, enfim, tudo passa a ser imprevisível. Nos piores casos passa a ser até impossível “tocar” no software, e esses monstros viram aqueles softwares que “se o servidor desligar ele não liga nunca mais”. E o pior é que isso acontece toda hora. Quantas vezes você já não pegou um projeto tão ruim, mas tão ruim que seria mais fácil fazer do zero do que consertá-lo? Isso é um sinal claro de software podre.

Para evitar que isso aconteça, o que se deve fazer é reavaliar a situação do software a cada história/funcionalidade implementada. Um bom desenvolvedor sempre avaliará se não é hora de mover algumas coisas de lugar, generalizar algumas funcionalidades, reescrever algumas porções de código e etc. – assim como faria um bom jardineiro. Isso deveria ser uma lei, não uma opção.

Os times ágeis trabalham com um conceito que é a “definição de pronto” (DOD – definition of done). A definição de pronto diz quando é que uma funcionalidade pode ser considerada pronta ou finalizada. Na minha opinião, para se considerar uma funcionalidade “pronta” é necessário no mínimo:

  • Desenvolver a funcionalidade
  • Testar unitariamente (melhor ainda se for fazendo TDD)
  • Testar a integração com outros componentes (quando for o caso)
  • Verificar se o build do projeto funciona sem erros e fazer o deploy em uma ambiente de produção simulado
  • Testar segundo os critérios de aceitação estabelecidos pelo cliente
  • Depois dos testes desenvolvidos e a nova funcionalidade passando em todos eles, avaliar a necessidade de fazer refactoring no novo código
  • Com a entrada da nova funcionalidade, avaliar a necessidade de fazer refactoring em algum módulo do sistema
  • Atualizar a documentação (quando necessário)

Pode parecer um exagero ou muito trabalho, mas não é. A questão é que você não pode deixar para fazer nenhum desses itens depois de 2 meses de desenvolvimento, você precisa fazer isso desde o primeiro dia! Quando você deixa para depois, você acaba acumulando o famoso débito técnico, e depois poderá ter que pagá-lo com juros, que poderão ser muito altos. O melhor é fazer aos poucos, a cada passo dado, porque desta forma o trabalho sempre será muito menor e não irá onerar o projeto. Mais uma vez fazendo analogias, é como câncer: você pode se previnir e tentar evitar que ele aconteça, ou você pode esperar ficar doente para depois ter que fazer uma arriscada cirurgia invasiva (e mesmo assim pode não dar certo, e aí perde-se o paciente).

Categories
Engenharia de software Testes

Programadores de Schrödinger

Donald Knuth deu uma entrevista para o InformIt esses dias que deu o que falar!

Como o Paulo Silveira comentou no GUJ, Knuth tem algumas opiniões controversas e polêmicas sobre testes unitários, eXtreme Programming, Open Source e programação concorrente. O Phillip Calçado também comentou o assunto, referindo-se a opinião do Keith Braithwaite, que tem ótimos pontos.

Sobre testes unitários em particular, Knuth fala o seguinte:

[…] the idea of immediate compilation and “unit tests” appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be “mocked up.”

Basicamente ele parece não acreditar em testes unitários.

O problema é que hoje em dia, além da complexidade da programação em sí, é necessário lidar com a complexidade do domínio do software, com o fato de que as empresas devem responder rapidamente às mudanças (e o software deve acompanhar), o fato de que não existem “desenvolvedores solo” mas sim equipes de desenvolvimento e por aí vai. Por isso é essencial que os softwares sejam bem testados e que esses testes sejam executados constantemente para garantir o bom funcionamento do sistema ao longo dos incrementos que serão feitos durante seu ciclo de vida. Mesmo com todas essas precauções, como bem disse o Phillip, se nos dias de hoje alguém ou alguma empresa pagasse $2.56 por cada bug encontrado nos seus programas (como faz o Knuth), provavelmente já estaria falida. Já imaginou então se não houvessem os testes como que seria?

Convenhamos, o caso do Knuth é um caso a parte. Ele está na ativa desde os anos 60 quando nossos pais ainda eram adolescentes, e possivelmente por isso tem práticas e opiniões que não necessariamente se aplicam às situações de hoje. É claro que ele merece todo o respeito por tudo que ele fez e faz pela computação, mas não acho que a opinião dele sobre práticas ágeis em especial possa ser levada em consideração ao pé da letra. E o que mais me preocupa nisso tudo é que, por ele ser um ícone da computação, as pessoas tomem tudo que ele falou como verdade absoluta e comecem a achar que testes unitários não servem para nada, quando na verdade eles são essenciais para qualquer programador profissional!

Para mim, os programadores que não testam poderiam ser chamados de Programadores de Schrödinger.

Falo isso por causa da teoria do Gato de Shrödinger. Resumindo a história, o físico Erwin Schrödinger uma vez sugeriu que se puséssemos um gato numa caixa fechada, onde a vida do gato dependesse do estado de uma partícula sub-atômica, haveria uma superposição de estados que faria com que, do ponto de vista da mecânica quântica, o gato estivesse vivo e morto ao mesmo tempo até que a caixa fosse aberta. Seria impossível determinar o seu estado até abrir a caixa! Na minha imaginação eu fico pensando no momento que a caixa é aberta e aparece um gato vivo (ou morto) o que aconteceu com o outro gato… Provavelmente ele está em algum outro universo paralelo onde todas as coisas são ao contrário (e as pessoas acham guarda-chuvas ao invés de perdê-los). Enfim, não se sabe de forma alguma o que pode acontecer.

Finalizando toda essa viagem, os Programadores de Schrödinger simplesmente não sabem o que vai acontecer quando o seu sistema entrar em produção. Pode ser que nenhum bug apareça e que eles fiquem ricos e comprem milhares de jatos particulares. Ou não.

Na dúvida, eu escrevo testes. 🙂

Categories
Agile Engenharia de software Refactoring Testes

Test infection: por onde começar?

Fala GC!

Cara, o que voce faria se entrasse em um projeto para implementar umas melhorias, mas esse projeto não tivesse nenhum tipo de teste, o código não fosse testável e você soubesse que daqui a 3 meses ia sair do projeto? Você perderia tempo fazendo refactoring, implementando testes, configurando CruiseControl e tal, ou ia simplesmente ligar o foda-se???

Isso acontece pelo menos 32409 vezes todos os dias em algum lugar do planeta.

Os desenvolvedores acostumados a programar com testes têm uma dificuldade enorme de trabalhar em aplicações que não tem testes. A primeira coisa que os desenvolvedores mais experientes fazem quando pegam uma aplicação nova é olhar a base de testes. Por alí já é possível descobrir uma série de comportamentos e detalhes da implementação do sistema, bem como as intenções de quem o programou. Mas o que você faz quando cai de pára-quedas num projeto que não tem um mísero teste sequer? Você não pode deixar esse problema para outra pessoa? É você o infeliz que tem que resolver o problema e fazer a faxina?

Minha resposta para essa pergunta é bem simples: SIM, você é o infeliz que tem que resolver o problema.

<história>
Uma vez eu trabalhava numa empresa e meu chefe me pediu para fazer um protótipo de um sistema que integrava um website com um PABX para fazer determinadas tarefas. Como era um protótipo e eu só tinha duas semanas, eu fiz ZERO testes (e a aplicação funcionava por milagre divino). Só que para o meu azar, esse protótipo era para fazer uma demonstração para um cliente, que adorou a idéia e comprou na mesma hora! Como meu chefe achava que já estava parcialmente pronto e funcionando, meu prazo para terminar era de mais quatro semanas. Duas semanas depois eu estava desesperado por não conseguir avançar na aplicação e não conseguir fazer o negócio funcionar. Aconteciam bugs estranhos, daqueles que te fazem pensar que você está na profissão errada. Todos os dias eu me arrependia profundamente de ter deixado os testes para trás. Meu chefe ficou desesperado e colocou mais um desenvolvedor para me ajudar. No primeiro dia ele me perguntou: “GC, onde estão os testes para eu dar uma olhada?”. Er.. bom… não tinham testes… E eu fiquei totalmente desmoralizado, fui humilhado, massacrado e apanhei quase até a morte.
</história>

Hoje em dia não abro mão dos testes. Se você entregar uma aplicação que não funciona, a culpa é sua! Então, faça tudo que é possível para garantir que tudo esteja funcionando.

Finalmente, respondendo o e-mail do meu amigo acima (que não posso dizer o nome porque não tenho permissão), eis algumas dicas para você não ficar em maus lençóis:

Dica número 1: faça sempre o melhor que puder! Mesmo que você ache que vai ficar 2 semanas ou 3 meses em um projeto, seu gerente pode mudar de idéia e você pode acabar ficando bem mais tempo do que isso. Então, tire essa idéia da cabeça já e comece a se preocupar com os testes. E mesmo que você com certeza absoluta só fique 3 meses, como que você vai sair de cabeça erguida e com a certeza de que o que você fez está funcionando se você não tem os testes para comprovar?

Dica número 2: conserte as janelas quebradas. Se alguém chega na sua casa e metade das janelas estão quebradas, então não tem muito problema se quebrar mais uma. Porém, se todas as janelas estiverem impecáveis, quebrar uma janela é péssimo! Siga este mesmo princípio para o seu código, não tenha janelas quebradas. Se você tiver 90% de cobertura de testes, todos eles forem impecáveis e nenhum falhar no CruiseControl, o próximo desenvolvedor que chegar se sentirá na obrigação de manter tudo funcionando da mesma forma, porque esta é a cultura do projeto. Já se todos os testes estiverem quebrados ou não houverem testes, não faz a menor diferença.

Dica número 3: não abraçe o mundo com as pernas! Não precisa refatorar a aplicação inteira de uma vez, até porque você corre um grande risco de tudo parar de funcionar e você ser demitido, além de que não vai conseguir implementar as features. Neste caso, minha estratégia seria refatorar o código na medida que precisasse implementar as features. Faria o ciclo normal de TDD: implementaria os testes fazendo refactor na implementação para torná-la testável, implementaria a feature, garantiria seu funcionamento e depois um novo refactor para deixar tudo bonito.

Dica número 4: get them Test Infected! Faça um workshop com os outros desenvolvedores do time e mostre para eles a importância de escrever testes. Ensine-os a usar o CruiseControl, JUnit, JMock, injeção de dependência e tudo mais que for necessário para que os testes aconteçam. Mesmo que você “perca” dois ou três dias de trabalho, com certeza ganhará muito mais desse dia em diante.

<piada>
Dica número 5: só por via das dúvidas, para ajudar nos momentos de fraqueza, coloque alguém para te vigiar em tempo integral. O “Dijkstra is watching” é ótimo para isso, tenha ele sempre por perto.
</piada>