XP, XP, XP???

Estou lendo o guia prático do Extreme Programing.
Já lí sobre programação em pares, user stories etc... (devo estar lá pelo capítulo 11-12).

Foi +- por esse ponto que o autor falou que os críticos da XP diziam que ela não se preocupa com a arquitetura (o que, segundo o autor, não é verdade).

Pois bem, dei uma avançada no livro e dei uma lida no exemplo que eles mostram no final.

O que posso dizer é que realmente não vi nenhuma arquitetura ser planejada. Simplesmente, após o teste ser construído, as funionalidades eram adicionadas as classes.

Por exemplo, a classe cliente (entidade) possuia seus acessors e mutators normais (getter and setter) mas possuia também uma série de outros métodos, que incluiam até mesmo métodos auxiliares para persistência em XML.

Estou gostando muito da abordagem que a XP oferece, e muitas de suas práticas fazem bastante sentido quando o autor disserta sobre elas.

Mas... Quando lí os exemplos... cara. Realmente não concordei com a abordagem que eles usaram (quer dizer, o resultado final do sistema).

Será que não seria bom dedicar um mínimo de tempo para já se usar alguma arquitetura. Por exemplo, ter uma classe responsável por persistência e deixar as entidades apenas com os métodos get e set???

Acho que padronizar o código é muito importante (por exemplo, determinadas funcionalidades devem ser distribuídas em tais e tais classes). Dessa forma, os outros desenvolvedores já sabem onde procurar determinado trecho de código.

Não sei se estou me enganando, mas lembro de ter lido que o programador escolhe a forma de implementar a funcionalidade. Acho que isso pode desorganizar um pouco as coisas (não estou falando em que algoritmo ele usa, mas onde coloca seus métodos etc...).

Comentários? Alguém com uma maior experiência para falar do assunto? Alguém que já usou o modelo clássico e uma arquitetura em camadas e depois usou XP em algum outro projeto? Quais foram as diferenças que vocês notaram, arquiteturalmente falando?

::caraca meu português tá uma droga::

Thread.start() Membro desde: 12/08/2002 16:24:16 Mensagens: 37 Offline

quando vc realmente usa xp, todos os desenvolvedores jah concordaram sobre um "coding standard" ou seja, eles sabem ondem colocar metodos e tal, alem disso, por programar pareados, confusoes raramente ocorrem e todo mundo conhece bem o todo codigo. Collective ownership of the code, acaba com aquela historia de cada um no seu pedacao e dane-se o resto do programa, todo mundo conhece o programa inteiro.
eh muito legal, eu jah usei XP e acho que a arquitetura da aplicacao entra no jogo, e o mais legal eh que vc pode ir consertando a arquitetura ao longo do desenvolvimento! Ao usar padroes e refatorar sempre vc acaba implementando aplicacoes muito bem arquitetadas.

Mandou mto bem, Alexandre!

Eu queria so deixar bem claro aqui que nunca vai ser possivel para um livro dar enfase suficiente pra expressao "refatorar sempre". Isso eh uma coisa que, infelizmente, eu nao vejo muito por ai - tem sempre aquele programador que acha que uma vez que o codigo dele foi escrito, testado e funciona, nao deve ser mexido nunca.

Uma das maiores barreiras pra um time de XP eh a adocao imbecil do "em time que esta ganhando nao se mexe"... se mexe, sim, senhor!

Legal.

Ainda tenho uma pequena dúvida.

O livro dizia que a primeira iteração é a mais importante. Só que ele parte da perspectiva de que na primeira iteração já estamos implementando as User Stories. Só que onde entra o esforço para montar os recursos para que as funcionalidades possam ser implementadas (se, por exemplo, eu vou usar hibernate, preciso de um tempo para configura-lo, mesmo que o faça aos poucos)?

Não vi menção sobre as atividades paralelas ao desenvolvimento. Será que só devo me preocupar com elas quando sentir necessidade de tê-las?

Com o hibernate, por exemplo, posso criar uma unica classe que faça as operções básicas de persistência (inserir, excluir, deletar) para qualquer entidade do meu sistema. Ora, nada mais justo do que, antes da codificação começar, essa classe já esteja pronta. Ou então, algum desenvolvedor, quando precisar persistir, cria essa classe e comunica aos demais que existe uma classe de utilitário que pode ser reutilizada por todos.

Essa é minha dúvida. Como coordenar esse tipo de problema? Para não acontecer de várias pessoas estiverem implementando a mesma funcionalidade (lembro que o livro menciona algo sobre enxergar algumas redundâncias, mas diz para não se preocupar com elas no momento)?

Enquanto escrevia esta mensagem me lembrei de algo. As reuniões diárias em pé. Segundo o livro, com elas, os desenvolvedores estão, no máximo, um dia desatualizados.

Será que são nessas reuniões que se descobre que dois desenvolvedores estão fazendo uma classe de utilitário que faça a mesma coisa? Detectado então o problema, eles se juntam aos pares, implementam a classe e descartam a outra?

Ainda acho melhor ter uma análise um pouco mais profunda para detectar esses pontos. Ou posso estar enganado e, mesmo deixando esses problemas para serem descobertos e refatorados depois, o projeto possa ser entregue sem problemas...

Elvis.The.Pelvis wrote:Não vi menção sobre as atividades paralelas ao desenvolvimento. Será que só devo me preocupar com elas quando sentir necessidade de tê-las?

Nao existem atividades paralelas ao desenvolvimento, em XP...

Se vc esta desenvolvendo um software, entao eh isso o que vc esta fazendo!

Pegando o seu exemplo do Hibernate, por exemplo, aqui vai um dialogo que pode ocorrer (Dn = desenvolvedor N, C = cliente, G = gerente do projeto)

D1: Precisaremos salvar os dados em uma base de dados?
C: Sim, claro!
D2: Qual?
C: Por enquanto, MySQL, mas eu quero migrar pro Oracle mais pra frente...
D1: Otimo, entao a gente vai usar JDBC.
D2: Melhor, pq a gente nao usa alguma ferramenta pra simplificar a coisa?
D1: Beleza, usemos Hibernate, entao?
D2: Parece uma boa...
G: Ta bom. Antes de bater o martelo no Hibernate, aqui vai uma User Story: Tornar os objetos do sistema persistentes em um banco de dados. Inicialmente MySQL, futuramente Oracle.

No dia seguinte...

D1: Bom, fiz um pair com o D2 e a user story de persistencia foi resolvida com o Hibernate. A gente criou uma classezinha pra ajudar a persistir os dados usando Hibernate e gerenciar as Sessions. Ta' la' no CVS, o nome dela eh HibernateHelper.

D3, D4, D5, D6... D10: Opa, vamos usa-la entao!

No dia seguinte...

D3 e D4: A gente teve umas ideias pra deixar a HibernateHelper mais generica, assim a gente pode usar ela na nossa user story tambem. Ja atualizamos o codigo, mas a gente precisa que vcs atualizem as suas chamadas.

D1, D2, D5, D6... D10: Beleza...

E assim vai...

Era como eu imaginava...

Caraca esse XP me parece porreta mesmo :D.

Ei e o livro que eu estou lendo fala sim de refactoring o tempo todo.

Teste, Implemente. Tarefa pronta, refatore.

Vai começar nova tarefa, refatore novamente para melhorar o código para a nova funcionalidade.

Teste, implemente. Tarefa pronta, refatore.

Vai começar nova tarefa, refatore novamente para melhorar o código para a nova funcionalidade...

E por ai vai :D.

A bronca é que vc nunca consegue aprender um processo só por livros. Queria ler alguns casos de sucesso, como eles se desenrolaram, antes de começar a usar por aqui na empresa.

Bom, ja' que vc e' de Recife (esse "porreta" que vc soltou te denunciou completamente

), procure trocar uma ideia com o pessoal do CESAR. Eles estao usando XP com bastante sucesso, pelo que eu sei

Eheheh

Vou levar um papo com Júlio Lins. Ele já trabalhou na Qualiti. deve saber algo sobre...

Valeu galera

[]s

Recife é arretado de bom ;)

Thread.start() Membro desde: 12/08/2002 16:24:16 Mensagens: 37 Offline

Oi, foi a galera de XP que inventou os wikiwikis, e no wikiwiki original tem um monte de coisa legal sobre XP se vc quiser viajar um pouco, soh que tah tudo em ingles:

http://www.c2.com/cgi/wiki?ExtremeProgramming

Valeu pela dica. Sem bronca ser em inglês. Essa semana vai ter um workshop na Universidade Federal de Pernambuco sobre Agile Modeling.

Vão vir uns gringos palestrar. Após assistir as palestras, posto o que achei sobre elas aqui.

Virtual Machine Man Membro desde: 21/08/2002 03:53:28 Mensagens: 661 Offline

Bela história sobre um caso de usar Hibernate. Mas imagino que a coisa aconteca um pouco diferente.

primeiro que por mais que o pessoal tenha se reunido e discutido, a primeira implementacao de persistencia vai ser fake. Em vez se um HibernateHelper, acho muito mais provável ter um PersistenceManager que vai ser bem fake e vai serializar o objeto em um arquivo e pronto. Mais pra frente, na hora que nao for mais necessário ficar refatorando e mexendo em todos os objetos, é bem mais fácil enxergar os verdadeiros requisitos da camada de persistencia. Quem sabe a idéia inicial de implementar com hibernate nunca seja utilizada, porque

1. Apareceu uma tecnologia OR nova muito mais adequada para a aplicacao.
2. A implementacao fake com serializacao funciona tao bem que venceu a necessidade de um banco de dados.
3. Pelas recentes discussoes com o cliente, uma abordagem com Prevayler (ou equivalente) é muito mais interessante

Bom, vai saber quais as razoes, mas sempre existe a chance da sua idéia inicial mudar, e se vc nao gastou muita energia pra fazer bonito logo de cara, melhor.

[]s!!

P.S. Muito bom o link, Alex, nunca tinha lido esse...

Mermão. Pode até ser. Mas veja bem, o trabalho para colocar o hibernate funcionando é tão pequeno que é melhor começar por ele mesmo.

Afinal, session.save() e oos.writeObject() são bem semelhantes não acha (em questão de esforço)?

Claro que se você estivesse usando SQL na mão, você poderia retardar a implementação até quando ela fosse realmente necesária. Mas acho que no caso do hibernate o overhead é pequeno e dificilmente surgirá outra coisa que possa ser usada no lugar dele, e apresentar vantagens, durante o trasncorrer do projeto (calma, veja a explicação abaixo ;)).

Qualquer coisa nova que surja durante o desenvolvimento do projeto provavelmente ainda estará em versão beta, ou o projeto já está tão avançado que não valha mais a pena mudá-lo. E existe ainda o tempo de aprendizagem da nova tecnologia. Você poderia deixar as novas tecnologias para novos projetos.

E, afinal de contas, o cliente não se importa como você implementou a funcionalidade, desde que ele saia satisfeito com o produto.

Elvis.The.Pelvis wrote:Qualquer coisa nova que surja durante o desenvolvimento do projeto provavelmente ainda estará em versão beta, ou o projeto já está tão avançado que não valha mais a pena mudá-lo.

Concordo com todo o resto do post, mas, segundo a pratica do XP, se tem alguma user story que torna o Hibernate invalido, so ai vale a pena...

Eu sabia que isso ia causar um pouco de confusão. Eheh. Mas já tinha pensado na resposta. Esqueci de mencionar que essa é a visão do desenvolvedor. Lógico que se os requisitos mudarem, você deve mudar sua implementação. Só que agente sabe que, pelo menos na grande maioria das aplicações (comerciais pelo menos), mudanças nos requisitos não impactam no framework escolhido para persistência.

Mudando de assunto.

Então, por que simples ao invés de flexível? (http://www.xispe.com.br/wiki/wiki.jsp?topic=SimplicityKey)

Caramba, realmente parece que a filosofia do XP é "não pense no futuro, não desenvolva frameworks que suprirá todas as suas necessidades, simplesmente coloque o código para rodar".

É por isso que XP causa tanta comoção. Eu mesmo, como desenvolvedor, tendo a procurar soluções brilhantes em vez de simples, sempre querendo implementar uma grande funcionalidade/framework ao invés de mandar ver nos "INSERTS". Afinal, o desafio é o que me mantém trabalhando com informática.

Gostaria de trabalhar com XP. Tudo que falo aqui é mera especulação e tenho certeza que minha visão mudará drasticamente após usar XP na prática.

Por enquanto, a aplicação da teoria nos projetos que participo hj é muito divertida. Estamos lidando com dezenas de problemas de projeto que o XP aponta. E eu sempro digo: "Segundo o XP...". Eheheh o pessoal já ta ficando de saco cheio :D.

a ideia do XP não é você não desenvolver um framework para XXX
e sim, você desenvolver um framework quando for precisar dele, e mesmo assim, faça o framework da maneira mais simples possivel, e depois va melhorando ele de acordo com as suas necessidades.

por exemplo:

vamos precisar de um framework de persistencia.
ok, vamos desenvolver um.
o que contem o framework de persistencia?
controle da persistencia, transações, uma linguagem de colsulta, ....
OK, mas disto, o que vamos precisar agora??
só salvar e carregar os objetos, o resto só vai ser utilizado na proxima faze do projeto.
OK, então desenvolvemos apenas a persistencia agora e depois implementamos o resto.

acho que é mais ou menos isto

Notícias, artigos e o maior fórum brasileiro sobre Java