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 programa, 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 ?
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:
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=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 ?[/quote]
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
[quote=AlexandreGama][quote]
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.
[/quote]
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 ;)[/quote]
permito sim, rsrsrsrsrs, mas não penso como vc
[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.
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!
[quote=AlexandreGama][quote]
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.
[/quote]
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 ;)[/quote]
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.
[quote=AlexandreGama][quote]
permito sim, rsrsrsrsrs, mas não penso como vc
[/quote]
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![/quote]
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 ,
[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.
:thumbup:
Exatamente! Não só inevitável como saudável. O que seria do Refactoring se não pudessemos modificar um código existente…
[quote=AlexandreGama][quote]
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.
[/quote]
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![/quote]
É outra visão válida
:thumbup:
Confesso que também verifico de vez em quando. Na dúvida, é sempre bom dar uma verificada
[quote=AlexandreGama]
Você pode modelar o seu código e criar em runtime as suas tabelas…
Abs![/quote]
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