Planejar antes de codificar?

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. :wink:

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 :wink:

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 :slight_smile:

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: [/quote]

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…

[quote=InicianteJavaHenrique][quote=rmendes08][quote=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: [/quote]

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. [/quote]

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. :smiley:

:thumbup: [/quote]

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…

[quote=Daniel_MV][quote=InicianteJavaHenrique][quote=rmendes08][quote=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: [/quote]

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. [/quote]

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. :smiley:

:thumbup: [/quote]

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.
[/quote]

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.

[quote=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 :)[/quote]

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.

[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]

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 …

[quote=jmmenezes][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]

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!

[/quote]

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

[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.

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.