Diferenças entre Arquitetura de Projetos

E onde diabos há semelhança entre construir um software e construir uma casa?

Renatov wrote:
Saudações a todos ... acho realmente interessante os argumentos "extremistas".

Me pergunto sempre se os desenvolvedores XP, quando um dia pensarem em construir as suas casas ou reformar um apto irão usar das mesmas heurísticas.

Diriam eles ao pedreiro (já que não precisam nem de Arquiteto ou Engenheiro) ... "Bota a parede ai mesmo, e não precisa se preocupar com colunas. Se até o final da obra eu resolver fazer o segundo andar da casa, vocês quebram tudo (quer dizer, fazem um refactoring) e constroem tudo de novo."

Abraço.

Acredito que os programadores em geral tem um poquinho mais de estudo que os pedreiros em geral (nada contra eles).

Enfim, são tarefas totalmente diferentes

Me pergunto sempre se os desenvolvedores XP, quando um dia pensarem em construir as suas casas ou reformar um apto irão usar das mesmas heurísticas.

Há casas e casas.

Boa parte dos projetos que são descontinuados(ou desencorajados) possuem um dito "Arquiteto de Software" por trás dele.Quer bagunçar um projeto?Taca zilhões de métricas,CMM, uns medalhões(de preferência alguém fera em Análise Essencial e Estruturada que acha que AOO é uma tolice e pode projetar 'qualquer coisa' com seu conhecimento).
IMHO, um Arquiteto de Software seria mais uma posição, tipo um indivíduo com + de 5 anos de programação e desenvolvimento de muitos projetos.O Arquiteto apenas como um projetista, um engenheiro, a meu ver é um erro, que pode prejudicar muito um sistema.É como um técnico esportivo de natação que nunca nadou.Existem bons, mas são muito raros...

What is classpath? Membro desde: 29/01/2007 13:50:25 Mensagens: 8 Offline

Olá.

Realmente essa é uma discussão a lá religião, futebol e mulher. Gera sempre muita polêmica e está recheado de opiniões diversas. Graças a Deus pois a unanimidade é burra.

Bom, fiz analogia a Engenharia Civil devido a nossa área ser a Engenharia de Software (acredito que não foi a toa que qualificaram assim).

O XP é um processo de desenvolvimento que tem os seus méritos e seu valor, mas como diria o Ministério da Saúde: "Aprecie com moderação". Não acredito que ele seja a solução para todos os casos como alguns radicais insistem em apregoar.

Entendo que o XP seja uma boa solução para projetos de pequeno porte e com equipes reduzidas. Principalmente para equipes "in-house" onde o usuário tem a "porta aberta" na área de TI, sem se preocupar com orçamentos, riscos, prazos apertados, tecnologias heterogêneas e em primeiro lugar, em ter os seus requisitos bem definidos. Nessa situação realmente fica fácil iniciar o desenvolvimento de um sistema, e ir adicionando e/ou modificando as funcionalidades durante o decorrer da programação.

Entusiasta Java Membro desde: 03/10/2006 22:07:36 Mensagens: 16 Offline

Aí galera... só para finalizar esse tópico.
Andei pesquisando e achei dois pdfs.
Para quem se interessou pelo assunto recomendo a leitura

segue os links:
www.ime.usp.br/dcc/posgrad/teses/ane.pdf
www.rise.com.br/wdbc2006/apresentacoes/terca/arquitetura_e_DBC.pdf

Realmente arquitetura é definida de acordo com a exigência de comportamento da aplicação, como integração, disponibilização dos componentes de negócio como serviço, se vai haver ou não negócios orquestrados por regras de negócio e workflow - BPM e por aí vai.

Então CV é difícil colocar todas as necessidades dos clientes como algo comum, que pode ser resolvido com qualquer framework RoR por exemplo da vida.

Quero ver projetos de alta-criticidade, com loadbalance, cluster, assíncrono funcionando sem planejamento.

[]´s

Kenobi wrote:Quero ver projetos de alta-criticidade, com loadbalance, cluster, assíncrono funcionando sem planejamento.

Engraçado ver que ainda existem pessoas que acreditam que não existe planejamento em processos ágeis. Todos os processos ágeis que eu conheço fazem reuniões de planejamento pelo menos semanais, quando elas não são diárias.

A grande diferença é que nós planejamos durante todo o projeto, porque sabemos que o nosso trabalho é entregar software que funciona, não fazer previsão do futuro.

Quanto maior a altura, maior a queda

Maurício acho que o problema que mesmo lendo um monte de artigos, tutoriais, cases, etc, sempre existe o dilema de São Tomé. Sem contar q as pessoas em geral são status quo, então não adianta falar, o ideal seria ver e participar de uma projeto assim, mas aí vira um círculo vicioso, não faz pq não tem experiencia e não tem experiencia pq não faz .. e ainda por último mesmo q tente sem experiência, e no caso de errado, para muitas pessoas uma experiência negativa só é vista pelo lado negativo...

Maurício Linhares wrote:

Kenobi wrote:Quero ver projetos de alta-criticidade, com loadbalance, cluster, assíncrono funcionando sem planejamento.

Engraçado ver que ainda existem pessoas que acreditam que não existe planejamento em processos ágeis. Todos os processos ágeis que eu conheço fazem reuniões de planejamento pelo menos semanais, quando elas não são diárias.

A grande diferença é que nós planejamos durante todo o projeto, porque sabemos que o nosso trabalho é entregar software que funciona, não fazer previsão do futuro.

Quanto maior a altura, maior a queda

Não estou falando que não há planejamento. Mas uma coisa é bem diferente, no processo ágil vc faz de acordo com as iterações e entregas.
Dependendo do escopo do projeto , o tempo gasto com refactoring será 50% do tempo da construção - adicional.

Como disse anteriormente, depende do projeto. Gosto de processo ágil, principalmente onde os itens de influência são baixos, e o mesmo está muito mais atrelado à desenvolvimento de negócio, do que infra-estrutura.

What is classpath? Membro desde: 29/01/2007 13:50:25 Mensagens: 8 Offline

Se é por ter experiência em projetos ágeis, já trabalho a quase 3 anos em projetos orientados a XP. Daí posso falar por vivência própria e não por leituras curiosas de artigo.

O Kenobi citou muito bem quando falou sobre refactorings. Isso pra mim é um dos grandes engodos do XP. Você sai acreditando que pode produzir produtos rapidamente e que possíveis distorções possam ser corrigidas com o tempo. Se vc está falando que o teu usuário pediu um ou dois campos a mais ou mesmo uma nova funcionalidade, pode até funcionar. Mas por favor não erre no seu design, as consequências são amargas. Você pode chegar no meio do caminho e perceber que a solução imaginada na primeira iteração, quando o meu foco da lanterna era muito fechado, não foi robusto suficiente para suportar as novas iterações e as funcionalidades decorrentes. Por exemplo, um problema que deveria ser solucionado por uma simples agregação, pros pares das primeiras iterações foi resolvido por herança. Vamos então dar uma de Dr. Frankstein (ou seria Dr. Pitangui) e criar o nosso monstro através de refactorings (famoso bisturi e agulha).

É claro que tudo isso tem a ver também com a experiência dos "programadores". Mas sem ter uma visão do "todo", como eu poderia crucificar os pares das primeiras iteração por terem adotado uma solução que não foi a melhor. Ainda mais por confiarem plenamente no "bisturi".

Infelizmente a realidade pode ser mais amarga e a "emenda sair pior que o soneto".

Volto a dizer: acho que podemos ter desenvolvimentos ágeis sem abrir mão de um boa definição de escopo e um bom design. Existem qualidades que podem ser mescladas e podemos colher frutos de um processo misto e que alcance um ponto de equilíbrio.

Defina "processos orientados a XP". Formalmente isso não existe.

Refactoring não envolve melhorias funcionais mas sim de design. Se você criou um Frankestein é porque simplesmente não fez refatoring, para começar. Acho que o conceito não está muito claro.

Isso tudo não 'tem a ver' com a experiência (na verdade, qualidade) dos programadores, ela simplesmente é decorrente desta.

Bom design não tem a ver com BDUF. Até a IBM já aprendeu isso, não é a toa que contratou Scott Ambler.

pcalcado wrote:Bom design não tem a ver com BDUF. Até a IBM já aprendeu isso, não é a toa que contratou Scott Ambler.

[sendo irônico]
Ah, mas não é BDUF, é só um pouquinho de design antes do projeto começar. Sabe, aquele pouquinho que agente fica imaginando que o mundo é perfeito, que os sumarinos são amarelos e que nós conhecemos todos os cenários que as ferramentas que nós usamos passam.

[deixando de ser irônico]

Em um projeto recente, queriam um diagrama de classes, era pra fazer uma abtração sobre toolkits gráficos (web e desktop, a idéia é escrever uma única aplicação que rode nos dois ambientes). Queriam diagrama do diabo a quatro. E aí?

E aí que da idéia inicial, nem a idéia sobrou. A implementação foi mais uma prova que imaginação demais e pouco código rodando é só isso. Imaginação demais.

Se você não tem testes nem código, não tem nada. Já passou a época em que computadores operavam consumindo cartões de papel

What is classpath? Membro desde: 29/01/2007 13:50:25 Mensagens: 8 Offline

pcalcado wrote:Defina "processos orientados a XP". Formalmente isso não existe.

Se vc puder ler novamente lá está "projetos orientados a XP". Formalmente "processos orientados a XP" realmente seriam o máximo.

Mas em tempo corrigido pelo pcalcado, realmente errei em dizer que uma mudança de requisito é um refactoring. Thanks.

JavaEvangelist Membro desde: 27/03/2006 11:11:34 Mensagens: 391 Offline

Questionamento aos eXtremes de plantão!

Evoquei meu livro aqui de XP e realmente não vi nenhuma menção a projeto preditivo. O lema é projeto so com refatoração! Só vale projeto adaptativo! Nada de pensar no futuro em danadinhu!

Mas na realidade será que vcs não pensam nem um pouquinho no futuro? Tudo começa com uma classe sem coesão, as refatorações vão rolando, outras classes vão sugindo, tudo vai melhorando...

Não acho que as coisas rolam de forma tão extrema assim! A meu ver se fosse tão extrema deveria rolar assim, voce deveria realmente começar com uma classe e ir refatorando. Mas como vejo que as coisas não rolam assim ainda acho que tem projeto preditivo ai no meio!

Ou será que as coisas rolam assim?

[]s

What is classpath? Membro desde: 29/01/2007 13:50:25 Mensagens: 8 Offline

... aproveitando e concordando com o Maurício, realmente "software sem código não é software" e software que não possue um conjunto de testes não pode nem sair do ambiente de desenvolvimento. Os testes são um dos meios efetivos para se comprovar a não conformidade de um produto mas não o meio de "garantir a sua qualidade". Um bom exemplo de garantia da qualidade é a programação em pares.

O fato da IBM ter desenvolvido e apostado no OS2 comprovou que nem sempre ela acerta. A ida do Scott eu encaro muito mais como o aproveitamento de boas práticas (incorporação) do que uma mudança radical, desprezando o passado. Realmente não tenho acompanhado de perto para ter essa certeza mas não me parece uma atitude típica da Big Blue.

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