Olá Pessoal!
Muito legal a discussão! Nos últimos 2 anos tive a oportunidade de participar e contribuir com a comunidade de padrões nos eventos SugarLoafPLoP 2008 aqui no Brasil e do PLoP nos EUA (onde Raph Johnson e outros grandes nomes estavam presentes). Esse tipo de discussão ocorre bastante nessa comunidade. Para os interessados acredito que vale a pena dar uma olhada nos artigos dessas conferências e tentar comparecer nos próimos eventos!
[]s
Pode ser na sua estrategia waterfall porque ela exige saber de antemao quais são todos requisitos e todos os padrões que existem pra chegar numa solução.
Mas refactoing não é suicidio pra quem planeja baseado em iterações curtas, pelo contrario, é uma pratica essencial porque permite os developers se familiarizarem com o domínio e por conta disso evitar erros na implementação (ou modelo, dá no mesmo). Se vc acha que refactoring é prejudicial deveria ler mais sobre metodologias ageis como XP, Scrum aplicado a projetos reais.[/quote]
haha alias, mochuara, olha so que lugar legal pra se ler alguma coisa sobre metodologias ageis como XP, Scrum:
http://sergiotaborda.javabuilding.com/category/planejamento/
opa, olha quem escreve o site 
[quote=Guerr@]Olá Pessoal!
Muito legal a discussão! Nos últimos 2 anos tive a oportunidade de participar e contribuir com a comunidade de padrões nos eventos SugarLoafPLoP 2008 aqui no Brasil e do PLoP nos EUA (onde Raph Johnson e outros grandes nomes estavam presentes). Esse tipo de discussão ocorre bastante nessa comunidade. Para os interessados acredito que vale a pena dar uma olhada nos artigos dessas conferências e tentar comparecer nos próimos eventos!
[]s
[/quote]
Bom, gostaria de saber quais seriam as suas observações já que você Guerra é um conhecedor também sobre o assunto.
; )
Recomendo sempre o Blog e o Site também Javabuilding do Sérgio Taborda, tem um ótimo conteúdo e um bom trabalho na certa.
Bem, acho que estamos num fórum profissional, e eu não deveria estar falando aqui que gambiarra não faz parte de um processo de desenvolvimento sério. Mas, se você acha necessário, já deixo claro, “programar orientado a gambiarra não faz parte de qualquer desenvolvimento sério”. Nesse caso, concordo com você. A técnica pode até funcionar (já que o refactoring efetivamente vai corrigir a gambi), mas certamente será um desperdício hercúleo de tempo e recursos.
Pouco tempo depois que você postou, percebi pq estamos em atrito. Na verdade, é um problema de terminologia. Tailoring, é um ajuste do modelo. A diferença é que o tailoring é um ajuste baseado numa mudança de requisito e pode, efetivamente, alterar o comportamento observável do software.
Falando no modelo, de maneira ampla, concordo parcialmente com você. Refactoring do modelo, ou mesmo o tailoring, geralmente representa mesmo um erro de modelo. Só não creio que erros de modelo possam ser evitados. Daí a importância do ciclo iterativo, onde encaramos erros como parte do processo (e, consequentemente, em muitos processos assim, deixamos de chamar os erros de erros). Parte disso, não é necessariamente falha da análise de requisitos.
O fato é que os usuários não entendem de software, e é só depois das primeiras releases que eles começam a ter uma visão melhor do que o software será, e do que eles podem ou não podem requisitar. Muitas vezes, a implementação gradual faz com que o usuário repense até mesmo o seu processo, e conceitos que ele tinha como importantes anteriormente passam a ser refeitos ou completamente abandonados, outros requisitos surgem. Já vi isso acontecer em todos os sistemas de maior porte que trabalhei.
Um exemplo disso é que já vi o modelo waterfall funcionar supreendentemente bem em sistemas de engenharia, onde o usuário tem uma noção exata do que o software será e que requisitos ele deve atender. Mesmo quando um modelo mais iterativo foi adotado, ele possuia poucas mudanças, quase nenhum retrabalho, e quase nenhuma re-analise de modelo. Não estou falando só de sistemas pequenos e específicos, mas de sistemas grandes, como os presentes em centrais telefônicas.
Exactamente. Erros do modelo não podem ser evitados, mas essa frase pressupõe que existe um modelo.
O meu ponto é que um modelo não nasce ad doc. Existe um ponto de partida que foi modelado antes do iniciar a implementação antes do sprint 1. Este modelo vai mudar, mas ele existe. quanto mais cuidado foi colocado na sua modelagem,menos alterações serão necessárias depois.
(P.S. eu disse “cuidado” não esforço ou detalhamento)
Básicamente, quanto melhor for a versão zero do modelo, menos ele será alterado. E como torná-lo melhor logo de inicio ? usando patterns. Esse é o meu ponto. Patterns é um catalizador para ter um modelo zero melhor. Não só isso,como para facilitar as futuras alterações que já sabemos irão existir.
Pagina 31 - Revista Mundo Java - Edição nº 33
Quando é difícil refatorar
“Existem alguns casos em que a refatoração se torna algo difícil de ser feito, e em sua grande maioria devido a um alto grau de acoplamento entre partes da aplicação.Quando a refatoração a ser feita envolve banco de dados, principalmente quando o mesmo é utilizado em mais de uma aplicação, a situação se complica.O acoplamento da aplicação com a estrutura do banco acaba sendo bem alto, e esta dependência dificulta a refatoração.”
“Pensei nisso antes ou depois do modelo, ou isso pouco importa”
Olá
Minha experiência com sistemas de engenharia vai desde sisteminhas pequenos até projetos de CAD de mais de 5 anos e mais de 5 milhões de dólares.
Acho que defendo o desenvolvimento por trial and error muito antes de alguém ter escrito algum livro sobre desenvolvimento iterativo.
Desenvolvendo sistemas de engenharia já passei por caso em que fiquei 1 mês, repito um mês inteiro tentando fazer funcionar e provar que funcionava uma única fórmula. Meu método de trabalho sempre incluiu desenvolver protótipos para testar o funcionamento do modelo imaginado e muitas e muitas vezes fui obrigado a alterar completamente o modelo porque justamente os testes não deram certo.
Não se esqueçam que as contas em um sistema de cálculo científico são MUITO mais complexas do que qualquer programinha de controle de estoque e faturamento que não passam de contas de somar e diminuir. Antes que algum desavisado me jogue pedras aviso que passei 6 anos da minha vida vivendo de sistemas de controle de estoque, faturamento e outras continhas de somar a mais.
Modelar um sistema na rocha e sair programando sem poder alterar o modelo me parece bem ruim. Talvez sirva para algo bem simples. Mas por exemplo para o Flickr não serviu. Como todos os sabichões daqui devem saber, os caras estavam desenvolvendo um joguinho que incluia um gerenciador de imagens. Em dado momento jogaram tudo fora e passaram a se dedicar somente ao que depois virou o Flickr.
Minha experiência com sistemas que foram modelados completamente errados e depois precisaram ser modificados não me convencem que exista algum Deus poderoso que consiga acertar sempre logo de cara. Falo isto tanto para o código como também para o modelo. E vou além. Acho raro encontrar casos em que o que o cliente pediu foi entendido 100% corretamente pelo arquiteto de software. Há sempre uma boa margem de falha.
[]s
Luca
Bom, eu realmente não esperava que o que falei valesse para todo e qualquer sistema de engenharia. Realmente, se você tem sistemas onde os cálculos terão de ser desenvolvidos no processo, fica difícil que funcione no modelo waterfall.
No caso, eu trabalhei 6 anos com sistemas de telefonia. Os padrões eram bem definidos, já havia bastante conhecimento de boa parte do processo, já que diversas centrais similares já haviam sido desenvolvidas ao longo dos anos.
Novamente, vale ressaltar que o desenvolvimento não era 100% waterfall. Acho que ninguém hoje em dia é louco de achar que vai fazer tudo num tapa. Mas era bem longe de ser considerado ágil, até porque parte do software estava em firmware, e dependia de um projeto de hardware para funcionar. E o custo para alterar isso, é altíssimo.
[quote=André Fonseca]Pois é
[/quote]Isso é um conceito que hoje pode ser pouco aceitável, já existem protótipos para produzirem ambiente de aceitamento ou não, veja a ferramenta http://www.tersus.com/ e procure ver onde você faz a refatoração, a tecnologia é decisiva na hora de projetar software.
O ponto é bem aqui (negrito adicionado por mim).
Ninguem está degladiando experiencias. O ponto é muito simples : iterações de processos ageis não são trial and error.
Trial and error (TE) é feito repetidamente, iterações são feitas repetidamente, mas a semelhança acaba ai: na divisão temporal.
E nem sequer ai porque TE só é refeito quando se descobre erro, enquanto agilidade tem iterações pré-programadas.
O que descreveste é mais perto de TDD onde por teste o modelo é evoluido. Em TDD não ha preocupação com padrões ou sequer com OO porque - em tese- essas coisas não serão necessárias. TDD objetiva encontrar a minima solução que satisfaz os testes.
Agilidade, iteração agil, sprint, não é isso. Iteração agil é ter um conjunto de tarefas pré-defenidas e executá-las. Tão simples assim. Acontecem imprevisto, claro - chamados impedimentos - mas não são esperados. A evolução não é baseada em encontrar erros como em TE. Quando se diz que o modelo é feito iterativamente significa que ele é implementado iterativamente, mas o modelo já existe ha priori. O modelo faz parte da propria definição do projeto, do backlog e afeta diretamente as estimativas. O modelo mode ser modificado, mas isso para atender a novos/diferentes requisitos ele não é mudado sem novos requisitos apareçam. Esta é a diferença. Em Trail and erros os requisitos são fixo, e o modelo evolui até satisfazer todos. Em agilidade o modelo satisfaz todos os requisitos conhecidos de começo.
Agora vc fala que é impossivel ter uma epifania para encontrar esse modelo primogénito. Aceitando que isso é verdade, é por isso que existem tecnicas como TDD que são usadas antes de planejar as iterações ( aquilo que se chama iteração zero). Em agil vc pode alocar quantos sprints quiser para achar o modelo que statisfaz todos os requisitos conhecidos, mas para cada sprint vc terá uma meta a alcançar. Apenas Scrum - porque é um processo que sublinha muito fortemente foco é que vc é obrigado a entregar funcionalidade demonstrável a cada sprint. Neste mecanismo vc tem no máximo 1 sprint para conseguir o modelo e algo outro algo que seja demonstrável. por isso é muito preferivel usar o sprint zero (Planning Metings) para polir o modelo ao máximo. E note que isto é feito por todos os participantes não apenas o implementador.
Num sistema cientifico o modelo é dado pela própria ciencia da coisa e o software atua apenas como um teste “unitário” desse modelo. Se o software está sendo usado para encontrar um modelo cientifico desconhecido então está sendo feita a exploração do modelo e não do software. Ou seja, não estamos lidando com um projeto de software como produto.
O ponto importante é que iterações ageis não são tentativas e erros. São coisas bem planejadas baseadas em coisas bem planejadas. Nada é ad doc.
Nao entendi o que voce quis dizer com polir o modelo ao maximo, pode exemplificar? Essa frase me passou a nitida impressao de waterfall.
Quando voce diz polir, voce diz implementar as funcionalidades o mais completo possivel e depois usar UI e infra estrutura para demonstrar o que foi implementado? Ou voce diz, debater e desenhar até ter bem definidas as funcionalidades e só entao implementar?
Pode ser na sua estrategia waterfall porque ela exige saber de antemao quais são todos requisitos e todos os padrões que existem pra chegar numa solução.
Mas refactoing não é suicidio pra quem planeja baseado em iterações curtas, pelo contrario, é uma pratica essencial porque permite os developers se familiarizarem com o domínio e por conta disso evitar erros na implementação (ou modelo, dá no mesmo). Se vc acha que refactoring é prejudicial deveria ler mais sobre metodologias ageis como XP, Scrum aplicado a projetos reais.[/quote]
haha alias, mochuara, olha so que lugar legal pra se ler alguma coisa sobre metodologias ageis como XP, Scrum:
http://sergiotaborda.javabuilding.com/category/planejamento/
opa, olha quem escreve o site
[/quote]
O que tem de legal sobre agile la não sei, e confesso que não sinto motivado em ler sobre metodologias ageis num blog de alguém que diz ser suicidio fazer refactoring.
[quote=YvGa][quote=sergiotaborda]
Agora vc fala que é impossivel ter uma epifania para encontrar esse modelo primogénito. Aceitando que isso é verdade, é por isso que existem tecnicas como TDD que são usadas antes de planejar as iterações ( aquilo que se chama iteração zero). Em agil vc pode alocar quantos sprints quiser para achar o modelo que statisfaz todos os requisitos conhecidos, mas para cada sprint vc terá uma meta a alcançar. Apenas Scrum - porque é um processo que sublinha muito fortemente foco é que vc é obrigado a entregar funcionalidade demonstrável a cada sprint. Neste mecanismo vc tem no máximo 1 sprint para conseguir o modelo e algo outro algo que seja demonstrável. por isso é muito preferivel usar o sprint zero (Planning Metings) para polir o modelo ao máximo. E note que isto é feito por todos os participantes não apenas o implementador.
[/quote]
Nao entendi o que voce quis dizer com polir o modelo ao maximo, pode exemplificar? Essa frase me passou a nitida impressao de waterfall.
Quando voce diz polir, voce diz implementar as funcionalidades o mais completo possivel e depois usar UI e infra estrutura para demonstrar o que foi implementado?
[/quote]
Cruzes!! Não! Achei que todo o mundo soubesse que “modelo” sempre é conceptual. Falha minha.
[quote]
Ou voce diz, debater e desenhar até ter bem definidas as funcionalidades e só entao implementar?[/quote]
É mais por ai, debater e desenhar até que o modelo acomode as funcionalidades conhecidas.
Mas o ponto é o que significa na sua frase: “bem definida” ?
Em agil é comum ouvir o termo “well enought” (bem o suficiente). O que isto significa?
Significa que vc tem o modelo que atende os seus requisitos com o menos esforço possível. Mas isso não significa ser preguiçosos. Significa abstrair as coisas a um ponto que a programação é trivial.
Por isso que eu disse polir e não especificar.
VC sabe que todo e qualquer modelo que fizer será um modelo cru, que terá que ser melhorado. Mas isso não é desculpa para começar com um pedragulho de 2 tonelas e ir esculpindo com uma agulha.
Vc quer alterá-lo o menos vezes possivel ou seja, cada alteração tem que ser a mais eficaz possível.
Por exemplo, estamos fazendo um sistema de ERP e temos o modulos financeiro para fazer. Quem é o idiota que não usara o padrão de conta para modelar contas financeiras ? Simplesmente não faz sentido começar do zero com um modelo de entidades à toa para daqui a cinco anos descobrirmos por tentantiva e erro que o modelo de conta é o melhor para modelar este tipo de dominio. Estamos fazendo um sistema e-comerce que precisa atender um milhão de pessoas por dia. Quem vai ter a ideia de usar session para controlar os dados do usuário ? Clusterirzar session ? sim, claro, os constainers fazem isso, mas é muito melhor não precisar de fazer clustereização de session. Trabalhar com numeros e usar double? Todo o mundo já cansou de dizer que não é para usar double! A desculpa esfarrapada do costume :" … usamos double porque não necessitamos de muita precisão… " o que raios isso sequer signifca ? Ou pior ainda “usamos double porque é mais rápido que BigDecimal”…
Existem erros graves que vc pode cometer facilmente que podem facilmente ser retirados do modelo numa fase muito pre-liminar. Aplicar boas práticas e patterns é uma forma simples e rápida… bom, ok, não é simples, mas é rápida- de polir o modelo. Estamos falando de algumas horas , não dias. Estamos falando de juntar toda a equipa e sincronizar o que cada um pensa e o que pode trazer a mesa.
O exemplo muito tipo de falta de polimento é trabalhar com grandes massas de dados. O programador que caiu no conto da refactoração mágica e pensa que se retorar um List pode mandar quantos objetos forem precisos. Até que lhe aparece um OutofMemoryError na cara e ele fica desesperado e vem no GUJ perguntar como aumenta a memoria. Ai mandam-o fazer um profiling… o erro era claro do inicio. Se é preciso lidar com muitos dados List não fai dar. Pelo menos não ArrayList … o padrão Fast lane precisa ser usado. Afinal , como raios vcs pensam que funciona um ResultSet ? E ele implementa List ?
Muitos padrões são óbvios pelo próprio domínio, outros pelo contexto, outros apenas se vc tem experiencia e já viu o problema antes. Mas sempre, sempre , vc pode melhor o modelo.
O sistema manipula dinheiro ? Money de cara. Sem conversa. Não vamos perder tempo usando BigDecimal , DOuble ou double , ou pior , float, porque “o nosso sistema não precisa de precisão” ( pun intended)
Ha erros que são muito grosseiros e isso pode ser polido logo no inicio. Coisas mais complexas vc só descobre depois, mas por razão das circustancias, não que vc fez seu modelo ser limitado de propósito e esperou ele gritar para ir lá e mudá-lo.
Polir significa conversar, experimentar o modelo conceitualmente em vários cenários (aqueles que já foram levantados que serão necessários) e modelar. Modelar é legal! OO é só modelagem. Eescrever código qualquer cara de 10 anos sabe.
Vamos deixar uma coisa clara - mais uma - se modelar fosse tão ruim, tão anti-util , se tivessemos tanto que evitar modelar, porque raios somos bombardeados com metodologia focadas em encontra o mellhor modelo ? Porque se fala de patterns ? porque se fala de bad smells, anti-patterns, boas práticas , etc… ? Será que é porque modelar é ruim ? ou será que é porque a maioria das pessoas é um mau modelador ?
Porque estariamos interessados numa segunda edição do GoF se patterns não fosse realmente util ?
[quote=sergiotaborda]Vamos deixar uma coisa clara - mais uma - se modelar fosse tão ruim, tão anti-util , se tivessemos tanto que evitar modelar, porque raios somos bombardeados com metodologia focadas em encontra o mellhor modelo ? Porque se fala de patterns ? porque se fala de bad smells, anti-patterns, boas práticas , etc… ? Será que é porque modelar é ruim ? ou será que é porque a maioria das pessoas é um mau modelador ?
[/quote]
Ninguem esta questionando modelagem, e sim o que VOCE considera modelagem. VOCE considera o modelo como algo que não é o código, mas não sabe dizer o que é alem de dizer que são “patterns” e eles irão salvar o mundo. Ao mesmo tempo vc diz que não faz BDUF, mas ta dificil ver isto como não-waterfall. (E veja bem, não tenho nada contra waterfall. O que tenho contra é chamar de Scrum o que é waterfall.)
Voce diz que qualquer garoto codifica, mas diz que não é qualquer um que modela. Qual é a sua atual definição para aqueles que modelam diretamente no código?
Se vc precisa lidar com patterns é sinal que sua linguagem falta abstrações necessarias (o que é muito comum no caso da linguagem Java). Ainda assim não acho que patterns sejam inuteis. Eles são uteis, no código da concorrência. 
Bom, quando voce diz que se trata de horas e nao de dias, nao tenho porque discordar.
Só o que eu nao pude deixar de reparar é o seu desdem por TDD, me passou a impressao que voce considera TDD o mesmo que code and fix o que nao esta nem perto da verdade. Voce poderia dizer que TDD é design and fix, aí até posso concordar, mas de todas as formas de design que conheco é de longe a mais eficaz.
Se voce precisa do fix é porque errou e se errou precisa saber disso o quanto antes, se voce tem apenas um modelo conceitual nao é possivel saber se ele é o melhor modelo possivel, porque ele é apenas conceitual, até que ele seja testado. Mas se o modelo so vai ser implementado e testado depois de “conceitualmente pronto” voce vai estar testando seu codigo, nao seu design e se seu design esta errado os testes nao vao apontar o erro.
Se estou errado sobre sua impressao de TDD, ignore meu post.
Com certeza absoluta um de nos dois tem uma definicao errada sobre modelo. Onde voce viu alguem dizer que modelar é inutil? quem disse que temos que evitar modelar? O que é dito é que a tentativa de obter projetar de ante-mao o modelo perfeito é ruim, anti-util e que temos que evitar por motivos obvios.
[quote=YvGa]
Com certeza absoluta um de nos dois tem uma definicao errada sobre modelo. Onde voce viu alguem dizer que modelar é inutil? quem disse que temos que evitar modelar? O que é dito é que a tentativa de obter projetar de ante-mao o modelo perfeito é ruim, anti-util e que temos que evitar por motivos obvios.[/quote]
Comentário perfeito! Evitar o big design up front. Tem gente contra (ou entao usam definicoes diferentes para BDUF, em quao BIG é esse B).
[quote=Paulo Silveira][quote=YvGa]
Com certeza absoluta um de nos dois tem uma definicao errada sobre modelo. Onde voce viu alguem dizer que modelar é inutil? quem disse que temos que evitar modelar? O que é dito é que a tentativa de obter projetar de ante-mao o modelo perfeito é ruim, anti-util e que temos que evitar por motivos obvios.[/quote]
Comentário perfeito! Evitar o big design up front. Tem gente contra (ou entao usam definicoes diferentes para BDUF, em quao BIG é esse B).[/quote]
Posso ate concordar que na maioria dos casos fazer BDUF pode ser prejudicial. Mas dizer que precisa ser evitado sempre seria bom vir acompanhado do porque, senão saimos de um extremo (sergiotaborda) para o outro (paulosilveira).
A verdade é que, se vc programa em Java, .NET (e outras linguagens estaticas meia boca) algum tipo de BDUF precisa ser feito. Quem não gosta de BDUF deve preferir outra linguagem pra trabalhar.
[quote=mochuara]
Comentário perfeito! Evitar o big design up front. Tem gente contra (ou entao usam definicoes diferentes para BDUF, em quao BIG é esse B).
Posso ate concordar que na maioria dos casos fazer BDUF pode ser prejudicial. Mas dizer que precisa ser evitado sempre seria bom vir acompanhado do porque, senão saimos de um extremo (sergiotaborda) para o outro (paulosilveira).
A verdade é que, se vc programa em Java, .NET (e outras linguagens estaticas meia boca) algum tipo de BDUF precisa ser feito. Quem não gosta de BDUF deve preferir outra linguagem pra trabalhar.[/quote]
Talvez seja porque sempre trabalhei num mesmo nicho de mercado (aplicacoes gerenciais) que nao consigo ver onde definir detalhes da implementacao possa ser benefico. E tambem nao creio que preciso dar exemplos, com BDUF voce esta desperdicando esforco, porque em 100% dos projetos que participei do inicio ao fim, o que se imaginava do software no inicio foi substancialmente diferente do que foi colocado em producao.
Como disse, nao sei se em outras areas projetar completamente antes de implementar é benefico de alguma forma.
O que seria bom vir acompanhado do porque sao as excecoes a regra.
