E faz 3 ou 4 dias que eu estou acompanhando. Muito boa a discussão, pq na minha opnião, o sergiotaborda consegue fundamentar bem suas opniões com argumentos. Bastente construtivo esse tópico.
Como importa? Quer dizer que padrões utilizados por engenheiros pra driblar problemas de engenharia são diferentes de padroes pra resolver problemas de negócio, modelagem, código?
De um contexto amplo, não é tudo padrão? Me explica o porquê de isso importar…
Concordo! Me expressei mal nessa frase. A situação é que o problema muda e sem um problema não existe um padrão.
Esse é o ponto que estamos divergindo Taborba. Eu compreendo teu ponto de vista à respeito de que se o problema mudou não é culpa do padrão. Na verdade, nesse aspecto, teu ponto de vista é o meu. Só discordo do ponto que tu diz que “o padrão foi mal identificado”, acho que “mal” da um significado de intenção. O fato de eu não identificar uma situação não inválida uma solução que eu tinha dado anteriormente. Apenas, neste ponto, eu tenho que me “adaptar”.
[quote]
Dê exemplos. Do ponto de vista abstrato isso não faz sentido. [/quote]
“Eu posso ser um arquiteto, descobrir como outros arquitetos la na Europa estam resolvendo problemas de engirecimento de cimento e adotar aqui. Mas de repente a solução dada lá não necessariamente será a melhor a ser usada aqui.
Pois aqui terei uma temperatura diferente, nivel do mar diferente, umidade do ar diferente, estações do ano diferentes… E por ai vai…”
Lógico que esse exemplo não invalidaria o padrão utilizado na Europa. Mas mesmo assim o padrão adotado na Europa não será usado de forma “lisa” aqui no Brasil.
Enfim, acho que não estamos se achando apenas no contexto que estamos dando às coisas…
Como importa? Quer dizer que padrões utilizados por engenheiros pra driblar problemas de engenharia são diferentes de padroes pra resolver problemas de negócio, modelagem, código?
De um contexto amplo, não é tudo padrão? Me explica o porquê de isso importar…
[/quote]
Padrões servem para resolver um problema da melhor forma. Para que isto funcione, o problema tem que ser identificado primeiro.
Problemas de dominio/negocio são mais facilmente mal identificados. Por causa disto os padrões não podem ser usados ou sequer se vê a opção de usar um padrão.
Por exemplo, ao trabalhar com dinheiro use Money. Ele facilita o problema de trabalhar com dinheiro em moedas diferentes. Ai, o analista (de negocio) fala que “para este sistema não ha multi-moeda”. E o money não é usado. Isto é uma falha em identificar o padrão. Todos os sistemas são multi-moeda já que se server para N serve para 1. mas se serve para 1, não serve para N.
Além destas restrições tipicas de “para este sistema” temos restrição no nivel de abstração. Por exemplo, poucos “domain experts” identificam controle de estoque com o tratamento de contas equivalente a finanças ou contabilidade. Isto porque para eles estoque é fisico (localizável no espaço-tempo) enquanto finanças e contabilidade não é. Para um software tudo sempre é meta-fisico (apenas uma ideia ou conceito). Identificar estoque com o padrão Account não é comum ou trivial para a maioria dos analistas o que os leva a modelos mais complexos/menos pradronizados.
Os padrões de analise como o nome indica advém da analise do dominio. Se essa analise não é bem feita os padrões não são identificados ou são mal-identificados.
Veja bem, os padrões são para serem aplicados ao modelo. O modelo é que resovlerá problemas do dominio, não o padrão em si.
Se o problema de dominio muda, é o modelo que muda (normalmente aumenta a abstração) se o modelo muda, é outro modelo, com outros padrões.
[quote] Só discordo do ponto que tu diz que “o padrão foi mal identificado”, acho que “mal” da um significado de intenção. O fato de eu não identificar uma situação não inválida uma solução que eu tinha dado anteriormente. Apenas, neste ponto, eu tenho que me “adaptar”.
[/quote]
Não. Vc tem que abandonar o modelo antigo e fazer outro. Esse outro terá outros padrões.
Vc não está reaproveitando nada. A evolução de um modelo é por descontinuidade. Se tentar fazer por continuidade, vc começará a fazer gambiarra logo,logo.
[quote]
Esse exemplo não é bom. Não é de software e não caracteriza um padrão. Padrão não é uma tecnica de construção. Padrão é algo que sempre se repete. Um padrão seria, por exemplo, que a relação entre o tamanho da flor de gira-sol com as petalas se relaciona ao tamanho sem as pétalas pelo numero de ouro ( o numero de outro e um numero tal que o seu quadrado é igual a ele somado um). Isto é sempre verdade porque é um padrão da flor do gira-sol. Qualquer gira-sol em qualquer parte do mundo irá obedecer esta regra empirica.
Um padrão da arquitetura seria , por exemplo, colocar a sala sempre com as janelas viradas para a vista mais nobre. Repare como é o padrão é meio abstrato e não tem variáveis do tipo “não se pode aplicar se…”
Quando pedi exemplos, pedi de padrões de software. Exemplo em que vc escolher o padrão Y e depois , quando novo requisitos chegaram , descobrir que deveria ter sido o X.
Ta, não sei bem o que define um gira-sol como um gira-sol. Não sei se é essa relação auréa que tu supracitou. Mas digamos que, o que define o gira-sol não é a razão auréa e sim a semente que o mesmo possui capaz de, somente ele, produzir um determinado tipo de óleo. Imaginemos que a razão auréa não se aplique a uma espécie de gira-sol achada hoje.
Como você definiria isso?
Te faço essa pergunta apenas pra mim me contextualizar com teu raciocínio. A propósito, não é uma pergunta capciosa…
Mas… Em tempo… Como disse anteriormente, acho que estamos apenas com um diferença de contexto/semântica no que estamos falando…
Ta, não sei bem o que define um gira-sol como um gira-sol. Não sei se é essa relação auréa que tu supracitou. Mas digamos que, o que define o gira-sol não é a razão auréa e sim a semente que o mesmo possui capaz de, somente ele, produzir um determinado tipo de óleo. Imaginemos que a razão auréa não se aplique a uma espécie de gira-sol achada hoje.
Como você definiria isso?
[/quote]
como disse, é uma regra empirica. O que significa que novos dados, novos requisitos podem mudar as coisas. Veja bem, este tipo de coisa não acontece com Design Patterns porque eles estão limitados ao escopo OO. A realidade não tem limites e essa que é a grande diferença dos padrões de analise.
No caso em particular, eu continuaria pelo empirismo. Vc simplesmente cataloga que existe dois tipos de flor. aqueles a que se aplica o padrão, e aqueles a que não. Estes ultimos formam uma nova classe. bom, na realidade a biologia começou bem assim …
Mas continuo achando que os exemplo não são bons já que fogem ao escopo OO e de software que é o foco aqui.
Acho interessante que a discussão, no final, converge para o que o Luca falou no primeiro post.
Geralmente, eu sigo os passos abaixo para desenvolver software:
- Entenda do que você está fazendo;
- Torne o programa eficaz (resolva o problema);
- Torne o programa eficiente (resolva o problema, usando as melhores práticas).
Não dá para fugir dessa ordem.
No caso de otimização, entrariam mais dois passos:
4. Use soluções específicas para o problema;
5. Use uma arquitetura de sw/hw específica para o problema.
[quote=ViniGodoy]Acho interessante que a discussão, no final, converge para o que o Luca falou no primeiro post.
Geralmente, eu sigo os passos abaixo para desenvolver software:
- Entenda do que você está fazendo;
- Torne o programa eficaz (resolva o problema);
- Torne o programa eficiente (resolva o problema, usando as melhores práticas).
[/quote]
O passo 2 não deve existir. Utilizar esse passo dois gera custo, debito tecnico, gambiarra, consume tempo, deturpa o modelo, deturpa integrações com outras partes do sistema. As desvantagens são maiores que as vantagens. Básicamente : esse passo é onde está a raiz de todo o mal de um design ruim, fraco, acoplado, sem longividade.
Entenda o problema e resolva-o seguindo as melhores práticas. se não sabe quais são ,aprenda-as. Esse tempo aprendendo as boas práticas não é custo, é investimento.
Olá
Na verdade as idéias estão lá desde os primeiros posts mas não exatamente no primeiro.
Apesar de escrever código não fazer parte do meu dia a dia, acredito que atualmente o modo de desenvolver sistemas mudou e quem ainda não mudou, acabará em dificuldades ou isolado.
Não acho mais sentido em pensar, pensar, pensar um monte, fazer diagramas, criar as classes e só depois escrever código intocável já com toque de gênio.
Para mim o mais recomendáve é a prática de escrever código sem compromsso e ir refinando aos pouquinhos. Escrever testes bobos só para conferir algoritmos, construir classes a partir do modelo de negócio tentando dissecar o problema mas sem nenhuma preocupação com nada definitivo. O uso de BDD ajuda. E seguir sempre testando, refinando e refatorando (inclusive jogando classes fora ou criando novas, é aqui que o monte de diagramas prévios se ferram).
De tempos em tempos parar e mostrar a um colega como está resolvendo o problema. Explicar o caminho adotado e verificar se outra cabeça tem alguma idéia melhor. Pode ser que neste ponto já tenham sido incluídos alguns padrões mas se depois foram julgados pelos pares como não sendo a melhor solução, será jogado fora do mesmo jeito do que a solução ad hoc.
Vejo a revisão em par como uma das melhores práticas de desenvolvimento por vários motivos, entre eles os seguintes:
- Alinha os conhecimentos da equipe em menos tempo, evita o caso de sobrar algum Sr SabeTudo 100% certo cujo conhecimento o coloque em alguma torre de marfim
- Duas cabeças pensam melhor do que uma. A chance de passar erros conceituais e de entendimento do negócio é minimizada.
- Aumenta a possibilidade de encontrar algum padrão adequado e principalmente algum caso de reuso de código.
- Aumentam as chances do código ficar legível, de que a escolha dos nomes sejá consensual, etc.
É este o motivo porque venho enfatizando que não se deve programar por padrões e sim programar pelo problema a resolver. Padrões aparecerão naturalmente se forem necessários.
E aí alguém poderia me perguntar?
E se trabalho sozinho sem nem um colega presencial ou que possa parear via Skype?
É ruim mas acontece. Neste caso sugiro fazer do mesmo jeito e incluir no seu pomodoro paradas de tempos em tempos para rever o código e verificar se está legível, se deixa débito técnico, se está testado e é testável, se não foi feito algo parecido em outro trecho do sistema que possa ser unificado sem prejuízo e se há algum padrão que ajude na clareza do entendimento. Não use padrões só porque existem.
Como veem, o que preconizo é completamente diferente de colocar o polegar de costas para o vento e tentar advinhar logo de cara o melhor caminho a seguir.
Como antigo velejador, meu conselho é: não adianta levar o barco rápido para lado errado da raia onde podem ocorrer piores condições. É melhor correr menos riscos e ir escolhendo o vento a cada passo e mudando o rumo em cada instante que se faça necessário.
RESUMO:
- Não programem por padrões.
- Primeiro se concentrem na solução do problema
- Não tenham medo ou vergonha de jogar código fora ou refatorar
- SEMPRE que possível, e deve ser possível diariamente, mostre seu código ao colega e habitue-se a examinar o código do outro. Não pareie sempre com a mesma pessoa com quem tem mais afinidade ou já sabe o modo de pensar.
[]s
Luca
Vejamos às diferenças
RESUMO:
- Não programem por padrões. :arrow: Modele por padrões. Padrões não são implementações!
- Primeiro se concentrem na solução do problema :arrow: A solução do problema é um modelo de objetos. concentre-se em encontrar esse modelo
- Não tenham medo ou vergonha de jogar código fora ou refatorar :arrow: Mas não use isso como desculpa para fazer a primeira porcaria que lhe vier à cabeça ou justificar não pensar no modelo de objeto o suficiente. Ninguem diz que precisa um modelo uml no visio, apenas precisa ter um modelo que, em toda a honestidade, é o melhor que vc consegue depois de conhecer o problema e ter visto como foi resolvido antes por outros.
- SEMPRE que possível, e deve ser possível diariamente, mostre seu código ao colega e habitue-se a examinar o código do outro. Não pareie sempre com a mesma pessoa com quem tem mais afinidade ou já sabe o modo de pensar. :arrow: concerteza.
Olá
VIVA!!!
O Sérgio Taborda concordou com alguém! E foi comigo!
A única discordância dele comigo é esta:
Para mim o melhor meio de encontrar este modelo é iterativamente. O que recomendo é não acreditar que conseguirá encontrar este modelo logo de cara.
Seja humilde em relação ao seu código. Comece por baixo. E não tenha apego por ele. descarte-o sem dó.
Quanto a questão de modelagem
Há muito que já escrevi aqui que modelagem se faz com canetinha em quadro branco e de preferência em conjunto ou com avaliação da equipe. Para documentar basta uma máquina fotográfica digital. Então, sempre que há necessidade de fazer algum tipo de modelagem prévio, sugiro que sempre seja pareada. Se não for criada em par, que pelo menos seja discutida em par. Concordo com o Sérgio e acredito que haja boas chances de se perceber e discutir algum padrão neste momento da modelagem.
Mas sem que isto resulte em um modelo engessado que ninguém mais pode modificar. O código as vezes nos mostra algo que não conseguimos abstrair a priori.
[]s
Luca
Sérgio, de que adianta você ter um artilheiro que corra muito o campo, saiba passar bem, driblar bem, chegue na cara do gol, mas não marque o ponto?
O que os passos dizem, é o que o Luca disse. Primeiro você se preocupa em entender o problema. Em seguida, tenta chegar a uma solução 100% funcional. Lógico, que se você vai procurar fazer isso de uma maneira elegante. Mas a preocupação inicial deve ser o problema, e não a forma. Ninguém falou em gambi, em passo nenhum, essa inferência foi por sua conta. O passo 2 não diz “resolva o problema de forma eficaz, de qualquer jeito”, estamos falando aqui de programação profissional, não de amadorismos. COmo você mesmo citou, não se deve usar esse passo como desculpa para fazer código porco. Mas antes de sair aplicando padrões em tudo, refatorando código, procurando oportunidades de DI, tornando a arquitetura complexa, tente chegar num programa simples e funcional, sem gambiarras.
Mas, até onde eu sei, ainda não inventaram um programador imune à falhas, ou que possa prever com completa exatidão a execução de um programa antes de executa-lo. Então, se a sua solução ainda não estiver tão rápida, flexível, ou consumindo tanta memória quanto você gostaria, você pode ter que recorrer ao passo 3, e procurar formas mais eficientes, sem abrir mão da flexibilidade. Por exemplo, você pode adicionar um ou outro cenário a sua solução e ver como ela reage. Você mesmo sugeriu isso. Eu não adicionaria um cenário hipotético, antes de entender totalmente o primeiro cenário, real. Da mesma forma, não adianta ir para a revisão de código, sugerida pelo Luca, sem antes ter um código funcional.
Bom, então devo ser só eu… eu não vejo dessa maneira. Não sei mais o que dizer para explicar.
Eu vejo dois tipos de refactoring. Um por motivos de simples implementação, uma classe não está certa, trocar array por list, aplicar final, sychronized, , dividir método em sub-metodos, etc… coisas de codigo mesmo. E tem o refactoring de modelo. A classe não herda daquela, ou duas classes independentes deveriam ter um pai comum, um tiny type deveria ser usado em vez de um primitivo, ou invez de string. etc… coisas que , deixando como está continuaria funcionando, mas que são alteradas para que o modelo faça sentido. É este tipo de refactoring de modelo que não pode ser continuo. Acontece eventualmente, mas como exceção, Não podemos instituicionalizar o refactoring de modelo por isso é catastrófico… é o que se faz todos os dias por - ou melhor , não se faz, porque é caro p’ra caramba e as equipas afunda nesse débito tecnico infinito. É o famoso, vamos fazer assim ,porque não dá tempo de melhorar. Não estamos falando de usar o eclipse para refactorizar, estamos falando de modificar o modelo abstrato.
Refactoring é algo ruim, sua metodologia não se pode basear nisso. Refactoring é exceção é uma ferramenta de urgencia, de cirurgia, não é para fazer todos os dias. Constante refactoring significa que seu codigo e seu modelo são fracos, vc não enxergou “the big picture”. Refactoring eventual é necessário, mas para correção, se vc faz refacotoring toda a hora quer dizer que seu codigo está errado permanentemente. Refactoring não é uma ferramenta de desenvolvimento, é um ferramenta de correção. O que vcs estão defendendo é quase um refactorign driven development e isso é inaceitável.
Vejam assim: o que é melhor, um código que nunca precisou ser refactorizado ou um que é refactorizado todos os meses ?
o segundo é muito simples de alcançar. Ponha alguem sem experiencia fazendo um sistema, e é assim que ele fará. Experimentalização.
o primeiro é que é realmente dificil, complexo, e gratificante. Afinal para que foram identificados os padrões de projeto ? Porque o GOF escreveu o livro? Para que todo o planeta fique refactorando seu codigo 1000 vezes por ano ? Não me parece. Ha uma vantagem clara em modelar usando padrões. Refactoring nunca poderá competir com isso.
Só que, claro, é preciso saber fazer. Se o cara lhe diz que vai fazer um singleton a sua primeira reação deve ser: “Isso não é um singleton!” Ao que ele responderá : “mas precisamos ter acesso global” , ao que vc responde : “singleton não é para isso”. Não é facil vc explicar para alguem que a classe não é um singleton ( ou qq outro padrão) quando a pessoa tem fracas bases sobre padrões, sobre OO em geral. Eu sei, já fiz isso muito. É frustrante.
É possivel escrever bom codigo sem ser consciente da existencia de padrões : sim, concerteza. Mas é possivel escrever bom código sem que os padrões estejam lá ? Não. Portanto só ha duas alternativas: a) vc tem talento inato e colocar os padrões lá sem saber que está fazendo isso. É um dom. b) vc estuda padrões e aprende a aplicá-los.
Vcs acham que talento se aprender ? Eu não acho. Acham que por tentativa e erro a pessoa será tão boa quanto o talentoso? poderá, mas não em tempo que possa competir com a opção b. Portanto eu sigo a segunda hipotese. Não vou perder meu tempo , trabalho manual e paciencia criando algo que sei que não serã bom o suficiente.
Alguém já viu um código que nunca precisou de refactoring? Eu não.
Em momento nenhum eu falei que você não deveria pensar sobre o código, ou tentar faze-lo da maneira correta. Aliás, fazer um sistema simples e funcional também não é uma tarefa fácil. Envolve projeto e entender a “big picture”.
Mas não creio que sequer seja possível acertar tudo de primeira ou escapar da refatoração. Vai haver refactoring, seja você um grande mestre Yoda da programação, ou não. A diferença é só a quantidade de refatorações que serão feitas, e quando.
Também não falei em programar por experimentação. Isso, novamente, foi você que inferiu. Mas realmente acho importante as refatorações serem constantes, pois nunca vi nenhum programa ou projeto que escapou delas. Aliás, nunca vi um código que nunca precisou ser refatorado. Se você consegue programar assim, talvez deva escrever um livro dizendo como, pois para mim, isso envolve até talentos mediúnicos e sobrenaturais.
Assumir o que você diz, envolveria um projeto perfeito, um entendimento de requisitos perfeito (tanto de sua parte, quanto a de seu usuário), um controle total do ambiente e a certeza total do comportamento do sistema após implementado. E também envolve ter a noção exata de como esse sistema e o ambiente onde ele está evoluirão. Sinceramente, nunca vi ninguém dominar com precisão absoluta todos esses fatores (para não dizer, qualquer um deles).
Taí valiosas dicas!E eu posso citar meu projeto corrente(em Swing) na qual eu nem tenho o domínio de todas as entidades do Sistema(o pessoal do SGB não é nada friendly…) e posso ter que jogar vaárias classes fora a qualquer momento.É um projeto de pesquisa, se eu me ligasse em seguir um padrão X ou Y ficaria louco.Sequer sei se eu vou gerar a base localmente ou vou pegar pedaços(é, pedaços!!!) dos diversos BD´s existentes… isso é mais comum do que muitos imaginam. Engraçado é ficar com o cliente tendo que fazer POT(Programação Orientada a Telas…) e nunca saber se essa telas resistem até a semana seguinte… :roll:
[quote=ViniGodoy]Alguém já viu um código que nunca precisou de refactoring? Eu não.
Em momento nenhum eu falei que você não deveria pensar sobre o código, ou tentar faze-lo da maneira correta. Aliás, fazer um sistema simples e funcional também não é uma tarefa fácil. Envolve projeto e entender a “big picture”. [/quote]
Pois, mas tb não disse o contrário…
O ponto não é que refactoring é inutil ou que se o fizer vc é mau programador. Refactoring, como já disse é uma ferramenta util. O ponto é que sempre que vc faz refactoring significa que se enganou no modelo. Mas o modelo muda, poderá dizer. Sim, mas se a mudança é constante, ha padrões para isso também. Como no exemplo do Ironlynx. Deixar que todas as classes mudem a todo o momento é non sense. É preciso ver que é constante e isolá-lo do resto. Utilizar um design que seja cooperante com a mudança e não contra ela. Bridge , Mediator e Interpreter são muito bons para isso. Sempre ha um porto seguro onde se amarrar.
Prometo que é a ultima vez que digo isto, mas preciso deixar bem claro: refactoração é utilizada quando é necessária. Sempre que usar isso representa um atrazo, um custo e um erro. Portanto, não programe à toa só porque depois poderá refactorar. Nem sempre é possivel refactorar depois. “refactor driven development” é suicídio.
Um bom modelo OO não muda quandos os requisitos mudam ele simplesmente é ajustado ( a expressão é tailored). Como uma roupa que ficou larga ela é ajustada. Mas a roupa em si é a mesma.
Quando o seu modelo muda pouco significa que vc matou a charada do melhor modelo que se adqua ao software. Quando muda muito e constantemente vc precisa abstrair mais, deixar o modelo mais flexivel,mais ajustável.
Enfim, padrões são excelentes guias. Guias não são deuses. São para ser estudados e entendidos , não reverenciados e idolatrados. É possivel matar sistemas em nome de -falsos - padrões , mas os padrões verdadeiross realmente não têm culpa. Livros de catalogos deveriam ser mais explicativos , dando exemplos reais.
Eu não aconcelho o GoF para programadores java, perfiro este aqui. Temo que uma segunda edição do GoF traria mais problemas ainda ( DI como padrão é simplesmente horrível ideia e vai causar mais problema que o MVC já causou - e o MVC nem sequer é do GoF).
Sergiãoooo !!!
Recomendei o livro de design Patterns Java WorkBook , para a Comunidade Java Livros valeu !!!
[quote=javamaniaco]
Não culpo a Sun e nem o Java. Pra ser sincero, nem sei porque tamanha complexidade é dão idolatrada e dão adotada nas empresas e porque, uma linguagem tão mais inteligente, mais fácil de escrever não teve seu lugar ao sol como o Java. Seria porque a Sun já foi bem grande? Talvez, olha o .Net, Microsoft por trás e pum, as empresas grandes adotam.[/quote]
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.
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]
Refatoramos Código ou Requisitos, se for refatorar o requisito não poderíamos intervir na estrutura do código, se fosse para refatorar o Código que comportamentos teríamos aos requisitos, se é que isso impactaria em algo.
O que entendi na observação em ser um suicídio pode ocorrer uma quebra encadeada ao design do projeto, por motivo não intencionais devido a não se ter controle para isso ou tecnologia que faça determinado histórico de mudanças dessa natureza, naturalmente estamos falando de um projeto enorme, mas o que não vem a ser projetos pequenos que podem assumir estruturas maiores futuramente, então como mante-los.
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]
Eu não disse que refactoring é prejudicial , eu disse que fazer apenas refactoring é prejudicial.
Mas já que vc é entendido em agilidade e não faz waterfall e tudo isso , explique-nos como monta o product backlog sem que acha planejamento do projeto como um todo e explique-nos o que seria o Brainstorm meatting e como se planeja os seus releases sem ser com antecedência e antes de começar o primeiro sprint. Aliás, diga-nos como calcula o numero de sprints necessários.
Depois explique como refactoring é uma tecnica de scrum e/ou onde scrum menciona tecnicas de programação/desenvolvimento.
Explique também como refactorar é totalmente inócuo ao processo do sprint e não consome qualquer tempo, custo e como não requer nenhum planejamento. Eu gostaria muito de saber como vc usa a diretiva de “re-planeja constantemente” sem ter um plano para começo de conversa.
Depois que vc explicar tudo isto , muito bem explicado, com exemplo práticos e convincentes eu respondo à sua colocação.