BT

Início Notícias Uma Abordagem Ágil para Reutilização de Código

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

Favoritos

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.

Avalie esse artigo

Relevância
Estilo/Redação

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.

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

Comentários da comunidade

  • Quando reutilizar...

    by Georgeo Rocco /

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    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 /

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    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 /

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    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

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

BT

Seu cadastro no InfoQ está atualizado? Poderia rever suas informações?

Nota: se você alterar seu email, receberá uma mensagem de confirmação

Nome da empresa:
Cargo/papel na empresa:
Tamanho da empresa:
País:
Estado:
Você vai receber um email para validação do novo endereço. Esta janela pop-up fechará em instantes.