Comments on: Evolução de Componentes e Serviços http://www.aqueleblogdesoa.com.br/2008/08/evolucao-de-componentes-e-servicos/ SOA? Veja bem... Sat, 10 Jul 2010 16:13:57 -0300 http://wordpress.org/?v=2.8.4 hourly 1 By: Eduardo Machado http://www.aqueleblogdesoa.com.br/2008/08/evolucao-de-componentes-e-servicos/comment-page-1/#comment-209 Eduardo Machado Mon, 18 Aug 2008 11:58:33 +0000 http://aqueleblogdesoa.wordpress.com/?p=319#comment-209 - A principal referência que conheço que liga métodos ágeis e refactoring é o livro do Fowler "Refactoring: Improving the Design of Existing Code". Ele justamente prega essa necessidade rotineira por limpeza de código durante iteration, sprint, etc. Além do mais acho que a questão levantada pelo Paulo Camara é abordada justamente na definição que Fowler faz desta atividade, que é obter uma versão do software que seja funcionalmente idêntica, porém com aspectos de qualidade (o principal é a manutenibilidade) melhoradas. - A evolução de componentes é sempre complicado, e uma das referências que gosto são pesquisas de CBD do IC-UNICAMP. Este artigo é uma metodologia que, dentro do esquema tradicional de atribuir números de versão no formato Major.Minor.Update, essa metodologia mostra uma forma sistemática de incrementar esses números a partir de alterações no componente (e por extensão serviços). http://www.ic.unicamp.br/~alobo/publications/04-lobo.pdf Abs. - A principal referência que conheço que liga métodos ágeis e refactoring é o livro do Fowler “Refactoring: Improving the Design of Existing Code”. Ele justamente prega essa necessidade rotineira por limpeza de código durante iteration, sprint, etc. Além do mais acho que a questão levantada pelo Paulo Camara é abordada justamente na definição que Fowler faz desta atividade, que é obter uma versão do software que seja funcionalmente idêntica, porém com aspectos de qualidade (o principal é a manutenibilidade) melhoradas.
- A evolução de componentes é sempre complicado, e uma das referências que gosto são pesquisas de CBD do IC-UNICAMP. Este artigo é uma metodologia que, dentro do esquema tradicional de atribuir números de versão no formato Major.Minor.Update, essa metodologia mostra uma forma sistemática de incrementar esses números a partir de alterações no componente (e por extensão serviços).
http://www.ic.unicamp.br/~alobo/publications/04-lobo.pdf

Abs.

]]> By: marcilio http://www.aqueleblogdesoa.com.br/2008/08/evolucao-de-componentes-e-servicos/comment-page-1/#comment-210 marcilio Fri, 15 Aug 2008 13:22:32 +0000 http://aqueleblogdesoa.wordpress.com/?p=319#comment-210 Aproveitando o assunto e ótimo texto do Ventura.... Quando falamos de refactoring de componentes de caixinha, pensamos no update de versão do componente para os sistemas em produção que o utilizam. Embora seja o ideal, sob ponto de vista de gerenciamento dos componentes e controle de qualidade, isso pode muitas vezes não ser atrante, e nem ser justificável para os projetos. O que tenho percebido é que, de boa vontade, os sistemas vão evoluir ou atualizar versões de componentes apenas para duas situações: -1) evoluções que de fato impactem diretamente na utilização do componente no sistema (performance, por exemplo). -2) correção de defeito :-) O sonho do grupo de componentes em manter todos os usuários usando as mesma versão do componente é um desafio e tanto, imagino que quem já teve que passar por isso por muitas vezes (Alô Paulão!), sabe do que estou falando... []s Marcílio Aproveitando o assunto e ótimo texto do Ventura….

Quando falamos de refactoring de componentes de caixinha, pensamos no update de versão do componente para os sistemas em produção que o utilizam.

Embora seja o ideal, sob ponto de vista de gerenciamento dos componentes e controle de qualidade, isso pode muitas vezes não ser atrante, e nem ser justificável para os projetos.

O que tenho percebido é que, de boa vontade, os sistemas vão evoluir ou atualizar versões de componentes apenas para duas situações:
-1) evoluções que de fato impactem diretamente na utilização do componente no sistema (performance, por exemplo).
-2) correção de defeito :-)

O sonho do grupo de componentes em manter todos os usuários usando as mesma versão do componente é um desafio e tanto, imagino que quem já teve que passar por isso por muitas vezes (Alô Paulão!), sabe do que estou falando…

[]s
Marcílio

]]> By: Paulo Camara http://www.aqueleblogdesoa.com.br/2008/08/evolucao-de-componentes-e-servicos/comment-page-1/#comment-211 Paulo Camara Fri, 15 Aug 2008 12:08:58 +0000 http://aqueleblogdesoa.wordpress.com/?p=319#comment-211 Deixa eu só fazer um comentário aqui sobre o lance do refactoring em métodos ágeis. Sim, Fábio, você está certo: os metodos Ageis pregam o refactoring como algo real e necessário. Porém, a experiência prática mostra que nenhum cliente tem dinheiro sobrando para permitir que seus sistemas (ou componentes) sofram alterações profundas e custosas de tempos em tempos. Isso não é justificável economicamente. Por isso que um bom projeto (aka design) é fundamental, independente do seu paradigma de desenvolvimento. Vejam que isso é bem diferente de tentar prever o futuro e fazer um design a prova dele. Isso, a experiência também prova que é improdutivo e ineficiente. Encontrar o meio termo é a arte de projetar sistemas. :-) []s, Paulo Deixa eu só fazer um comentário aqui sobre o lance do refactoring em métodos ágeis. Sim, Fábio, você está certo: os metodos Ageis pregam o refactoring como algo real e necessário. Porém, a experiência prática mostra que nenhum cliente tem dinheiro sobrando para permitir que seus sistemas (ou componentes) sofram alterações profundas e custosas de tempos em tempos. Isso não é justificável economicamente. Por isso que um bom projeto (aka design) é fundamental, independente do seu paradigma de desenvolvimento.

Vejam que isso é bem diferente de tentar prever o futuro e fazer um design a prova dele. Isso, a experiência também prova que é improdutivo e ineficiente.

Encontrar o meio termo é a arte de projetar sistemas. :-)

[]s,

Paulo

]]> By: joseventura http://www.aqueleblogdesoa.com.br/2008/08/evolucao-de-componentes-e-servicos/comment-page-1/#comment-213 joseventura Thu, 14 Aug 2008 13:35:16 +0000 http://aqueleblogdesoa.wordpress.com/?p=319#comment-213 Opa Fábio, Sim, tem uma relação. Tive uma experiência em projeto que era exatamente essa situação de "inchaço" de um componente. Ficamos conscientes do problema, e na época tentamos conter esse crescimento. Pouco depois fui em uma palestra de XP onde por coincidência foi mencionada a mesma situação, e realmente a abordagem ágil não é conter, mas gerenciar com consciência. Sobre extrapolar para um sistema inteiro: acredito que um refactoring desse porte, de uma vez só, teria um custo proibitivo. Por sorte, conforme os sistemas vão se tornando mais desacoplados (e temos várias técnicas para isso), os impactos vão diminuindo; justamente porque podemos fazer evoluções em partes isoladas. Opa Fábio,

Sim, tem uma relação. Tive uma experiência em projeto que era exatamente essa situação de “inchaço” de um componente. Ficamos conscientes do problema, e na época tentamos conter esse crescimento. Pouco depois fui em uma palestra de XP onde por coincidência foi mencionada a mesma situação, e realmente a abordagem ágil não é conter, mas gerenciar com consciência.

Sobre extrapolar para um sistema inteiro: acredito que um refactoring desse porte, de uma vez só, teria um custo proibitivo. Por sorte, conforme os sistemas vão se tornando mais desacoplados (e temos várias técnicas para isso), os impactos vão diminuindo; justamente porque podemos fazer evoluções em partes isoladas.

]]> By: frosato http://www.aqueleblogdesoa.com.br/2008/08/evolucao-de-componentes-e-servicos/comment-page-1/#comment-212 frosato Thu, 14 Aug 2008 12:56:37 +0000 http://aqueleblogdesoa.wordpress.com/?p=319#comment-212 Ventura, Muito bom o artigo!!! Parabéns!!! Esta estratégia de nascimento-evolução-refactoring dos componentes ou serviços parece ter relação com as práticas dos métodos ágeis, onde o refactoring de uma aplicação é considerado uma tarefa nobre e necessária. Você concorda e extrapolaria esta tática para o desenvolvimento, não só de componentes, mas da aplicação como um todo? Essa possível relação foi casual ou você se baseou nessas metodologias ágeis? abraço, Fábio Ventura,

Muito bom o artigo!!! Parabéns!!!

Esta estratégia de nascimento-evolução-refactoring dos componentes ou serviços parece ter relação com as práticas dos métodos ágeis, onde o refactoring de uma aplicação é considerado uma tarefa nobre e necessária. Você concorda e extrapolaria esta tática para o desenvolvimento, não só de componentes, mas da aplicação como um todo? Essa possível relação foi casual ou você se baseou nessas metodologias ágeis?

abraço,

Fábio

]]>