Uma discussão recente na lista de Extreme Programming do Yahoo Groups explorou o conflito aparente entre desenvolver software reutilizável e a prática do XP de não escrever o código até que ele seja necessário. Ron Jeffries e outras pessoas compartilharam suas idéias sobre os custos e benefícios da reutilizacão de código, além de como e quando colocá-la em prática em um ambiente Ágil.
Brandon Olivares iniciou a discussão. Ele havia acabado de dedicar 30 horas em um código quando percebeu que tinha a chance de ser reutilizado. Ele sentiu-se confuso sobre o fato de poder ou não generalizar esse código, de forma que outros projetos também pudessem usá-lo.
Até onde eu entendo, o XP desencoraja você a assumir que alguma coisa seria necessária, até que você realmente perceba que ela é necessária. Também conforme o meu entendimento, isso inclui a abstração de código a fim de torná-lo mais genérico para reutilização, até que haja uma duplicação; então ele pode ser refatorado.
A reutilização de software tem sido bastante apontada como um fator de grande economia de tempo. Assim, desenvolvedores de outro projeto podem beneficiar-se reutilizando seu código, ao invés de reinventá-lo. Brandon perguntou aos membros do grupo como eles decidem quando abstrair e generalizar o código, de forma que outros projetos possam reutilizá-lo.
Ron Jeffries foi o primeiro a responder, explicando algumas das razões pelas quais a reutilização entre as equipes podem ser mais difíceis e caras do que parecem a princípio.
Eu preciso ter o trabalho de empacotá-lo, o que não precisaria se fosse usado só por mim; preciso documentá-lo; preciso torná-lo mais sólido, retirando problemas que eu poderia contornar facilmente; preciso dar suporte e responder dúvidas a respeito dele; preciso treinar pessoas para usá-lo.
Se eu faço tudo isso, ele fica caro. Se eu não faço, a utilização do meu código por outras pessoas fica difícil e aí não as ajuda muito.
Tudo isso leva Ron a abordar o assunto dessa maneira:
Eu construo as abstrações que preciso. Se preciso delas novamente, em um contexto diferente, melhoro a abstração. Mas, a menos que o objetivo do meu projeto seja construir infra-estrutura para outros projetos, eu tento não gastar nem tempo nem dinheiro meu, desenvolvendo para os outros.
Outra pessoa observou que a reutilização pode ser facilitada por todos os projetos que compartilham o mesmo sistema de build e um conjunto unificado de testes. Dessa forma, uma equipe que quer reutilizar algum código, pode generalizá-lo para suas necessidades. O sistema de build ajudaria a garantir que nenhum teste dos outros projetos que usam o mesmo código, foi quebrado.
George Dinwiddie, Ralph E. Johnson, e outros recomendaram generalizar na segunda utilização (ou até mais tarde). Adam Sroka chamou essa abordagem de 'reutilização emergencial' e observou que ela parece ser mais eficiente do que o 'projeto para reuso'. Um participante chamado Tim explicou isso para as pessoas de sua empresa da seguinte forma: "Na primeira vez, você paga para o código ser escrito. Na segunda, você paga para ele ser reusado. Na terceira, ele sai de graça."
George alertou que o problema mais difícil poderia ser como fazer que outras equipes fiquem sabendo de um código potencialmente reutilizável. O custo de comunicação necessário para uma descoberta útil pode ser significante. Jeff Langr sugeriu que se os desenvolvedores tivessem pares em outros projetos, poderia ser uma forma eficaz de resolver o problema dessa descoberta.
Scott Ambler entrou na discussão dizendo que o open source é uma forma de reutilização que tem tido muito sucesso. Ele também citou que bibliotecas de código, kits de desenvolvimento, e até mash-ups são exemplos de reutilização de software que funciona.
Adam continuou com essa observação:
É importante distinguir quando minha equipe usa o que ela mesmo usou anteriormente e quando ela usa o que outra pessoa usou em outra época. A segunda alternativa requer maior reflexão... até para alguém de fora da minha equipe ficar sabendo disso. Existe um custo nisso e esse custo precisa reproduzir algum valor melhor para o negócio.
Como você decide quando reutilizar seu código? Deixe um comentário e compartilhe sua experiência.