BT

Uma Abordagem Ágil para Reutilização de Código

por Chris Sims , traduzido por Vinicius Assef em 24 Abr 2009 |

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.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Quando reutilizar... by Georgeo Rocco

Como o texto mesmo já deixa claro o custo de abstrair e generalizar o código, bem como que fazer sem realmente ter a necessidade, faz com que o custo não seja mais na terceira é de graça e sim na primeira custar o dobro caso não seja reutilizado por outra equipe. Por isso somente generalizar quando necessário.

Por que não? by Rafael Miranda

Se na Organização já existe um papel de, por exemplo, Chefe de Desenvolvimento, responsável por vários projetos/sistemas, que consegue identificar reutilizações em potencial, por que não já aproveitar e projetar visando reutilização logo de início e antecipar o ganho?

Outro exemplo seria a existência na Organização de um "Grupo de Arquitetura", responsável pelo alinhamento ou padronização das soluções criadas, que identifique tais reutilizações?

Sendo assim, penso que existem possibilidades diferentes, que podem tornar o projeto visando reutilização adequato e mais barato do que as alterativas apresentadas.

Re: Por que não? by Vinicius Assef

Rafael, gostei da sua colocação sobre o "Grupo de Arquitetura". Eu também me perguntava sobre a mesma questão, até trabalhar numa empresa que tinha essa área "funcionando".

Lá, era chamada de "Desenho de Soluções". Coisa incrivelmente desalinhada e que travava grande parte do desenvolvimento. Eram pessoas com conhecimento muito generalista, que não tinham condição de saber detalhes de todas as implementações. Na boa intenção, acabavam sugerindo coisas impossíveis, e muitos bons re-aproveitamentos passavam despercebidos por eles.

Quem acabava promovendo a reutilização eram as equipes de desenvolvedores mesmo.

Eu acho que esse tipo de equipe realmente não ajuda muito.

--
Atte.,
Vinicius Assef.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

3 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT