Olha a propaganda 8) ! Estou em Chicago também, próximo da W 35th Street.
Desculpe mas não pude deixar de comentar.
Flws.
[quote=al.barbosa][quote=rmendes08][quote]
Os métodos ágeis também têm mecanismos para seguir as etapas acima.
[/quote]
essa eu realmente não entendi … [/quote]
Por exemplo, no XP usam-se:
histórias de usuário - entender o problema - requisitos;
Projeto simples - planejar uma solução;
Testes constantes - testar para ver se a solução resolveu o problema. Como os testes são escritos antes da programação, é uma forma de planejamento também.
Programação em pares - é uma forma de revisão enquanto o sistema é codificado.
Os métodos ágeis valorizam mais o software funcionando do que a documentação abrangente. Mas eles não dispensam planejamento, testes, etc… Possuem mecanismos (práticas) para proporcionar qualidade ao sistema.[/quote]
Nesse caso, o termo mais apropriado seria “disciplinas”, e não etapas. Histórias de usuário podem ser adicionadas a qualquer momento , e o TDD é uma prática de desenvolvimento em si, e não uma etapa separada.
[quote=rmendes08][quote=al.barbosa][quote=rmendes08][quote]
Os métodos ágeis também têm mecanismos para seguir as etapas acima.
[/quote]
essa eu realmente não entendi … [/quote]
Por exemplo, no XP usam-se:
histórias de usuário - entender o problema - requisitos;
Projeto simples - planejar uma solução;
Testes constantes - testar para ver se a solução resolveu o problema. Como os testes são escritos antes da programação, é uma forma de planejamento também.
Programação em pares - é uma forma de revisão enquanto o sistema é codificado.
Os métodos ágeis valorizam mais o software funcionando do que a documentação abrangente. Mas eles não dispensam planejamento, testes, etc… Possuem mecanismos (práticas) para proporcionar qualidade ao sistema.[/quote]
Nesse caso, o termo mais apropriado seria “disciplinas”, e não etapas. Histórias de usuário podem ser adicionadas a qualquer momento , e o TDD é uma prática de desenvolvimento em si, e não uma etapa separada.[/quote]
Veja, eu não disse que as práticas ou disciplinas do XP são etapas. E nem que elas têm que ser realizadas em sequência.
O que estou dizendo é que o XP e os métodos ágeis não dispensam planejamento, testes, etc. - e que os passos que citei também são seguidos nos métodos ágeis. Só que eles são seguidos de forma iterativa e incremental.
Se precisar realizar cada etapa totalmente para depois iniciar a outra, aí é o processo em cascata. Não é disso que estou falando.
As histórias de usuário podem ser adicionadas a qualquer momento, mas é mais útil escrevê-las antes de criar o projeto referente a essas histórias.
O projeto simples faz sentido antes de codificar a solução projetada.
Também não estou dizendo que o TDD é uma etapa separada, estou dizendo que escrever os testes antes de codificar também é uma forma de planejamento. Planeja-se os resultados que o sistema terá que apresentar. Depois de implementar são aplicados os testes para verificar se os resultados planejados foram atingidos.
[quote=CyberX][quote=saoj]
Veja um exemplo de framework web sem nenhum framework (full-stack): http://www.mentaframework.org
[/quote]
Olha a propaganda 8) ! Estou em Chicago também, próximo da W 35th Street.
Desculpe mas não pude deixar de comentar.
Flws.[/quote]
Dessa vez não foi propagando. Ao invés dessa mensagem tu poderia ter me perguntado o que vou fazer hoje em Chicago? Mas não, preferiu ficar de cão-de-guarda-de-propaganda. Ótimo. Se me encontrar com alguma mulher essa noite nem precisa vir falar comigo. E se ela tiver amiga(s) não vou te apresentar.
Cara, quando eu desenvolvo eu procuro pensar um pouco sim, mas não a ponto de travar o desenvolvimento. Eu estou lendo um livro que fala um pouco sobre isso (Desenvolvimento Guiado a Testes - Kent Beck) e ele diz que não temos a obrigação de sempre fazer a mesma coisa e sim ter o bom senso de variar o tamanho dos passos que damos conforme a necessidade. Tem coisas que são óbvias, claro, variando com a sua experiência, então não há a necessidade de planejar algo que você faz sempre. Mas tem outras coisas que são novas para nós, então temos que testar, aprender e principalmente, pensar.
Então eu acho que é isso ai, a boa e velha resposta de advogado “Depende”, do que você faz e o que você já fez.
[quote=lucaspolo]Cara, quando eu desenvolvo eu procuro pensar um pouco sim, mas não a ponto de travar o desenvolvimento. Eu estou lendo um livro que fala um pouco sobre isso (Desenvolvimento Guiado a Testes - Kent Beck) e ele diz que não temos a obrigação de sempre fazer a mesma coisa e sim ter o bom senso de variar o tamanho dos passos que damos conforme a necessidade. Tem coisas que são óbvias, claro, variando com a sua experiência, então não há a necessidade de planejar algo que você faz sempre. Mas tem outras coisas que são novas para nós, então temos que testar, aprender e principalmente, pensar.
Então eu acho que é isso ai, a boa e velha resposta de advogado “Depende”, do que você faz e o que você já fez.[/quote]
Concordo plenamente.
Eu falei sobre os passos citados no livro do Pressman, mas entendo que pode variar muito a forma de segui-los.
Por exemplo, num caso mais simples, suponha que você é um desenvolvedor solo, trabalhando num projeto com pouca complexidade.
- Entender o problema - você conversa com o cliente e verifica se entendeu o que ele quer. Chega em casa e envia um e-mail para o cliente, explicando o que você entendeu da necessidade dele, pedindo para ele confirmar. O cliente confirma que é isso mesmo que ele quer.
- Planejar uma solução - você escreve num papel um rascunho das classes que vai precisar. Pensa um pouco se elas resolvem o problema e se a solução será fácil de manter. Decide se vai usar algum framework. Como é algo que você já está acostumado, não perde muito tempo.
- Implementar a solução - Você leva alguns dias desenvolvendo a solução.
- Testar - Você realiza uma bateria de testes e tenta cobrir as principais funções do sistema.
Os passos podem se repetir.
Num outro cenário, com uma equipe grande e um projeto complexo, envolvendo um contrato com o cliente, a coisa muda de figura.
- Entender o problema - são escritos uma série de casos de uso que são validados com o cliente cuidadosamente. É utilizado um processo iterativo, então não são detalhados todos os casos de uso no início. Eles vão sendo detalhados durante o projeto.
- Planejar uma solução - a equipe discute a melhor solução e os frameworks a utilizar. Prepara os diagramas do projeto e coloca num repositório central. Faz algumas provas de conceito. No início são projetados os casos de uso mais complexos e de maior risco. Etc.
- Implementar a solução - A solução é implementada em diversas iterações.
- Testar - Há uma equipe especializada em testes que realiza testes de integração, validação, etc. Versões alfa e beta são criadas. Etc.
Então é isso mesmo, depende.
[quote=saoj]A melhor forma de planejar é executar. Programacao é a arte de refatorar. Pra isso o eclipse te ajuda. Pra isso que existe SVN. Experimente criando branches. Há infinitas maneiras de desenvolver o sistema. Qual é a melhor?
A MAIS SIMPLES E BELA.
Tem gente que acha que complexidade é beleza. Aí ferrou…
Esqueca padroes. Tem que ter uma boa base de OO, e isso vc não pega lendo um livro, mas programando bastante. A teoria é importante mais é 25% da coisa. A prática é 3 vezes mas importante. É que nem andar de bicicleta.
[/quote]
Cara, eu concordo com quase tudo que voce diz, por isso que eu nao consigo entender porque voce nao gosta de TDD. Ele praticamente é a materializacao daquilo que voce repete topico apos topico. Ele “veste” de forma precisa tudo que voce diz, mas ainda assim voce vira as costas para a tecnica. Eu acho que voce teve alguma experiencia muito ruim em algum projeto com TDD mal implementado e por isso criou uma certa aversao a coisa. Talvez devesse dar uma segunda chance, mas enfim…
A unica coisa que eu discordo um pouco é quando voce diz que a teoria é 25% da coisa. Não sei, eu daria mais valor a ela, chegando ao 50/50. Eu conheco muita gente com mais de 10 anos de desenvolvimento, que tem uma enorme pratica em fazer exatamente a mesma coisa o tempo todo. Inclusive cometendo os mesmos erros, vez apos vez. Entao, eu acho que a teoria é importante tambem, e muito. Mas nao mais que a pratica.
E mais, é preciso entender a teoria, testa-la na prática, questioná-la. Não sair por ai aplicando idéias só porque leu no blog do Martin Fowler, sem nem saber porque e por onde. Seja qualquer regra, qualquer norma, prática, pattern ou seja lá mais o que for, nunca use sem um motivo real. Se voce não sabe porque o uso de um Strategy te ajudaria em determinado ponto, bota mais um if e vamo embora.
[quote=AlexandreGama][quote]
Sempre tento implantar um design pattern.
[/quote]
Acho perigoso isso. Normalmente a funcionalidade deve ser escrita da forma mais simples e funcional possível e a seguir refatorá-la para algum design pattern, se houver necessidade =)
Abs![/quote]
Eu ia falar isso. O pessoal hoje em dia acha que design patterns eh a solucao para todos os problemas do mundo. Acaba com a fome, miseria, traz a paz mundial e acaba com codigos feios, bugs e etc um verdadeiro discursso de miss Brasil. hehehe
Quando eu tenho algo pra fazer eu nao faco nenhum UML, ou qualquer diagrama complicado, primeiro eu tento entender exatamente o que eu tenho que fazer e tento enxergar um pouco do futuro do que precisa ser feito, assim eu evito algumas dores de cabeca futuras. Tambem tento entender o codigo em torno da area que eu adicionar algo. Feito isso eu faco um diagrama bem simples e rapido, soh para ter uma visao do que eu vou implementar.
Durante e quando termino a minha implementacao eu tento responder a essas perguntas:
- Codigo esta facil de entender?
- Estou utilizando codigo??
- Pode ser reutilizado?
- Estou repetindo codigo??
- Otimizado ao maximo?
- Vai afetar outras partes do sistema?
Ai eu sempre vou adaptando e modificando quando necessario, mas eu somente faco um check-in quando todas essas perguntas que eu coloquei acima sao respondidas, quando meu codigo esta bem documentado, comentarios no lugar, testes unitarios (valido para codigo backend e frontend).
//Daniel