Posts Tagged ‘Testes’

Mais 10 livros recomendados para desenvolvedores

Monday, March 3rd, 2014

Lá atrás em 2008 escrevi um post sobre 10 livros recomendados para desenvolvedores. Na época o post foi bastante popular e eu sempre pensei em escrever uma continuação, que acabei nunca fazendo.

Enfim, a hora chegou e aqui vai mais uma lista de outros 10 livros recomendados para desenvolvedores! Mas antes disso, alguns detalhes sobre como cheguei nessa lista:

Por que apenas 10 livros e não 20 ou 30? Não sei dizer – o primeiro post foi assim então vou continuar. :) O bom é que isso me deixa uma quantidade de livros mais do que suficiente para no futuro escrever vários posts!

Por que essa lista tem livros sobre “processos” como Kanban ou Lean? Não era para ser livros para desenvolvedores? Não tenho pretensão de escrever aqui uma lista definitiva e restrita a apenas um tópico, mas sim listar alguns livros que pessoalmente acho importantes para desenvolvedores de software e que me marcaram de alguma forma. Nosso trabalho não é só programar direito mas também saber se organizar (ou organizar um time) para que se entregue mais software, com mais qualidade e em tempo recorde, portanto acho esses tópicos super importantes.

Por que um livro sobre JavaScript e nenhum sobre Ruby, Python, Java ou qualquer outra? Tem alguma preferência de linguagens rolando aí? Não tem preferência não. O “Good Parts” é sensacional porquê me fez entender e respeitar JavaScript de um jeito completamente diferente. Não acredita? Leia o livro então! Acha que é perda de tempo? Eu acho que não, JavaScript hoje em dia é uma das linguagens mais populares e é indispensável conhecê-la bem para fazer desde um simples website como este blog até gigantes como Yahoo e Facebook.

Por que todos os livros são em inglês? 99% de toda a literatura relevante de tecnologia é em inglês e em muitos casos não há tradução disponível, portanto se você ainda não está craque, pule esta lista e vá urgentemente aprender inglês antes de mais nada! De todas as linguagens (de programação ou não) que você pode pensar em aprender, essa é provavelmente a mais importante.

Clean Code: A Handbook of Agile Software Craftsmanship Clean Code: A Handbook of Agile Software Craftsmanship
Robert C. Martin
Test Driven Development: By Example Test Driven Development: By Example
Kent Beck
Growing Object-Oriented Software, Guided by Tests Growing Object-Oriented Software, Guided by Tests
Steve Freeman e Nat Pryce
Code Complete: A Practical Handbook of Software Construction Code Complete: A Practical Handbook of Software Construction
Steve McConnell
Working Effectively with Legacy Code Working Effectively with Legacy Code
Michael Feathers
JavaScript: The Good Parts JavaScript: The Good Parts
Douglas Crockford
Kanban: Successful Evolutionary Change for Your Technology Business Kanban: Successful Evolutionary Change for Your Technology Business
David J. Anderson
Lean Software Development: An Agile Toolkit Lean Software Development: An Agile Toolkit
Mary Poppendieck e Tom Poppendieck
The Lean Startup: How Today The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
Eric Ries
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
Jez Humble e David Farley

Estamos contratando no Yahoo! Brasil

Thursday, November 18th, 2010

Estamos contratando desenvolvedores para o Yahoo! Brasil!

Nosso time é responsável pelo desenvolvimento e manutenção do Yahoo! Meme. Para trabalhar conosco é imprescindível ser faixa preta em Python, PHP ou JavaScript e conhecer pelo menos uma segunda outra dessas três. Mesmo sendo essas as principais linguagens que usamos por aqui, precisamos de desenvolvedores multidisciplinares que saibam usar diferentes tipos de ferramentas – porque nunca sabemos quais produtos virão no futuro e que tipos de vantagens poderemos ter usando ferramentas diferentes.

Tão ou mais importante do que isso é ter ótimos conhecimentos sobre desenvolvimento ágil (especialmente XP), conhecer ferramentas de testes unitários, ser capaz de trabalhar com TDD, entender sobre CI e a sua importância, automatização de rotinas/build/etc., melhores práticas de desenvolvimento de software, Orientação à Objetos, Domain-Driven Design e tudo mais que puder ser relevante para ajudar a construir software confiável e manutenível de forma rápida e com ritmo/qualidade sustentável. Experiência com automatização de testes com Selenium ou Webdriver também é essencial. Como trabalhamos com web, também é necessário ter conhecimento em HTML, CSS e desenvolvimento de aplicações cross-browser.

Como desenvolvemos produtos de escala mundial, é necessário ter experiência com aplicações de alta performance e disponibilidade, identificação e otimização de gargalos de performance, escalabilidade, caching e sharding. É importante também ter bons conhecimentos de pelo menos um tipo de Unix e seus derivados.

Conhecimentos em C, C++, arquitetura de serviços, desenvolvimento de mashups, experiência com uso e desenvolvimento de APIs (REST, YQL, etc.) e experiência em desenvolvimento para iPhone/iPad são bons diferenciais, porém não são requeridos.

Para estas posições é necessário saber inglês bem, o que quer dizer que você deve ser capaz de conversar e ler/escrever em inglês sem problemas (e eventualmente ser entrevistado em inglês caso necessário).

Estamos procurando por pessoas criativas, que gostem de inovação, de pesquisar e identificar novas tendências e de encarar desafios complexos com agilidade e velocidade. Nosso time é pequeno, jovem e nosso ambiente está em constante mudança e evolução. Queremos pessoas irreverentes, que gostem de desafios, com idéias novas e com vontade de criar produtos incríveis!

A empresa oferece contratação apenas por CLT e benefícios como plano de saúde e vale refeição. Estamos localizados na Vila Olímpia em São Paulo. Geralmente contratamos pessoas de outros estados, mas desta vez infelizmente só estamos contratando pessoas de São Paulo/Capital. Update: Voltamos a contratar pessoas pessoas de outros estados e oferecemos auxílio para mudança (passagem, hospedagem, etc.).

Se você se encaixa neste perfil, envie seu curriculo em inglês para mim (gc AT yahoo-inc.com) com uma lista dos últimos 3 livros técnicos que leu. Não esqueça de colocar links para o seu Twitter, LinkedIn, GitHub e o que mais você achar relevante e que pode nos ajudar a te conhecer melhor. :)

Update: mais detalhes sobre a vaga (em inglês) na página de desenvolvedores do Meme.

2 anos de Scrum e Agile na Globo.com e algumas coisas que eu aprendi

Friday, December 4th, 2009

Já se passaram pouco mais de 2 anos desde que começamos a trabalhar oficialmente com Scrum e Agile na Globo.com e um pouco mais de 2 anos e meio desde que a coisa toda começou de fato.

Depois de trabalhar diariamente com processos ágeis e uma porção de times diferentes na Globo.com, minha sensação é a daquele dito popular que diz que quanto mais você sabe de alguma coisa, mais você descobre que tem que aprender. De tempos em tempos surgem idéias novas excelentes e as vezes são coisas tão simples que eu me pergunto porque nunca tinha pensado nelas. Ou então algumas idéias que não deram certo no passado voltam à tona, são colocadas em prática e passam a funcionar muito bem. Sempre que eu acho que já aprendi como alguma coisa funciona alguém aparece com uma idéia melhor e me prova que eu estava errado em achar isso.

Me lembro quando perguntei lá no início para o Boris Gloger sobre o tempo que levaria para as coisas acontecerem. Na época ele falou que para uma empresa do tamanho da Globo.com certamente levaria de 2 a 4 anos para as coisas mudarem de fato. Eu achei um exagero e que ele estava louco, mas era eu que não tinha noção do tamanho da coisa toda. Ele estava certo.

Infelizmente eu não tenho uma história romântica para contar e estaria mentindo se dissesse que as coisas são maravilhosas depois que você adota Agile, Scrum ou o que quer que seja. Muito pelo contrário, os problemas começam a aparecer e tudo fica caótico. As vezes a quantidade de problemas chega a ser enlouquecedora e minha insônia aumentou consideravelmente depois disso. Mas eu não tenho nenhuma dúvida de que os processos ágeis são os que mais se adaptam às características de projetos de desenvolvimento de software, mais do que qualquer outra coisa que eu já tenha usado. Tivemos muito mais sucesso do que em qualquer outra iniciativa na história da empresa e as coisas acontecem muito mais e muito melhor do que aconteciam antes, mas mesmo assim ainda temos um caminho muito longo pela frente.

Hoje eu consigo entender com mais clareza o real sentido do empirismo que tanto se fala. Mesmo com pilhas de livros sobre desenvolvimento ágil na minha prateleira, eu olho para trás e vejo que o processo de “tentativa e erro” foi muito mais importante para o meu aprendizado do que qualquer teoria. Várias coisas escritas nos livros deram certo para alguns times e não deram para outros, e no fim das contas o que ficou foi uma mistura de todas essa experiências. Fomos fazendo as coisas, vendo o que dava certo ou errado, mudando, adaptando e seguindo em frente. Hoje não dá pra dizer que a Globo.com usa Scrum, XP, Lean ou Kanban. Você pode encontrar todos os seus sabores preferidos de Agile por aqui, às vezes misturados e até mesmo bem customizados e diferentes do tradicional.

Nesse tempo todo vivenciei muitos problemas, muitos sucessos, muitas derrotas, muitas falhas e muita mudança. Eu queria poder dizer que encontrei o Santo Graal do desenvolvimento ágil, mas dificilmente isso existe. E se existir, provavelmente o da minha empresa será diferente da sua e por ai vai. Porém, eu posso falar de algumas coisas que eu aprendi e que talvez possam ser úteis para outras pessoas e empresas:

Você sempre estará em transição.

Basicamente eu não acredito mais em transição ágil como eu já li por ai, que parece uma coisa que tem inicio, meio e fim. Hoje eu percebo que sempre se está em transição. Sempre surgirão projetos novos com características diferentes e sempre será necessário ajustar e se adaptar. Isso tudo fora que as pessoas e os times também mudam, e ai começa tudo denovo. É um trabalho que nunca acaba.

É muito fácil começar a fazer Scrum, o difícil é vencer a resistência das pessoas.

Grande parte do meu tempo nesses anos foi investido em quebrar barreiras e a resistência das pessoas. E não estou falando de diretores ou gerentes, às vezes os piores problemas estão dentro dos times. Os mais diversos tipos de problemas acontecem: tem gente que tem medo de trabalhar em par e expôr suas fraquezas para os outros, tem gente insatisfeita na empresa que envenena iniciativas, enfim, acontece de tudo. É muito importante trabalhar com pessoas bem intencionadas, comprometidas e que acreditam no que estão fazendo e que acreditam que as coisas sempre podem (e devem) ser melhoradas.

As pessoas precisam estar felizes.

É importantíssimo que a empresa reconheça seus talentos, que eles ganhem o que merecem e que eles trabalhem num ambiente agradável. Ninguém trabalha direito e dá 100% do seu potencial se não estiver feliz e satisfeito com a empresa. Pessoas infelizes e insatisfeitas podem acabar com um time inteiro, por isso a empresa tem que dar o primeiro passo e dar todas as condições para que isso não aconteça e, quando acontecer, resolver o problema o mais rápido possível.

Se o foco das pessoas for em “fazer telas”, “testar” ou “escrever software”, você está perdido. O foco das pessoas deve ser o produto, e não a sua função.

Muito desenvolvedor não gosta de fazer teste exploratório “porque isso é função do cara de QA”. Muito designer não gosta de fazer CSS e HTML porque isso é coisa de “desenvolvedor de front-end”. Bullshit! Imagine se um zagueiro está com a bola na linha do gol e diz que não vai fazer o gol porque não é atacante? Não tem essa, o foco é ganhar o jogo, entregar o produto, deixar o cliente feliz, não importa fazendo o que. Com o tempo você descobre a receita do time (quantidade de pessoas de cada especialidade) para que as pessoas passem a maior parte do tempo fazendo sua especialidade, mas isso não significa que elas não devem fazer ou entender de outras coisas.

Escalar não é facil. Aliás, se for possível, não escale nunca.

Times ágeis funcionam melhor quando são pequenos, porque o universo de pessoas é menor e a comunicação é melhor, as pessoas confiam mais no resto do time e por aí vai. Quando o número de pessoas e de times aumenta, a comunicação fica problemática e isso gera uma porção de problemas, desde coisas triviais como conflitos de merge até coisas mais complexas de resolver como falta de confiança, dificuldade em mudar de direção, dificuldade de passar a visão do produto, pessoas querendo aparecer mais do que outras e por aí vai. Faça um teste: reuna 30 amigos seus e tentem combinar um lugar para almoçar em no máximo 2 minutos. Repita o teste com 3 amigos e compare os resultados. Foi possível combinar um único lugar de forma unânime? Quanto tempo levou? Quais foram os conflitos de interesse? Qual foi o nível de barulho, stress e insatisfação das pessoas? Ter mais pessoas ajudou a fazer com que a decisão fosse mais rápida ou mais demorada? Talvez esse não seja o melhor exemplo do mundo mas vai ser bem fácil de perceber como times grandes se organizam com muito mais dificuldade.

Boas práticas de engenharia e desenvolvimento ágil como automatização, testes, refatoração, programação em par, integração contínua e TDD são fundamentais, imprescindíveis, inevitáveis, totalmente obrigatórias.

Todos os grandes saltos de qualidade e produtividade que demos na história da evolução da Globo.com foram porque essas práticas foram intensificadas e usadas com mais disciplina, e todas as vezes que elas não recebem a devida importância a velocidade diminui, a produtividade baixa e o time entrega menos (e com mais defeitos).

Um dos “problemas” com o Scrum é que ele não fala nada sobre usar essas práticas. Isso é proposital porque o intuito era que ele fosse bastante genérico e simples, mas como muitas pessoas gostam de seguir o livro cegamente sem pensar, elas acabam achando que não é necessário fazer o que não está escrito, e daí a probabilidade de fracasso é gigantesca. Você pode usar Scrum para produzir um marca-passo, por exemplo, mas você seria louco de não testá-lo exaustivamente só porque não está escrito? Você tem que fazer, porque é uma necessidade imposta pelo tipo de projeto. Com software não é muito diferente: se você não faz TDD, seu código fica pouco testável, e consequentemente você refatora menos ou tem dificuldade para fazê-lo. Consequentemente o tempo para implementar novas funcionalidades aumenta cada vez mais e como o cliente está sempre cobrando mais e mais coisas, você passa a testar menos para dar tempo de fazer mais funcionalidades. E por aí vai (para o buraco).

As regras são excelentes quando você não sabe o que está fazendo. Depois que aprender, quebre-as.

Geralmente quando as pessoas começam com Agile o que se recomenda é que você siga as regras à risca por algumas iterações até que você aprenda e que o processo esteja “no sangue”, e só depois que possíveis customizações devem ser feitas. Muita gente confunde isso com “sempre siga as regras à risca”. Por exemplo, hoje alguém me convenceu numa conversa que o Sprint Planning 2 do jeito que um determinado time estava fazendo estava bem inútil, uma grande perda de tempo. A sugestão foi fazer uma coisa mais “just-in-time”, ou seja, na hora que a história começar a ser desenvolvida. Muita gente pode falar que “ah, mas não é assim que o Scrum funciona” ou o clássico “aqui na empresa nós não fazemos desse jeito”. Se você tem um bom motivo para mudar as regras do jogo, discuta o assunto com o time e implemente as melhorias. Não existe essa coisa de “as regras do Scrum”, existem times produtivos com alta capacidade de adaptação e em constante evolução ou times que passam 50% do tempo discutindo o processo e não deixam o cliente feliz.

Trabalhar num ambiente ágil é muito muito muito mais divertido.

Acabei de passar quase 40 dias de férias e em conferências. Muita gente estaria odiando voltar para o trabalho depois disso, mas eu gostei. Quando eu cheguei hoje na empresa depois de mais de 1 mês a minha mesa já não era mais minha e eu não achava meu computador. O escritório mudou totalmente e o time que eu estava está todo misturado. Quando eu entrei na sala as pessoas estavam em pé discutindo, rabiscando no quadro e o barulho estava alto pra caramba. Depois de contar as novidades, de almoçar e de alguns updates, passei o resto da tarde programando em par numa tarefa que nem eu e nem o meu par faziamos idéia de como resolver, mas juntos descobrimos como fazer e resolvemos o problema. Foi um dia caótico porém muito produtivo e muito divertido, como a maioria dos que eu tenho. Tudo muda muito e está em constante evolução, e cada dia é um novo desafio. Se você gosta de ficar escondido atrás da “baia” e tem dificuldades em dividir o seu teclado com um amigo, recomendo fortemente que você não use Agile.

Agile não é o Santo Graal.

Nenhum processo de desenvolvimento (ágil ou não) é perfeito. Muita gente gosta, muita gente não gosta, alguns não se adaptam, outros se motivam a cada dia com os novos desafios e é assim que as coisas funcionam. <ironia> “Agile é tão perfeito” </ironia> que quando as coisas dão errado é muito mais fácil culpar o seu processo e reclamar que ele não funciona. Bullshit! Como o Jeff Patton fala, as pessoas fazem isso porque o processo não vai se defender de você e porque é muito mais dificil assumir e enxergar os problemas de verdade. Uma das chaves de ser bem sucedido nesses processos é entender que eles são apenas ferramentas muito simples e que se não estão funcionando é porque você precisa encontrar e resolver algum problema da sua empresa, do seu time, das pessoas ou do que quer que seja. Não bote a culpa no processo.

As pessoas são mais importantes que o processo. Foco nas pessoas.

São elas que fazem tudo acontecer. Quanto mais agentes de mudança sua empresa puder ter, melhor. A empresa tem que reconhecer essas pessoas e motivá-las para que elas motivem ainda mais seus pares e assim por diante. É preciso dar liberdade para elas criarem, tentarem coisas novas e errarem sem medo de serem repreendidas. Faça de tudo para que todos estejam felizes e motivados. Resolva os conflitos. Coloque tudo em pratos limpos. Trate todos com respeito e como amigos. Faça as pessoas crescerem e deixe (e ajude) que elas tenham visibilidade dentro da empresa. De todas as coisas que eu vi até hoje, nada é mais eficaz do que ter as pessoas certas do seu lado.

Nada disso é definitivo e eu posso mudar de opinião a qualquer momento sobre qualquer uma dessas coisas. Aliás, hoje numa conversa aprendi que é ótimo mudar de opinião, porque significa que você aprendeu alguma coisa nova/diferente que te fez pensar de uma forma nova/diferente e, portanto, você evoluiu. Fica então a última:

Crie sua opinião, aprenda mais e mude sua opinião. Esteja em constante evolução.

[PythOnCampus-RJ] Eu fui!

Monday, May 11th, 2009

Adorei participar do PythOnCampus nesse último sábado e conhecer várias pessoas muito legais da comunidade Python carioca (que não vou citar para não correr o risco de esquecer alguém)! Vejam as fotos no blog da comunidade PythOnRio.

Minha palestra sobre Testes e Qualidade de software em Python foi bem divertida! Quando percebí que a galera estava bem interessada eu deliberadamente estourei totalmente o tempo e ficamos quase duas horas falando sobre conceitos de testes, TDD e outras práticas de XP, doctest, unittest, pMock, Pyccuracy e por aí vai… Mais do que teoria, vimos bastante código Python!

Para quem não conseguiu anotar, a bibliografia que recomendei no final foi a seguinte:

Nas próximas semanas o PythOnCampus será repetido em outras faculdades pelo Rio de Janeiro. Acompanhem o site da comunidade PythOnRio para ficarem por dentro das datas e dos detalhes.

PythOnCampus-RJ, uma oportunidade para conhecer mais sobre Python

Thursday, May 7th, 2009

Nesse próximo sábado vai acontecer o PythOnCampus, um evento sobre Python promovido pela comunidade PythOnRio para disseminar informações sobre Python e software livre.

Eu estarei por lá falando sobre Testes e Qualidade de software em Python. Será uma apresentação bem prática (hands-on) onde vou explicar a importância de se desenvolver com testes (antes) e mostrar algumas ferramentas para desenvolver testes unitários e funcionais em Python. Haverão também outras apresentações sobre diversos assuntos como Django, jogos em Python, Pyrobotics e mais. Veja a grade de programação completa.

O evento será na Universidade Gama Filho no campus de Piedade no dia 09/maio/2009 a partir das 09:00 horas e a entrada é gratuita, basta se inscrever no site da Gama Filho.

[Agile 2008 Conference] From High-performing to Hyper-performing Agile teams

Saturday, August 23rd, 2008

Voltei depois de quase duas semanas para fazer meu último comentário sobre a Agile 2008 Conference (antes tarde do que nunca!). Esses dias foram um pouco agitados e acabei não conseguindo escrever antes…

O painel de discussões entitulado From High-performing to Hyper-performing Agile teams com a participacao de Jeff Sutherland, Rob Mee e Jason Titus foi ótimo para mim. Eu não esperava ouvir certas coisas que ouví, mas foi ótimo para pensar e abrir mais ainda a cabeça.

Foram quase duas horas de discussão sobre vários assuntos, até o famoso mito do “Rails não escala” entrou em pauta. Mas o que eu quero falar é de uma boa parte da discussão que foi relacionada à PatientKeeper, empresa na qual o Jeff é CTO e na qual concebeu o Scrum para desenvolver vários sistemas na área da medicina que fazem desde o controle do histórico de pacientes e armazenamento digital de exames até soluções para ajudar a organizar enfermarias, departamentos administrativos e o que mais você imaginar que um hospital tem. A PatientKeeper é inclusive citada no livro do Ken Schwaber e reconhecida como o início da existência do Scrum.

A primeira coisa que me surpreendeu é saber que 80% dos testes desses sistemas não são automatizados. Por incrível que pareça, a justificativa do Jeff é muito razoável: todos os sistemas da PatientKeeper são feitos para funcionar numa variedade enorme de dispositivos, desde Palms até iPhones e computadores convencionais. Basicamente o sistema tem que funcionar onde os médicos se sentirem mais confortáveis para usar. Ele argumentou que é muito difícil automatizar testes de interface em todos esses dispositivos, e por isso eles têm uma equipe de testes responsável por fazer este trabalho.

Antes de tudo, não, eu não acho isso ideal, inclusive eu sou um grande adepto dos testes de aceitação automatizados. Mas no caso deles não é possível automatizar os testes, então, bola para frente oras!

Recentemente no meu time na Globo.com passamos por algo parecido quando acabamos optando por não fazer testes de uma aplicação da forma que achavamos ideal. Como já diz o ditado, o ótimo é inimigo do bom. O que nós precisavamos era de uma solução suficientemente boa e que fosse implementável. A solução ideal demoraria muito para ser implementada e daria um trabalho enorme para ser mantida. Já a solução que demos, apesar de não ser perfeita, já está pronta e começando a render seus frutos.

Resumindo isso tudo, temos que tomar cuidado para não sermos utópicos – algumas vezes temos que ser pragmáticos e fazer o que resolve o problema.

A segunda coisa é que me surpreendeu é que, para cada grande funcionalidade que eles fazem, é feito antes do desenvolvimento todo o design e um protótipo do sistema para aprovação de todos os usuários (os médicos) e só depois de aprovado o protótipo o sistema é desenvolvido.

Mais uma vez, eu não acho ideal. Definidas as necessidades do projeto e sabendo onde se quer chegar com o produto, o melhor é que o time inteiro trabalhe junto, história por história, criando pequenos incrementos de software até que tudo esteja pronto. Inclusive eu cheguei a perguntar se ele não estaria fazendo uma espécie de “Scrum waterfall”, e ele nem pensou para responder categoricamente que não. Em primeiro, esse esquema não é feito para qualquer coisa, mas sim para as grandes funcionalidades e mudanças ou para sistemas novos. E em segundo, ele disse que alguns médicos são extremamente resistentes para usar o software no início, e se eles suspeitarem que há qualquer problema no projeto do software ou que “aquele botãozinho está difícil de enxergar”, eles simplesmente destroem o produto e perdem a vontade de usar. Considerando tudo isso e ainda que as mesmas coisas têm que funcionar numa dezena de dispositivos diferentes, deve ser realmente um desafio e tanto projetar essas interfaces para terem uma boa experiência de uso. Por isso tudo o design das telas é crítico para eles, e para ajudar a lidar com essa questão o processo de trabalho foi adaptado para ter esse “pré-projeto” dos sistemas.

A mensagem que devemos tirar dessas experiências é que não dá para ficar preso a uma metodologia! As metodologias servem para ajudar e não para te impedir de atender aos seus clientes e entregar software da maneira que é mais adequada para eles. Indivíduos e interações são mais importantes que processos ou ferramentas, e é entender isso plenamente que te faz ser verdadeiramente ágil. Os processos ágeis como o Scrum são adaptativos, e é sim recomendável que você siga eles à risca no início mas nada te impede de fazer ajustes ao longo do caminho – desde que você não quebre os pilares básicos como o desenvolvimento iterativo e incremental e as práticas/reuniões/papéis no caso do Scrum.

Pense fora da caixa!

Não dá pra fazer só mais uma coisinha?

Monday, May 5th, 2008

Desde que o mundo é mundo sempre tentam fazer com que nós programadores façamos mais do que nós achamos que é possível. Não importa quanto tempo você leve para fazer uma determinada tarefa, sempre alguém vem com aquela pergunta: mas não dá pra fazer só mais essa coisinha aqui???

O problema é que nem sempre se tem a percepção exata do que essa “coisinha” significa. A cada “coisinha” a mais que se faz é mais uma coisinha para programar, errar, testar, integrar, testar denovo e dar bug em produção.

No último Sprint da minha equipe aconteceu uma coisa muito engraçada. Uma das tarefas era colocar uma imagem de uma determinada forma em um site. Basicamente tratava-se de uma linha simples de código, só que a história não foi priorizada e por isso não entrou no Sprint. De fato parecia ser uma coisa bem simples. Como era só uma linha de código e todo mundo sabia disso, fizeram uma força danada pra empurrar essa história para dentro do Sprint, mas eu fui o chato e repetí umas vinte vezes: é mais uma coisa para testar e dar bug.

Isso foi no início do Sprint. Casualmente, nos dois dias seguintes o time deu um salto e o trabalho ficou muito adiantado. Com isso foi necessário colocar mais umas histórias para o time não ficar sem o que fazer e entre essas histórias estava a tal da linha para colocar uma imagem numa tal posição.

Fim do Sprint, tudo estava testado e o pacote com a aplicação fechado. Quando colocamos o site em produção, das 17 (dezessete) histórias que fizemos adivinha qual foi a única que deu problema??? A maldita “coisinha”, que por causa de uma configuração que só existia no mod_rewrite do Apache de produção não funcionava nem por um milagre! Até descobrir esse problema e resolvê-lo levamos algumas horas, sem contar que manchamos nosso histórico de alguns Sprints sem colocar bugs em produção…

Essas “coisinhas” de última hora nunca são tão simples quanto parecem. No mínimo é mais uma coisa para testar e dar bug em produção. :)

Programadores de Schrödinger

Tuesday, April 29th, 2008

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. :)

Test infection: por onde começar?

Sunday, March 30th, 2008

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>

[QCon 2007] Cedric Beust e Alexandru Popescu: Designing for testability

Thursday, November 8th, 2007

Cedric Beust e Alexandru Popescu, criadores do framework de testes TestNG, fizeram uma apresentação entitulada “Designing for testability“.

QCon 2007 - Alexandru Popescu e Cedric BeustEles falaram algumas coisas interessantes sobre os “inimigos” da testabilidade como chamadas entranhadas à métodos estáticos, encapsulamento ao extremo (atributos private final) e cuidado com Singletons.

No geral a apresentação foi média mas acabou servindo para levantar um ponto importante.

Num determinado momento eles falaram claramente que não acreditam muito em Test-Driven Development porque ninguém nunca vai aplicar corretamente. Eles alegam que as pessoas não gostam de escrever código que dá erro de compilação e que fica “vermelho no Eclipse” para depois escrever código que funciona. Por isso eles na maioria das vezes não usam a técnica.

Eu acho que isso não é um problema do TDD mas um problema das IDEs! O que acontece é que com essas IDEs semi-automáticas de hoje em dia as pessoas ficaram muito acostumadas com o Ctrl+Enter e escrever o teste antes implica em não ter esse tipo de funcionalidade, o que pode dar uma falsa impressão de que você está fazendo algo estúpido. Sem contar que a feature “Build Automatically” faz com que o seu código fique assustadoramente vermelho quando a IDE tenta compilar o teste e não consegue… Se você programar em Ruby, por exemplo, essa falsa impressão desaparece. Quando você escrever um teste para um código que não existe, simplesmente o teste não vai funcionar. Nada de alarmes vermelhos na IDE. Enfim, para mim é uma questão de hábito. Coincidentemente numa das palestras seguintes o Charles Nutter falou exatamente sobre isso e concorda que o problema do TDD no Java são as IDEs.

Para finalizar sobre esse papo de TDD ou não-TDD, gosto muito daquele provérbio budista que diz: “vá sempre pelo caminho do meio“. Não acredito que todo mundo deva ser pragmático e sempre escrever todo e qualquer teste antes de programar absolutamente qualquer coisa. Ninguém vai morrer se você escrever testes junto com a implementação em certos casos. Para mim o que mais importa nisso tudo é o mindset de possibilitar que as dependências sejam isoladas, ter uma suite de testes decente para garantir qualidade/permitir refactorings seguros e coisas desse tipo.

Download