TDD mais importante que tudo
No dia 18/09/2010 apresentei a palestra "TDD direto das trincheiras" em João Pessoa, no evento "Agilidade Paraíba" promovido pelo grupo Scrum-PB. O público era bastante jovem e poucos conheciam ou usavam TDD. Espero ter conseguido despertar a curiosidade de várias pessoas, mas na verdade eu ainda fico bastante chocado como tão poucas pessoas/empresas adotam TDD. Como eu coloco no último slide da minha apresentação, "TDD é mais importante que tudo".
A prática do TDD viabiliza economicamente o design evolutivo e em última instância o próprio desenvolvimento iterativo incremental. Através principalmente do TDD é que a curva de custo da mudança pode ser suavizada.
Usando TDD as pessoas perdem o medo de fazer refactoring para remover código duplicado ou para evoluir funcionalidades existentes. O uso do TDD induz ao programador ter um melhor entendimento do negócio. Além disso, usamos menos o debug (que toma um baita tempo), localizamos mais rapidamente os bugs e enfim, escrevemos um código de melhor qualidade.
Se você não usa TDD, sugiro que avalie melhor esta prática. Não é fácil fazer a transição. Leva tempo e esforço, mas quando a ficha cai, você não vai querer trabalhar de outra forma. Estude, se prepare bem. Se precisar de ajudar é só chamar 
Como brinde, deixo aqui um link com uma introdução ao TDD bastante legal. Boa Sorte!
Curado da IDE-dependência
No post "Jogue Fora sua IDE" eu falava sobre a IDE-dependência, de como ficamos dependente de IDEs e de como isso é ruim especialmente quando estamos aprendendo uma nova tecnologia. Pois bem, eu estou CURADO! Já faz um tempo que estou usando (aprendendo) Scala, e sem usar nenhuma sofisticada IDE.
Configurei um ambiente para programar em Scala utilizando apenas o gEdit (linux). O máximo que me permiti foi um syntax highlight, mas nada de code assist. De quebra, estou usando o sbt em um terminal integrado ao editor. Veja só:
Cuidado com a IDE-dependência. IDEs são ótimas ferramentas de produtividade, mas só funciona para quem domina o que está fazendo.
Agilidade Paraíba 2010
No dia 18/09/2010 vai acontecer o evento "Agilidade na Paraíba 2010", organizado pelo Grupo de Usuários Scrum Paraíba. Vou participar deste evento apresentando "TDD direto das trincheiras".
Acho muito legal que TDD venha gerando cada vez mais interesse, especialmente em nossa região. Isso porque eu digo e não me canso de repetir que TDD é a prática relacionada com engenharia de software mais importante do universo ágil. Através de TDD que você consegue suporte para design evolutivo, simplicidade e consequentemente desenvolvimento iterativo e incremental que DÁ CERTO! Nos vemos lá...
Para inscrições e mais informações, acesse: http://scrumpb.org
Codificação é Commodity?
Ouvi uma coisa no início dessa semana que não saiu da minha cabeça: "codificação é commodity". E aí? Será que é mesmo?
Quando usamos o termo commodity para serviços deve ser necessário que as empresas tenham uma certa uniformidade em relação a prestação deste serviço. Por exemplo, enviando uma especificação para duas "fábricas" de software espera-se que ambas entreguem o mesmo produto (com poucas diferenças) e mais ou menos no mesmo prazo. Em um cenário assim, a escolha do fornecedor vai depender primordialmente do preço. Vamos escolher a "fábrica" que cobrar mais barato. Para fortalecer ainda mais este conceito, temos certificações como o MPS.BR e CMMI que servem para classificar os fornecedores. Imagina-se então que duas empresas que são CMMI nível 5 devem produzir mais ou menos a mesma coisa no mesmo prazo e portanto, posso escolher a que me cobrar mais barato. Você realmente acredita nisso?
Diferentemente de como muita gente pensa, codificação não é uma atividade mecânica. Não existe nenhuma máquina em que você coloque as especificações em um buraco e saia o software pronto do outro lado. Arquiteturas, especificações, designs são modelos meramente teóricos. Nenhum arquiteto ou projetista pode garantir que aqueles esquemas irão funcionar. Para saber se vai funcionar o sistema tem estar codificado e rodando. Na prática esses modelos teóricos ajudam a estruturar o problema e definir as soluções em um nível mais abstrato, mas durante a implementação é que os detalhes emergem e as decisões finais são tomadas. Não sendo uma atividade mecânica que dizer então que não pode se considerar uma commodity? Acho que não, outros fatores devem ser analisados como por exemplo o desempenho dessa "indústria".
E como está o desempenho dessa "indústria"? Basta dar uma olhada no resultado do CHAOS Report (relatório anual do desempenho dos projetos de desenvolvimento de software feito pelo Standish Group). Em 2009 apenas 32% dos projetos de software foram considerados plenamente bem sucedidos. Como uma "indústria" com desempenho tão ridículo pode oferecer um serviço considerado commodity?
Cuidado, se você vai contratar uma empresa de desenvolvimento de software não olhe apenas para o preço. Fazer software é muito difícil e muito pouca gente sabe. Procure uma empresa que tenha um portfólio de sucessos. Não acredite apenas nessa bobagem de certificações, isso não vale nada. Tratar desenvolvimento de software como commodity só vai trazer dor de cabeça e prejuízo.
Por que você precisa (re)aprender linguagens funcionais?
Continuo investindo neste tema. Essa apresentação fiz em maio aqui no CESAR.
Café Ágil
Sábado passado (dia 15/05/2010) participei do evento Café Ágil promovido pela ThoughtWorks Brasil no Centro de Informática da UFPE. Neste evento eu apresentei o trabalho "TDD Direto das Trincheiras", mesmo trabalho que já havia apresentado no evento Agilidade na Prática em Novembro de 2009. Naquela oportunidade, deixei pra fazer a apresentação em cima da hora e ficou bem nojentinha (veja aqui), desta vez pedi ajuda a Jinmi Lee, que deu uma reformulada no ppt. Vejam a diferença:
Para uma comunicação eficiente é necessário que tanto o contéudo quanto a apresentação sejam bem feitos. Apenas com a união desses dois fatores será possível passar a mensagem de forma eficaz.
Voltando ao evento, as apresentações de Paulo Caroli e Jim Webber foram ótimas e a participação do público foi bem legal. Bastante interessante também a mesa redonda (a mesa era retangular mesmo), que além da minha presença e a do Paulo, ainda contou com a participação de Luciano Felix (Provider Sistemas), Cristine Gusmão (UFPE) e Alexandre de Vasconcelos (UFPE). Parabéns a todos pela organização e espero que tenha mais eventos desse nível por aqui.
Jogue fora sua IDE
Há algum tempo atrás, um amigo meu (Samuel) me disse que quando estava aprendendo algo novo (um framework ou uma nova linguagem) ele preferia usar o notepad ao invés de uma IDE. Naquele momento eu não dei muita importância, e ainda disse que era frescura, que usar uma IDE era bem melhor. Na hora eu não me dei conta, mas hoje vejo que eu já estava com IDE-dependência aguda.
Estou estudando Scala, e a primeira coisa que procurei para começar o estudo foi uma IDE para começar a dar meus primeiros passos. O problema é que não existe ainda nenhuma IDE que seja boa o suficiente para Scala. Primeiro tentei o Eclipse, mas o plugin está incrivelmente instável, não deveria ser nem disponibilizado para download. O Netbeans não está muito a frente e o IDEA é o melhorzinho, porém com muitos bugs também. Resultado, fiquei com o IDEA e comecei a trabalhar. Por conta dos problemas e dificuldades em pouco tempo eu travei. Perdi a paciência por usar uma ferramenta com tantos problemas e parei os meus estudos práticos.
E agora? Vou ter que esperar meses (ou anos) para que alguém desenvolva uma IDE boa o suficiente? E quando não existia ferramentas com esse nível de recursos? Como a gente se virava?
Quando eu comecei a trabalhar, usava Turbo C 2.0. Alguém se lembra? Não tinha syntax highlight, abria apenas um arquivo por vez e code assist nem pensar. Tinha copy and paste e lamba os beiços. E que saber? Era uma ferramenta muito boa. Era boa e produtiva pela simples razão que EU SABIA O QUE ESTAVA FAZENDO.
As ferramentas de hoje em dia são tão sofisticadas, tem tantos recursos e facilidades, que criaram uma geração de programadores que são absolutamente dependentes delas. Programadores que não são capazes de saber que método de uma determinada classe ele precisa chamar. Se não tiver um code assist eles simplesmente não sabem o que fazer (muitos não sabem nem com o uso do code assist).
Precisamos abandonar um pouco nossas IDEs. Precisamos (re)aprender as linguagens e frameworks sem o uso dessas facilidades. Só quando finalmente estivermos seguros sobre o nosso conhecimento é que estamos autorizados a usar as IDEs. Bye bye IDEA, seja bem vindo o Notepad. Agora finalmente vou APRENDER Scala. Depois de um momento de negação estou finalmente me curando da IDE-dependência. Samuel, você estava CERTO!
Porque linguagens funcionais são importantes
Dos 3 principais paradigmas de programação (funcional, imperativo e orientado a objetos), o funcional é o mais antigo. A primeira linguagem de programação funcional foi criada em 1955 (IPL) e a mais popular LISP foi criada em 1958. Apesar de surgirem um pouco depois (Fortran e COBOL foram criadas respectivamentes em 1956 e 1959), as linguagens imperativas tiveram maior popularidade. Mesmo sem ter alcançado o mainstream, o paradigma funcional continou recebendo investimentos ano após ano até meados dos anos 90, quando a turma das linguagens imperativas se fundiu definitivamente com o pessoal de orientação a objetos (C++ e principalmente Java são exemplos) enterrando as linguagens funcionais no lixo da história. Acabaram as esperanças desse paradigma se tornar parte do mainstream. Será?
O tempo passou e nos últimos anos alguns sinais começaram a aparecer. Erlang (linguagem funcional proprietária criada pela Ericsson) que foi banida e distribuida de forma open-source em 98, volta a ser utilizada pela Ericsson (e por muitos outros) em 2004. A Microsoft lança o F# (linguagem funcional para a plataforma .NET). O pessoal do Twitter reescreve seu back-end em Scala (linguagem funcional e OO para a plataforma Java). C# incorpora conceitos funcionais na sua linguagem para dar suporte ao LINQ. A Google publica artigos mostrando como utiliza o paradigma funcional para armazenar e recuperar dados. Porque esse interesse no paradigma funcional foi renovado? Qual o pulo do gato?
Devido a proximidade de limites técnicos e preocupação com consumo de energia, o pessoal de hardware está focando no desenvolvimento de novos processadores em soluções de múltiplos cores. Em breve teremos processadores com centenas de cores. Para se beneficiar deste panorama, temos que escrever softwares que executem de forma paralela. A boa notícia é que é muito mais fácil escrever código concorrente em liguagens funcionais do que em linguagens imperativas.
Não existe um único paradigma que seja indicado para resolver todos os tipos de problemas. Precisamos aprender (ou reaprender) o paradigma funcional, que foi abandonado por muito tempo. Precisamos de linguagens que incluam de forma coerente vários paradigmas, para que a gente possa escolher a melhor forma de resolver um determinado problema. Por fim, precisamos aprender Scala, que me parece a mais promissora nas novas linguagens multi-paradigma.
TDD direto das trincheiras
Essa foi a apresentação que fiz no evento "Agilidade na Prática" em 30/11/2009. Este evento foi promovido pelo SPIN Recife.
Sprint Planning Meeting II ou Sprint Design Meeting?
Qual o principal objetivo da reunião de Sprint Planning Meeting 2? 
Em muitos lugares você poderá encontrar uma resposta simplista para essa pergunta: O objetivo é dividir os itens do product backlog em tarefas de no máximo 8 horas (ou 16 em algumas fontes). Mas dividir como?
Durante a Sprint Planning Meeting 1, o time e o product owner selecionaram de comum acordo alguns itens para serem trabalhados durante o sprint em questão. Para chegar neste ponto, o time teve que discutir em mais detalhes cada item de backlog, tirar eventuais dúvidas e revisar algumas estimativas. Em função disso, podemos perceber claramente que se trata de uma reunião para discussão e esclarecimento dos requisitos. Até este momento estamos apenas trabalhando em cima do domínio do problema, ainda não entramos na solução.
No Sprint Planning Meeting 2 a cuíca muda o tom. Se pensarmos que o objetivo principal é apenas dividir os itens em tarefas, vamos estar na verdade apenas dividindo o problema, mas aqui precisamos na verdade é dividir a solução. Para chegar na solução o time vai ter que fazer design (análise & projeto), que é exatamente o objetivo desta reunião.
Agora, será que faz diferença? Será que dividir o problema é diferente de dividir a solução? Vejamos alguns exemplos:
Considere o item de backlog chamado Login do Usuário. Algumas possíveis tarefas para Sprint Planning Meeting 2 sem foco em design:
- Implementar tela de login
- Implementar serviço de autenticação
Muito bom, com esse conjunto de tarefas eu posso fazer o item de backlog, o problema é que agrega muito pouco e para efeito de planejamento é desastroso, afinal o time não sabe exatamente o que vai fazer em cada uma dessas tarefas. Tudo vai ser descoberto apenas na hora H. Neste cenário observamos que é muito comum a criação de diversas novas tarefas durante o sprint.
Vamos ver agora que tarefas eu poderia criar se tivesse realizado a reunião com foco em design:
- Criar tela de login
- Selecionar lib js para chamar serviço de autenticação via ajax (supondo que é ajax e uma lib ainda não foi selecionada)
- Criar serviço de autenticação
- Criar query com login=login e senha=senha
- Criar classe de Usuario (campos: login e senha)
- Criar método para criptografar a senha (escolher método)
- e por aí vai...
O que acontece no novo cenário é que a equipe se aprofundou na solução. Neste caso o time pôde definir melhor o escopo de cada tarefa, antecipar dúvidas e eliminar riscos. Mas afinal para que serve o planejamento?
Resumindo:
- Sprint Planning Meeting 1 = Requisitos
- Sprint Planning Meeting 2 = Design
E ainda assim: Sprint Planning Meetings = planejamento.