programação em par

Software Craftsmanship com Uncle Bob Martin

Posted by andrefaria on Nov 30, 2009 in Agile | 3 comments

O pessoal da Software Engineering Podcast acabou de publicar a entrevista de Markus Völter com o consagrado Robert C. Martin, também conhecido como Uncle Bob Martin autor diversos livros como Clean Code e evangelista do movimento Software Craftsmanship. Recomendo que todos ouçam ao podcast (em inglês) na integra, mas gostaria de enfatizar alguns pontos importantes.

Sobre o Arquiteto de Software

Foto por Anirudh Koul

Segundo Uncle Bob, pensar arquitetura e design vale muito a pena, porém, ele não gosta nada da idéia de se separar a arquitetura da codificação. Os melhores arquitetos são aqueles que codificam e vivem no “mundo que constroem para os outros”, disse. Se um arquiteto não codifica ele fica desconectado das decisões que toma, porque não é afetado por elas, ele ”não tem que dormir na cama que faz”.
O importante é que arquitetos mantenham seus dedos no teclado, a final, você não pode liderar um time a menos que os conheça e entenda. Você tem que experienciar o que o time está fazendo para saber o que ele realmente precisa.

Documentação

O código é documentação mais imporante. Todos os outros documentos devem refletir o que o código faz. O código digire todos o resto e não é apenas resultado de outros documentos como sugure o waterfall.

Software Crafsmanship

O termo foi criado com a publicação do livro de Pete McBreen em 2002. Fala-se sobre aprender com mestres. Aprenda as habilidades e como tomar decisões, mas você deve aprender com outras pessoas ajudando-as a fazerem seu trabalho.

Você deve sentir orgulho da forma que você trabalho.
Sinta orgulho de poder fazer Test Driven Development.
Sinta orgulho de ter alta cobertura de código.
Sinta orgulho de desenvolver software de alta qualidade.
Sinta orgulho de ter um bom design de código.
Sinta orgulho de desenvolver software que realmente agregue valor de negócio aos clientes.

Uncle Bob sugere como práticas TDD, Integração Contínua e Programação em par, e afirma que bons times trabalham em par na maior parte do tempo, no entanto, afirma que não se deve ser religioso quanto a isso, “você não precisa trabalhar em par 100% do tempo”, diz.

Qualidade e Relacionamento com Clientes

Não basta funcionar, o software deve ser bem escrito e fácil de manter. Foque em agregar valor. Deve haver um parceira com os clientes. Você deve realmente envolver-se com as decisões tomadas e garantir que o que cliente pede realmente vai agregar valor para ele. Não faça simplesmente porque é seu trabalho se você já sabe que não vai dar certo. Comprometa-se com o resultado do seu trabalho.

Produtividade

Aprenda os Shortkeys (atalhos de teclado). Tente fazer o máximo que você puder sem usar o mouse. Um desenvolvedor de software deve estar altamente integrado com seu ambiente.
Utilize uma boa ferramenta de SCM (Source Code Control), o CVS é razoável, o SVN é melhorzinho, mas meu favorito é o Git.

Bug Tracking Systems são importantes, mas use com certo cuidado. Devem ser leves e simples de usar.
Use ferramentas para teste como jUnit (xUnit), rSpec, Cucumber, JBehave e Fit.
Linguagens dinamicas são muito produtivas e se você faz TDD o “perigo” vai embora. Você não precisa mais de um compilador para te dar uma falsa segurança.

Desenvolvimento de Carreira

A coisa mais importante para um desenvolvedor de software é noção de aprendizado contínuo. Você nunca pode parar de aprender. É como um médico.

Você deve aprender o máximo de linguagens que puder, e deve conseguir escrever código em todas essas linguagens ainda que não seja um especialista em todas elas. Não adianta. Aprenda no mínimo uma linguagem estática, uma dinâmica e uma funcional. Robert diz que todos devem aprender LISP.

Recado de Uncle Bob no Rails Conf 2009

Uncle Bob Martin na RailsConf 2009 porFabio Akita no Vimeo

Mais Informações sobre Robert C. Martin

Posted by andrefaria on Dec 20, 2008 in Agile, Featured | 20 comments

Já faz algum tempo que a programação em par se tornou uma realidade do meu dia-a-dia, confesso que nos meus primeiros contatos com Extreme Programming (XP) essa era a prática que eu menos gostava, mas depois, ao me envolver mais com práticas ágeis comecei a perceber seus benefícios e inclusive passei a propagar a idéia, porém agora, senti um mais de perto como realmente funciona e gostaria de compartilhar um pouco do que venho aprendendo.

O que é programação e par?

Bernardo e Elmar por ImproveIt

A programação em par é uma técnica que sugere que todo e qualquer código produzido em um projeto de desenolvimento de software seja implementado por duas pessoas juntas, diante do mesmo computador, revezando-se no teclado [1]. A Pessoa quem está com teclado em mãos é chamada de condutor e a outra de navegador.

Por que programar em par?

“Unir-se é um bom começo, manter a união é um progresso, e trabalhar em conjunto é a vitória.”
(Henry Ford)

Foco no trabalho

Focus por Dani Ihtatho

Temos o mundo inteiro de informação e recursos ao alcance de alguns cliques. A internet, o correio eletrônico, o feed reader, somos tentados o tempo todo a nos distrair, e perder o foco do nosso objetivo principal: escrever código. A programação em par nos ajuda a manter o foco, afinal de contas, temos alguém sentado ao lado interessando em ver o problema resolvido, assim, com certeza, mesmo que tentados iremos evitar fazer outra coisa senão concentrar nossas energias em resolver o problema em questão. Isso não quer dizer que seja proibido consultar algo na internet, ou ler e-mails, na Bluesoft, por exemplo, sempre temos algumas máquinas disponíveis para esse tipo de coisa, porém, garanto que a freqüência desse tipo de atividade é bem menor quando se trabalha em par, e não são somente as distrações que são reduzidas, segundo Laurie Williams [3], as pessoas são menos interrompidas por outras quando trabalhando em par do que quando trabalhando sozinhas.

Ensinar e Aprender

Owen teaching Dad how to use the computer pro Jordan Brock

Owen teaching Dad how to use the computer por Jordan Brock

“Aprender é a única coisa de que a mente nunca se cansa, nunca tem medo e nunca se arrepende.”
(Leonardo da Vinci)

Todos nós somos diferentes, pensamos de forma diferente e sabemos coisas diferentes, programando em par essas diferenças podem se complementar de forma positiva trazendo mais qualidade ao trabalho e muito aprendizado a ambos os envolvidos, não somente conhecimentos técnicos, mas também muito conhecimento sobre o domínio de negócio são trocados todo o tempo.

Exterminando ilhas de conhecimento

“uhmmm…, esse problema é só com fulano mesmo, ele quem desenvolveu e sempre deu manutenção nisso, nem adianta tentar porque ninguém mais vai conseguir resolver isso “.

Quem nunca ouviu algo assim? Eu já, e muitas vezes. É comum, especialmente em contextos em que não são aplicadas metodologias ágeis, existirem ilhas de conhecimento, essas ilhas são representam o conhecimento retido por pessoas que não o com outras, muitas vezes por falta de oportunidade, outras por pensar que dessa forma se tornaram insubistituiveis, bobagem.

Ilhas de conhecimento podem se tornar um grande problema, porque a manutenção do software fica extremamente dependente da pessoa que retêm o conhecimento, e essa pessoa pode a qualquer momento sair da empresa, ficar de férias, estar viajando, etc… Mas e quando ocorrer um problema crítico e a pessoa não estiver presente? O grande problema é que tudo fica dependendo da ilha.

A programação em par estimula a troca de conhecimento, faz com que todo a equipe compartilhe o código e saiba um pouco de tudo o que foi desenvolvido, tornando assim, a toda a equipe capacitada a resolver qualquer problema a qualquer momento, se um membro da equipe estiver ausente, provavelmente não haverá poblemas por isso.

Mais disciplina = Mais qualidade = Menos bugs

asians with swords! por miss karen

A programação em par aumenta a qualidade do software sem impactar de forma significativa no prazo [2]. Apesar de ser contra senso que duas pessoas trabalhando em um único computador podem produzir mais valor do que trabalhando separadamente, sem dúvida é fácil de acreditar que irão entregar um trabalho de muito mais qualidade, e essa qualidade adicional, por si só, trará grandes ganhos mais tarde.

Laurie Williams da universidade de Utah em Salt Lake City comprovou que a programação é em média apenas 15% mais lenta do que a programação individual, porém, produz 15% menos bugs [5]. Considerando que testar e debugar é na maioria da vezes muito mais custoso do que a programação inicial, esse é um resultado no mínimo significativo.

Segundo Vinícus Teles, “a pessoa que está conduzindo o teclado (condutor) tem um campo de observação diferente do seu parceiro. Quem digita normalmente está olhando sobretudo para a linha que está editando e adjacências. O navegador, por sua vez, tem uma visão mais ampla e olha não apenas a linha que está sendo editada, mas também o restante do código que aparece na tela. Ao fazer isso, ele acaba tendo uma visão complementar que freqüentemente revela problemas que o condutor não percebe com a mesma rapidez” [1], dessa forma, o código está sendo revisado o todo o tempo, sem contar que programar em par evita que caiamos na tentação de não escrever testes unitários ou deixar refactorings de lado [4].

Dicas

Ping-pong programming (P3)

"Ping (Pong)" por Dustin Baxter

Ping-pong Programming [12] é um técnica que une programação em par e test driven development tornando o a programação em par mais divertida [13], dinâmica e interativa, consiste nos seguintes passos:

O Programador A escreve um novo teste e o deixa falhando.
O Programador B implementa o código necessário para fazer o teste passar.
O Programador B escreve o próximo teste.
O Programador A implementa o código necessário para fazer o teste passar.
O processo se repete.

Pausas

"Pause" por Vanderlin

Pare! Tome um café. Coma alguma coisa. Converse com outras pessoas além do seu par [7]. Tudo isso será bom para que descanse um pouco, se distraia e se prepare para voltar mais disposto e dar continuidade na tarefa.

Cuidado com discussões longas

Estabeleça um time-box para discussões. É comum que dois programadores discordem ao tentar decidir as melhores formas de implementar algo, quando isso acontecer, procure ouvir as razões da outra pessoa e apresentar suas argumentações, tentem chegar a um meio termo, se isso não for possível chame uma terceira pessoa para dar uma opnião. Não resista em ceder quando perceber que outro pode estar certo, lembre-se você está aprendendo e ensinando o tempo todo, não há problema algum em estar errado de vez em quando.

Não se engane!

Wrong Way por Emilie Eagan

Mito: Sem Programação em Par, não há Agilidade

Martin Fowler uma das personalidades mais respeitadas no mundo do desenvolvimento de software escreveu um artigo em 2006 levantando alguns dos principais enganos sobre programação em par. Fowler esclarece em seu artigo que “não é necessário programar em par para estar praticando um processo ágil” [11], nem mesmo para se pode dizer que para aplicar Extreme Programming você é obrigado a programar em par, o máximo que se pode dizer é que alguém aprender XP, deve tentar programar em par e ver se funciona em seu caso em particular [11]. A programação em par não é nem mesmo citada no manifesto ágil, porém, é uma prática altamente recomendada para que se alcance os principios ágeis.

Mito: A Produtividade cairá pela metade

Um outro engano muito comum é pensar que a produtividade dos desenvolvedores cairá pela metade, como discutimos anteriormente, na maioria dos casos essa afirmação será falsa.

Mito: Tenho certeza de que não vou gostar de programar em par

Segundo Fowler, muitas pessoas surpreendem-se e começam a gostar de programar em par depois de tentar, por isso, experimente antes de dizer de não gosta!

Conclusão

Concluo com a citação de Mary e Tom Poppendieck no livro “Implementing Lean Software Development”:

Programação em Par não é para todos, nem para todas as situações, porém, a programação em par cria sinergia: Duas pessoas vão frequentement entregar um código mais integrado, testado e sem defeitos, trabalhando juntas [...]. A Programação em par é uma das melhores formas de se atigir os beneficíos de revisões de código [...] .

Referências

[1] Improvit – Programação em Par
[2] Extreme Programming Rules – Pair Programming
[3] Williams, Laurie (2003). Pair Programming Illuminated, Addison-Wesley
[4] Beck, Kent (2000). Extreme Programming Explained, Addison-Wesley
[5] Cunningham & Cunningham – PairProgramming
[6] Mark Needham – Pair Programming: What works for me
[7] Brian Guthrie – The Way I Pair
[8] thekua.com@work – How I like to pair
[9] InfoQ – Pair Programming Debate
[10] InfoQ – Common misconceptions about paired programming
[11] Martin Fowler – Pair Programming Misconceptions
[12] Pair Programming Ping Pong Pattern
[13] Ping Pong Pairing: Even More Fun!
[14] Poppendieck, Tom and Mary (2007). Implementing Lean Software Development, Addison-Wesley

Posts Tagged "programação em par"

Bluesoft Podcast: Um podcast sobre Métodos Ágeis em Português