Planejar antes de codificar?

Sempre tento implantar um design pattern.

O desenvolvimento de fluxogramas é de grande importância para os profissionais em programação de computadores. Omitir o seu desenvolvimento durante a fase de planejamento, visando apenas um meio de ganhar tempo utilizando-se da programação direta, mostra o quão despreparado está o programador. Pois, à medida que são descobertos erros de lógica, fazem com que o programador passe horas tentando corrigi-los, o que poderia ser solucionado com o desenvolvimento inicial de um fluxograma.

:thumbup:

:arrow: UML - http://www.uml.org/

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!

diegointersoft:

Olá pessoal, recentemente comecei a me questionar sobre o meu modo de desenvolvimento, pois sempre quando tenho um problema, logo parto direto para a linha de comando, e no próprio código faço o planejamento do meu código, isso as vezes da uns transtorno, pois no meio do código mudo de idéia e crio uma lógica melhor.

Afinal, gostaria de saber como vocês quando se deparam com um problema de programação como é sua abordagem de desenvolvimento ? Planejam criando um algoritmo em português e uma lógica ANTES e depois codificam isso, ou já codificam direto ? Seria o último recomendável ?</blockquote>

Acho que planejamento pode ser muito útil para manter a objetividade do que se está fazendo. As técnicas são muitas, pode ser pseudo-código, protótipos de telas, diagramas dos mais diversos tipos ou um rascunho livre. Acho que qualquer uma é válida desde que se siga a regra de ouro do planejamento: o planejamento não pode durar mais nem ser mais difícil do que a tarefa em si.

Me permite discordar de você? UML simplesmente auxilia e não é regra. Desenvolvimento com Testes de Unidade te dão a orientação do que deve ser feito e não é necessária a complexidade que digramas de classe, sequências, etc possuem.
Creio que essa forma seja a forma clássica da Engenharia de Software e é a forma que constantemente amarra o desenvolvedor a um fluxograma que tenta mostrar o que sequer foi iniciado.

TDD, escrevendo um teste e fazendo uma funcionalidade passar, com um código que seja simples. =)

Abs!

No meu ponto de vista a vida do software começa pelo banco de dados, logo, um modelo ER consigo visualizar todas as camadas antes mesmo de sair desenvolvendo, incluindo a tela(view), e também posso perceber os erros de design em que vou cair, e ja encontrar as soluções masi adequadas, ou mudar o design do banco.

Me permite discordar de vc tb? O banco de dados muitas vezes deve ser o último a ser visto, com exceção de app legadas, etc. A sua modelagem de código é muito mais importante que um “simples local para guardar os seus dados”. O seu Design não deveria
depender do seu banco, que na grande maioria será Relacional, criando entraves para a sua app OO.

Apenas outra visão

AlexandreGama:

No meu ponto de vista a vida do software começa pelo banco de dados, logo, um modelo ER consigo visualizar todas as camadas antes mesmo de sair desenvolvendo, incluindo a tela(view), e também posso perceber os erros de design em que vou cair, e ja encontrar as soluções masi adequadas, ou mudar o design do banco.

Me permite discordar de vc tb? O banco de dados muitas vezes deve ser o último a ser visto, com exceção de app legadas, etc. A sua modelagem de código é muito mais importante que um “simples local para guardar os seus dados”. O seu Design não deveria
depender do seu banco, que na grande maioria será Relacional, criando entraves para a sua app OO.

Apenas outra visão ;)

permito sim, rsrsrsrsrs, mas não penso como vc

InicianteJavaHenrique:

O desenvolvimento de fluxogramas é de grande importância para os profissionais em programação de computadores. Omitir o seu desenvolvimento durante a fase de planejamento, visando apenas um meio de ganhar tempo utilizando-se da programação direta, mostra o quão despreparado está o programador. Pois, à medida que são descobertos erros de lógica, fazem com que o programador passe horas tentando corrigi-los, o que poderia ser solucionado com o desenvolvimento inicial de um fluxograma.

:thumbup:

Cara, acho que tá um pouco exagerada essa frase. Para mim, mais parece propaganda do Maker ou de qualquer outra ferramenta que gere código a partir de fluxograma. Se o programador se sente confortável em desenhar fluxogramas antes de codificar, ótimo, mas isso não quer dizer que quem não o faz é despreparado.

Que bom q nem todo mundo tem a mesma visão =)

Volto a defender meu ponto de vista com a JPA por exemplo. Você pode modelar o seu código e criar em runtime as suas tabelas, ou seja, sua modelagem ficará muito melhor que tabelas auxiliares na mão por exemplo e seu
banco acompanhará “um pouco melhor” o seu design. Digo um pouco melhor por que sabemos das complicações de uma solução relacional com uma solução OO.

Abs!

Perfect!

AlexandreGama:

No meu ponto de vista a vida do software começa pelo banco de dados, logo, um modelo ER consigo visualizar todas as camadas antes mesmo de sair desenvolvendo, incluindo a tela(view), e também posso perceber os erros de design em que vou cair, e ja encontrar as soluções masi adequadas, ou mudar o design do banco.

Me permite discordar de vc tb? O banco de dados muitas vezes deve ser o último a ser visto, com exceção de app legadas, etc. A sua modelagem de código é muito mais importante que um “simples local para guardar os seus dados”. O seu Design não deveria
depender do seu banco, que na grande maioria será Relacional, criando entraves para a sua app OO.

Apenas outra visão ;)

Faço coro com o Alexandre …

O modelo relacional (relacional != ER) é muito limitado em termos de semântica, e na minha opinião existem ferramentas melhores para modelar o domínio de uma aplicação, o próprio diagrama de classes é ótimo na minha opinião.

Os diagramas UML são ótimos na minha opinião, eles cobrem os mais diversos aspectos de modelagem de um sistema, mas eu também acho que detalhar cada método, cada classe é um exagero. Uma vez definida a estrutura do sistema acho que é mais produtivo partir para o código.

Quanto a mudar de idéia no meio da implementação , bom, eu acho que isso é inevitável, principalmente com relação a interface.

AlexandreGama:

permito sim, rsrsrsrsrs, mas não penso como vc

Que bom q nem todo mundo tem a mesma visão =)

Volto a defender meu ponto de vista com a JPA por exemplo. Você pode modelar o seu código e criar em runtime as suas tabelas, ou seja, sua modelagem ficará muito melhor que tabelas auxiliares na mão por exemplo e seu
banco acompanhará “um pouco melhor” o seu design. Digo um pouco melhor por que sabemos das complicações de uma solução relacional com uma solução OO.

Abs!

Bom, eu tenho que confessar que eu tenho um pé atrás com os frameworks JPA. Sempre é bom conferir o SQL gerado para ter certeza que não tá virando me$#%3 ,

rmendes08:

InicianteJavaHenrique:

O desenvolvimento de fluxogramas é de grande importância para os profissionais em programação de computadores. Omitir o seu desenvolvimento durante a fase de planejamento, visando apenas um meio de ganhar tempo utilizando-se da programação direta, mostra o quão despreparado está o programador. Pois, à medida que são descobertos erros de lógica, fazem com que o programador passe horas tentando corrigi-los, o que poderia ser solucionado com o desenvolvimento inicial de um fluxograma.

:thumbup:

Cara, acho que tá um pouco exagerada essa frase. Para mim, mais parece propaganda do Maker ou de qualquer outra ferramenta que gere código a partir de fluxograma. Se o programador se sente confortável em desenhar fluxogramas antes de codificar, ótimo, mas isso não quer dizer que quem não o faz é despreparado.

A fonte é do livro:

MANZANO, José Augusto N. G.; OLIVEIRA, Jayr Figueiredo de. Algoritmos: lógica para Desenvolvimento de Programação de Computadores. 21 ed, São Paulo: Érica, 2008.

Porém, para começar (o que eu acredito ser a dúvida do autor do tópico) está de bom tamanho.

:thumbup:

Exatamente! Não só inevitável como saudável. O que seria do Refactoring se não pudessemos modificar um código existente…

AlexandreGama:

O desenvolvimento de fluxogramas é de grande importância para os profissionais em programação de computadores. Omitir o seu desenvolvimento durante a fase de planejamento, visando apenas um meio de ganhar tempo utilizando-se da programação direta, mostra o quão despreparado está o programador. Pois, à medida que são descobertos erros de lógica, fazem com que o programador passe horas tentando corrigi-los, o que poderia ser solucionado com o desenvolvimento inicial de um fluxograma.

Me permite discordar de você? UML simplesmente auxilia e não é regra. Desenvolvimento com Testes de Unidade te dão a orientação do que deve ser feito e não é necessária a complexidade que digramas de classe, sequências, etc possuem.
Creio que essa forma seja a forma clássica da Engenharia de Software e é a forma que constantemente amarra o desenvolvedor a um fluxograma que tenta mostrar o que sequer foi iniciado.

TDD, escrevendo um teste e fazendo uma funcionalidade passar, com um código que seja simples. =)

Abs!

É outra visão válida

:thumbup:

Confesso que também verifico de vez em quando. Na dúvida, é sempre bom dar uma verificada

AlexandreGama:

Você pode modelar o seu código e criar em runtime as suas tabelas…
Abs!

no meu ver, isto leva a erros de design, em grandes aplicações uma alteração brusca no software digo algo que não foi planejado, não seria possivel com uma solução elegante, apenas uso de gambis

Ai pessoal, por favor, falem a minha lingua. Sou novo no mundo da programação e nunca trabalhei como programador, estou tendo programação este semestre na faculdade e não tive diciplinas de engenharia de software ainda para entender esse linguajar e conceitos complicados.

O que eu queria saber, é se vocês planejam antes de desenvolver ou não. E se criam fluxogramas ou algoritmo em portugues antes, dependendo do tamanho do problema é claro. Estou falando de aplicações Simples ou médias é claro. Desculpe não esclarecer antes, mas o foco da minha pergunta não é aplicações empresariais.

Mas quando falamos de design nos referimos ao design do código correto? O design do código vai muito mais além que armazenamento de dados. Se uma alteração for brusca como voce disse, seja orientado a banco de dados, seja orientado a objetos, seja procedural, o seu requisito mudará de qualquer forma, ocasionando a modificação do seu design de qualquer forma.

A modelagem do seu código de acordo com o seu banco faz parte de uma Engenharia clássica mais antiga e que não é bem vista hoje, já que o core da sua aplicação não deve estar na base. O seu ponto de vista é comumente encontrado em aplicações com volumes grandes de procedures(eca!) e triggers(eca again!) no banco, criando regras de negócio no proprio banco.

Novamente, acho perigoso a programação orientada a banco de dados.

Abs!

Neste começo de semestre é interessante você fazer um mínimo de modelagem sim, assim você já tem uma visão geral de como serão as suas classes e métodos. Mas não serão a bala de prata, ou seja, não necessariamente serão a sua versão final de implementação. No meio do caminho surgirão novos caminhos e cabe a você segui-los ou não.

Sobre os algoritmos em portugues(pseudo) neste começo abuse deles, afinal pedir uma xícara de café em alemão e pedir em chinês é a mesma lógica, você só mudará o idioma

Mas como a sua pergunta é bem genérica, vou parar por aqui senão escrevo até amanhã = )
Existem outras técnicas interessantes pra você dar uma olhada enquanto inicia na carreira, então sinta-se a vontade para perguntar.

Abs!

concordo com você, a implementação muda e o design do código muda também.

verdade também, nas novas aplicações que crio, faço como você mesmo disse: em runtime, nesses 4 anos de desenvolvimento com Java passei por 3 empresas e participei de n projetos, e todos os sistemas legados que peguei são exatamente como falow, triggers e procedures pra todo lado, estou tentando enchergar mais longe, até mesmo porque quero vir a me tornar um projetista de software(arquiteto), mas naõ bego que acho muito interessante retirar a carga de processamento do Java e deixar o banco trabalhar, legal ter falado com você, abraços.

O que você falou é interessante mesmo. Em novos projetos a facilidade de “começar bem” é muito grande. Infelizmente em projetos legados, muitas vezes com um banco que inicialmente teve como core uma aplicação em Delphi, VB (Java não escapa também rs) tem
80% da sua regra de negócio concentrada em triggers e procedures e isso é realmente dificil de se mudar.

Abraços!

Algorítmo eu vou direto pro código, nada de diagrama UML, no máximo rascunhos no papel e testes unitários

Sistemas eu estou experimentando uma abordagem que eu mesmo inventei de fazer toda a interface primeiro, sem se preocupar como vai ser implementado o código ou BD. Ainda to no começo mas estou gostando

Não deveria ser a contrario :?:

Primeiro funcionalidades depois layout (tá bom que usuário ver 70% de layout, mas mesmo assim…)

:thumbup:

Na verdade se vc faz algo independente da View, o “encaixe” da view fica facilitado. Acho que vai de projeto pra projeto mesmo. Mas no geral deve funcionar tb.

Abs!

Não deveria ser a contrario :?:

Primeiro funcionalidades depois layout (tá bom que usuário ver 70% de layout, mas mesmo assim…)

:thumbup:

Eu to fazendo assim pq são as telas que vão dizer quais vão ser as funcionalidades do sistema, que dados eu vou armazenar no banco. Quando eu terminar elas vou ter uma idéia de tudo que vai ser necessário no programa. Enquanto estou fazendo elas já posso testar com usuários oq se aquilo que to fazendo vai ser importante ou não

Mas isso é só um experimento em um projeto pessoal meu, e além disso as telas vão ser as partes mais difíceis de fazer, não vai ter nada de super complexo no código…

InicianteJavaHenrique:

rmendes08:

InicianteJavaHenrique:

O desenvolvimento de fluxogramas é de grande importância para os profissionais em programação de computadores. Omitir o seu desenvolvimento durante a fase de planejamento, visando apenas um meio de ganhar tempo utilizando-se da programação direta, mostra o quão despreparado está o programador. Pois, à medida que são descobertos erros de lógica, fazem com que o programador passe horas tentando corrigi-los, o que poderia ser solucionado com o desenvolvimento inicial de um fluxograma.

:thumbup:

Cara, acho que tá um pouco exagerada essa frase. Para mim, mais parece propaganda do Maker ou de qualquer outra ferramenta que gere código a partir de fluxograma. Se o programador se sente confortável em desenhar fluxogramas antes de codificar, ótimo, mas isso não quer dizer que quem não o faz é despreparado.

A fonte é do livro:

MANZANO, José Augusto N. G.; OLIVEIRA, Jayr Figueiredo de. Algoritmos: lógica para Desenvolvimento de Programação de Computadores. 21 ed, São Paulo: Érica, 2008.

Porém, para começar (o que eu acredito ser a dúvida do autor do tópico) está de bom tamanho.

:thumbup:

Esse foi o primeiro livro que comprei, no primeiro mês de faculdade ainda, para a disciplina lógica de programação.

Com todo respeito ao autor, li 2 livros dele, esse e o de Linguagem C, mas são muito básicos, aliás todos livros dessa coleção/editora parecem seguir o mesmo caminho.

Cara é muito básico, esse livro é para aprendizado de fluxograma (não UML) que é uma abordagem ultrapassada pois ninguém usa no mundo real, esses fluxogramas com caixinha, retângulo, paralelepípedo, etc…só servem para modelar programa de somar 2 números, ou imprimir os números pares de 1 a 100. Porra as faculdades ainda ensinarem isso ai é o fim da picada, acho que para o primeiro mês de aula, para fixar os conceitos de variáveis, entrada de dados, processamento e saída, vá lá, mas não mais que isso.

eu gosto de desenhar a arquitetura que vou usar, de uma forma rápida, como vai ficar cada camada, algumas coisas mais complicadas que vai ter…coisa do tipo. Isso na prática costuma ser um momento no qual temos que perder um tempo que não temos para evitar perder muito mais tempo depois…

Daniel_MV:

InicianteJavaHenrique:

rmendes08:

InicianteJavaHenrique:

O desenvolvimento de fluxogramas é de grande importância para os profissionais em programação de computadores. Omitir o seu desenvolvimento durante a fase de planejamento, visando apenas um meio de ganhar tempo utilizando-se da programação direta, mostra o quão despreparado está o programador. Pois, à medida que são descobertos erros de lógica, fazem com que o programador passe horas tentando corrigi-los, o que poderia ser solucionado com o desenvolvimento inicial de um fluxograma.

:thumbup:

Cara, acho que tá um pouco exagerada essa frase. Para mim, mais parece propaganda do Maker ou de qualquer outra ferramenta que gere código a partir de fluxograma. Se o programador se sente confortável em desenhar fluxogramas antes de codificar, ótimo, mas isso não quer dizer que quem não o faz é despreparado.

A fonte é do livro:

MANZANO, José Augusto N. G.; OLIVEIRA, Jayr Figueiredo de. Algoritmos: lógica para Desenvolvimento de Programação de Computadores. 21 ed, São Paulo: Érica, 2008.

Porém, para começar (o que eu acredito ser a dúvida do autor do tópico) está de bom tamanho.

:thumbup:

Esse foi o primeiro livro que comprei, no primeiro mês de faculdade ainda, para a disciplina lógica de programação.

Com todo respeito ao autor, li 2 livros dele, esse e o de Linguagem C, mas são muito básicos, aliás todos livros dessa coleção/editora parecem seguir o mesmo caminho.

Cara é muito básico, esse livro é para aprendizado de fluxograma (não UML) que é uma abordagem ultrapassada pois ninguém usa no mundo real, esses fluxogramas com caixinha, retângulo, paralelepípedo, etc…só servem para modelar programa de somar 2 números, ou imprimir os números pares de 1 a 100. Porra as faculdades ainda ensinarem isso ai é o fim da picada, acho que para o primeiro mês de aula, para fixar os conceitos de variáveis, entrada de dados, processamento e saída, vá lá, mas não mais que isso.

Cara, eu não tenho nada contra fluxogramas, absolutamente nada mesmo. Aqui onde eu trabalho mesmo, há quem goste de fluxogramas para documentar processos, e por incrível que pareça, funciona. Para fins de aprendizado, eu acho que eles são ótimos. Explicar uma estrutura de decisão ou uma estrutura de repetição com um fluxograma é a melhor maneira, na minha opinião.

Enfim, o ponto que eu gosto de deixar claro é que ferramentas não são inerentemente boas ou ruins, mas sim o uso delas. O grande mal na minha opinião, é impor o uso de ferramentas por alguém que não esteja envolvido diretamente no processo de produção.

victorcosta:

Algorítmo eu vou direto pro código, nada de diagrama UML, no máximo rascunhos no papel e testes unitários

Sistemas eu estou experimentando uma abordagem que eu mesmo inventei de fazer toda a interface primeiro, sem se preocupar como vai ser implementado o código ou BD. Ainda to no começo mas estou gostando :)

Na prática, essa é a prática de mercado, começar a fazer a interface e partir para as entranhas do sistema. É o que pode ser chamado de desenvolvimento top-down. Mas acho que o seu grande mérito é justamente desenvolver da maneira que você se sente mais à vontade, não há mais nada produtivo do que isso.

Apenas acho que fazer toda a interface primeiro é um grande risco. Não seria melhor desenvolver funcionalidades completas ?

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.

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.

Saoj, concordo um pouco com você, mas acho que um planejamento básico precisa… pelo menos para definir… as cascas… qual framework usar… qual tecnologia usar dependendo do sistema… etc…
Depois parte para a implementação tendo os requisitos macros…
Mas como tudo há excessões… tem casos que realmente precisam de muito planejamento, mas vejo como minoria…

Mas planejamento nenhum também é perigoso… imagina 10 desenvolvedores que saem fazendo o projeto… um deles usa Spring, o outro usa Vraptor, o outro servlet/jsp… o outro resolve criar o módulo dele fazendo uma ponte com asp classic… o outro usa o maker… vira uma zona total!!! Acho que ao menos a questão do que será utilizado… o porque será utilizado (algumas provas de conceito são necessárias neste caso)… e como a casca será feita… (se vai usar MVC… se vai ter DAO… se vai usar Stored Procedure… onde a regra vai ficar, etc…)!

Pior que eu acho do que não planejar… são aqueles que usam milhares de frameworks diferentes, e que muitas vezes não precisava… (e ficam meses planejando onde usar cada pedaço de cada framework da moda)

Já vi sistema que era tanto framework misturado… sendo que podia jogar tudo fora e usar somente o Spring… era tanto conflito… que dava medo!
Eu já não concordo quando muita gente usa o Spring só para DI e IOC… e acaba geralmente usando hibernate e jsf! Penso que o Spring poderia fazer tudo ou se realmente que ficar com hibernate e jsf, poderia usar um picoContainer para DI!

Acho que a explicação dada no livro do Roger Pressman, Engenharia de Software, deixa bem claro algumas coisas importantes no desenvolvimento de software.

Ele fala mais ou menos o seguinte: quais são as etapas para resolver um problema, qualquer problema? Se pararmos para pensar, deveremos chegar na maioria das vezes aos seguintes passos:

1. entender o problema;
2. planejar uma solução;
3. implementar a solução;
4. testar para ver se a solução resolveu o problema.
   Então no desenvolvimento de sistemas acredito que essa é a abordagem ideal.

Se não entendermos o problema, podemos construir uma ótima solução, mas que não resolve o problema correto. Daí a importância dos requisitos. É preciso validar os requisitos com o usuário.

Se não planejarmos uma solução, podemos implementar uma solução e descobrir depois que a essa solução não é adequada - e precisar mudar muita coisa. É verdade que a refatoração permite alterar, mas pode ser muito trabalhoso refatorar, dependendo da quantidade de mudança necessária. Pode ser melhor planejar, projetar um pouco, antes de executar. O tempo gasto compensa na medida em que não é preciso alterar (muito) a solução. É verdade que o projeto nunca é 100% perfeito, sempre precisa alterar um pouco na implementação.

Se não testarmos a solução implementada para procurar erros antes de entregar ao usuário, é ele quem vai achar os erros.

A forma de executar esses passos pode variar muito, aí entram outras discussões sobre metodologias. Mas acho importante segui-los mesmo que não haja um processo formal. Os passos podem ser seguidos de forma iterativa. Os métodos ágeis também têm mecanismos para seguir as etapas acima.

essa eu realmente não entendi …

jmmenezes:

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.

Saoj, concordo um pouco com você, mas acho que um planejamento básico precisa… pelo menos para definir… as cascas… qual framework usar… qual tecnologia usar dependendo do sistema… etc…
Depois parte para a implementação tendo os requisitos macros…
Mas como tudo há excessões… tem casos que realmente precisam de muito planejamento, mas vejo como minoria…

Mas planejamento nenhum também é perigoso… imagina 10 desenvolvedores que saem fazendo o projeto… um deles usa Spring, o outro usa Vraptor, o outro servlet/jsp… o outro resolve criar o módulo dele fazendo uma ponte com asp classic… o outro usa o maker… vira uma zona total!!! Acho que ao menos a questão do que será utilizado… o porque será utilizado (algumas provas de conceito são necessárias neste caso)… e como a casca será feita… (se vai usar MVC… se vai ter DAO… se vai usar Stored Procedure… onde a regra vai ficar, etc…)!

Pior que eu acho do que não planejar… são aqueles que usam milhares de frameworks diferentes, e que muitas vezes não precisava… (e ficam meses planejando onde usar cada pedaço de cada framework da moda)

Já vi sistema que era tanto framework misturado… sendo que podia jogar tudo fora e usar somente o Spring… era tanto conflito… que dava medo!
Eu já não concordo quando muita gente usa o Spring só para DI e IOC… e acaba geralmente usando hibernate e jsf! Penso que o Spring poderia fazer tudo ou se realmente que ficar com hibernate e jsf, poderia usar um picoContainer para DI!

Sim. Eu estava falando de ARQUITETURA, não de frameworks. OO mesmo.

E tb estava falando de um desenvolvedor SOLO. Se vc tem um time, então claro que vai ter haver planejamento, para saber quem vai fazer o que e quais os frameworks que serão utilizados. Claro que antes de comecar vc tem que escolher os frameworks.

Tava falando de arquitetura OO mesmo. Tem gente que gosta de programar em UML. Eu não gosto.

E concordo com VC. Quando menos frameworks melhor. Spring é desnecessário em 95% dos casos.

Veja um exemplo de framework web sem nenhum framework (full-stack): http://www.mentaframework.org

rmendes08:

Os métodos ágeis também têm mecanismos para seguir as etapas acima.

essa eu realmente não entendi …

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.

Eu vejo a modelagem da aplicação como um ponto muito relativo, e que tem mudado muito, aprendi inicialmente a modelar sobre a base, porém sempre achei errado, até que ao começar a desenvolver projetos mais sério(fora da faculdade) me deparei com problemas q mostraram que uma modelagem boa é a mais simples possível que define a regra de negócio e permite a escalabilidade requerida, ou seja, sempre pensar como atender os requisitos funcionais e não funcionais. E por mais perfeita que seja seu projeto inicial, ele vai mudar, etnão o desenvolvimento deve prover uma maneira fácil de se adaptar a pontos que durante o projeto deram a entender que poderiam variar, ou seja, mapear riscos.

Fora isto, desenvolver também vai do modo como voce interage com o time, e do tipo da aplicação. É uma pergunta abstrata demais, tipo, qual linguagem é melhor, sempre vai gerar respostas abstratas, isto até se definir um foco para a pergunta.

Olha a propaganda 8) ! Estou em Chicago também, próximo da W 35th Street.
Desculpe mas não pude deixar de comentar.

Flws.

al.barbosa:

rmendes08:

Os métodos ágeis também têm mecanismos para seguir as etapas acima.

essa eu realmente não entendi …

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.

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.

rmendes08:

al.barbosa:

rmendes08:

Os métodos ágeis também têm mecanismos para seguir as etapas acima.

essa eu realmente não entendi …

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.

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.

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.

CyberX:

saoj:

Veja um exemplo de framework web sem nenhum framework (full-stack): http://www.mentaframework.org

Olha a propaganda 8) ! Estou em Chicago também, próximo da W 35th Street.
Desculpe mas não pude deixar de comentar.

Flws.

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.

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.

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.

1. 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.
2. 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.
3. Implementar a solução - Você leva alguns dias desenvolvendo a solução.
4. 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.

1. 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.
2. 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.
3. Implementar a solução - A solução é implementada em diversas iterações.
4. 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.

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.

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.

AlexandreGama:

Sempre tento implantar um design pattern.

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!

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