Olá, há algum tempo estou tendo dificuldades em alguns projetos que inicio, acho que deve ser falta de planejamento(eu apenas começo a digitar e criar classes e arquivos assim do nada do jeito que está sem nenhuma ideia de como vai ser, apenas com a ideia de que vou fazer Software X com funções Y). Quando estou programando chega uma hora em que os codigos não fazem sentido, algumas classes são desnecessárias, varios metodos não tem motivo algum para existir, variaveis que não servem de nada(seria tudo isso normal ?), alguns projetos eu simplesmente não consigo fazer manutenção nem alterar uma simples linha de codigo pq mudaria todo o programa por uma simples besteira. Pois bem, alguem poderia me dizer algum modo de adiquirir alguma expriência para que eu não cometa os mesmo erros, vejo que se eu continuar assim vou entrar em um ciclo vicioso e nunca vou conseguir terminar nada. Eu já não aguento mais começar um projeto e do nada ter que apagar tudo pq o codigo não é mais legivel nem funcional, cansei de fazer gambiarras mesmo sem ter um prazo a comprir. Ouvi dizer que seria uma boa participar de projetos Open-Source(dificil é achar um de um nivel bem baixo que até eu mesmo consiga acompanhar com minha pouca experiência).
Enfim gostaria de alguma dica de o que fazer nessas horas onde não se sabe do seu futuro nessa area tão complicada.
Essa fúria de programar não é algo realmente legal. Acho que no início todo mundo faz isso, só pra ver se é capaz de criar código compiláveis rsrsrs.
Mas o seu problema é justamente falta de ideia e organização. Minha dica: planeje, por mais idiota que seja sua ideia, e só depois codifique. Que seja para ter um simples cadastro de usuários, pense nas operações que serão executadas (inserir, atualizar, consultar, deletar) e pense bem nos dados que irá manter. É um bom treino.
Você já desenvolveu seu projeto de banco de dados na faculdade/curso técnico? Se sim, desenvolva uma aplicação sobre este banco de dados. Acho que é uma ótima ideia também.
sim cara desse jeito, eu também não entro muito em foruns nem nada do gênero deve ser por isso que não tem muita jeito pra coisa, eu apenas pesquiso aleatoriamente algo que me interessa, vou começar a me abrir mais com a comunidade.
eu estudo por conta propria em casa desde o começo do ensino médio, esse ano estou meio parado por alguns motivos pessoais mais tomara que eu consiga uma boa nota no enem e cursarei sistemas da informação em breve.
Em primeiro lugar você não deveria sair escrevendo código sem pensar. Eu sei muita gente faz isso, eu já fiz muito. Mas o que você deve fazer primeiro é pensar no software em um contexto geral. Saia das linhas de código e olhe mais de cima o problema. Resumindo, faça uma análise e se possível um projeto do seu software. Na análise você deve ter os requisitos funcionais (como cadastrar usuário, realizar compra) e não funcionais (como desempenho, segurança…), as regras de negócio e um cronograma. Sim, é difícil fazer tudo isso quando se está criando algum produto sozinho ou com mais 1 ou 2 programadores e principalmente se não temos prazo. Mesmo que não tenha um prazo real, determine um. Também já sofri com isso. Então tenha tudo isso antes de pensar em “como fazer”, pense em “o que” você precisa fazer. Nesta etapa é precisa documentar essas coisas, seja com histórias, casos de uso ou descrições dos requisitos.
No projeto (design) de software, você pensa em “como fazer”. Antes de sair criando classes, crie diagrama de classes, veja com que elas irão se relacionar, se possuem tipos mais genéricos e especializados, se tendem a mudar ou serão mais estáticas, pense em interfaces. Não precisa criar diagramas UML e tudo mais. Mas rabisque, use uma ferramenta online pra criar diagramas de forma que no mínimo você e sua equipe entenda e você tenha uma visão do todo. Nesta hora pense em que frameworks vai utilizar baseado no que já tem de análise e projeto. Como serão suas camadas e a comunicação entre elas. Faça alguns testes com a arquitetura pensada.
Então, seja feliz e programe. Você não precisa pensar no software inteiro pra começar. Isto pode ser incremental, pode ser dividido em módulos e você vai repetindo esse ciclo em um determinado prazo. Se conseguir pensar em boa parte antes, melhor ainda. E saiba que tudo que foi pensado também pode e com certeza vai mudar quando partir pro código. Mas aí você já tem uma visão geral e sabe no que vai impactar e etc. Pesquise um pouco sobre engenharia de software, ao menos para ter uma noção.
Você deveria pegar algum projeto pronto e seguir o padrão desse projeto,
eu tive a sorte de encontrar um professor muito organizado(organizado até demais) e seguir o padrão de projeto dele,
já fiz varios projetos e nenhum deles tive esse seu problema de projeto mal planejado.
Tem por ai varias apostilas também que ensinam em um padrão muito legal (as da caelum) e também tem
alguns usuarios desse forum que disponibilizam projetos em blogs(eu sigo os projetos do Hebert quando programando em jsf).
E sempre é bom você fazer um diagrama antes de codificar,eu faço de mer …
Fazer algo sozinho é dificil mesmo sem ninguem pra lhe criticar ou sem sugestões é meio que complicado. Falando em UML já até dei uma estudada esses dias no UML Caso de uso vou continuar estudando então.
[quote]
Enfim, falei demais.[/quote]
Que nada cara, muito bom conseguir atenção de alguem que se dispõe a ajudar as outras pessoas.
1° Você tem que conhecer bem o modelo que você quer implementar. Por exemplo, se você quer criar um sistema para o gerenciamento de um bar, deve conhecer bem as rotinas utilizadas nele. Isso é mais do que levantar requisitos funcionais e não funcionais, é enteder o funcionamento do negócio para poder implementa-lo.
2º Qual o básico que você tem que implementar para ter o sistema funcionando? Respondendo essa pergunta você já tem o caminho. O problema é que programador adora adicionar firula ao sistema, mas se concentre no que o sistema necessita realmente fazer e descarte qualquer coisa que não seja necessário agora. Deixe o amanhã para amanhã, pois é mais barato criar algo simples e alterar no futuro, caso necessário do que criar algo complexo, cuja a maioria das funcionalidades não serão utilizadas.
3º Utilize TDD, isso vai fazer com que você cria classes pequenas e com baixo acoplamento. Porém, recomendo fortemente que você leia o livro do Evans, TDD - Desenvolvimento Guiado por Testes, pois a maioria do material que você vai encontrar na internet ensina um TDD de botequim, que de TDD não tem nada!
NÃO FAÇA ISSO! Isso não desenvolvimento orientado a objetos. Tabelas não são objetos. Muito cuidado! Deve-se primeiro modelar o sistema e depois criar as tabelas e não ao contrário. O banco de dados deve funcionar como um repositório para os objetos. Contudo, não se esqueça do banco de dados. Nem todo o relacionamento entre objetos pode ser facilmente mapeado para um banco de dados relacional. Deve se pensar também em desempenho, evitando que para realizar um cálculo tenha que se carregar todo o banco de dados para a memória!
NÃO FAÇA ISSO! Isso não desenvolvimento orientado a objetos. Tabelas não são objetos. Muito cuidado! Deve-se primeiro modelar o sistema e depois criar as tabelas e não ao contrário. O banco de dados deve funcionar como um repositório para os objetos. Contudo, não se esqueça do banco de dados. Nem todo o relacionamento entre objetos pode ser facilmente mapeado para um banco de dados relacional. Deve se pensar também em desempenho, evitando que para realizar um cálculo tenha que se carregar todo o banco de dados para a memória![/quote]
Mas fica bem dificil você desenvolver o sistema sem ter uma minima ideia de como será a persistencia dele no banco de dados…
NÃO FAÇA ISSO! Isso não desenvolvimento orientado a objetos. Tabelas não são objetos. Muito cuidado! Deve-se primeiro modelar o sistema e depois criar as tabelas e não ao contrário. O banco de dados deve funcionar como um repositório para os objetos. Contudo, não se esqueça do banco de dados. Nem todo o relacionamento entre objetos pode ser facilmente mapeado para um banco de dados relacional. Deve se pensar também em desempenho, evitando que para realizar um cálculo tenha que se carregar todo o banco de dados para a memória![/quote]
Mas fica bem dificil você desenvolver o sistema sem ter uma minima ideia de como será a persistencia dele no banco de dados…[/quote]
Eu pensava assim antes, mas depois tinha dificuldades pois esquecia vários cenários. Depois que comecei a estudar A&POO entendi que primeiro devem ser pensadas as funcionalidades de um sistema e não suas entidades. Dessa forma você não esquece dos cenários em que o sistema será submetido. Isso na minha opinião, claro.
NÃO FAÇA ISSO! Isso não desenvolvimento orientado a objetos. Tabelas não são objetos. Muito cuidado! Deve-se primeiro modelar o sistema e depois criar as tabelas e não ao contrário. O banco de dados deve funcionar como um repositório para os objetos. Contudo, não se esqueça do banco de dados. Nem todo o relacionamento entre objetos pode ser facilmente mapeado para um banco de dados relacional. Deve se pensar também em desempenho, evitando que para realizar um cálculo tenha que se carregar todo o banco de dados para a memória![/quote]
Mas fica bem dificil você desenvolver o sistema sem ter uma minima ideia de como será a persistencia dele no banco de dados…[/quote]
Por que? Existe sistemas inteiros que não possuem qualquer método de persistência, então por que a persisência é importante? Isso vem do velho modelo que ensinado nas faculdades no qual você tem que fazer o levantamento de requisitos funcionais, não funcionais, depois modelar os dados e ai começar a codificação! Só que assim você não esta modelando um sistema OO, esta implementando uma consulta a dados!
Um sistema OO é um modelo baseado em alguma coisa. Se você quer modelar um carro, vai desenvolver classes que representam cada peça do carro. Porém, se você pensar no carro em termos de banco de dados o que vai sair dali não é um carro, mas um modelo da representação de um carro no banco de dados. Isso é uma péssima prática, baseada em um modelo antigo de análise, que cria uma série de problemas.
NÃO FAÇA ISSO! Isso não desenvolvimento orientado a objetos. Tabelas não são objetos. Muito cuidado! Deve-se primeiro modelar o sistema e depois criar as tabelas e não ao contrário. O banco de dados deve funcionar como um repositório para os objetos. Contudo, não se esqueça do banco de dados. Nem todo o relacionamento entre objetos pode ser facilmente mapeado para um banco de dados relacional. Deve se pensar também em desempenho, evitando que para realizar um cálculo tenha que se carregar todo o banco de dados para a memória![/quote]
Mas fica bem dificil você desenvolver o sistema sem ter uma minima ideia de como será a persistencia dele no banco de dados…[/quote]
Negativo! A persistência não é o ponto crucial do sistema, é o negócio dele (a menos que persistência seja o negócio do sistema - vide um software de banco de dados). O domínio do sistema é que resolve o problema do cliente e não a forma como as tabelas foram modeladas (claro que elas representam uma parte significativa, mas em infraestrutura). Sendo mais direto: os requisitos do sistema não devem ser orientados à sua infraestrutura e, sim, o contrário. Quando você começa pelas tabelas, está amarrando seus requisitos na infraestrutura.
NÃO FAÇA ISSO! Isso não desenvolvimento orientado a objetos. Tabelas não são objetos. Muito cuidado! Deve-se primeiro modelar o sistema e depois criar as tabelas e não ao contrário. O banco de dados deve funcionar como um repositório para os objetos. Contudo, não se esqueça do banco de dados. Nem todo o relacionamento entre objetos pode ser facilmente mapeado para um banco de dados relacional. Deve se pensar também em desempenho, evitando que para realizar um cálculo tenha que se carregar todo o banco de dados para a memória![/quote]
Mas fica bem dificil você desenvolver o sistema sem ter uma minima ideia de como será a persistencia dele no banco de dados…[/quote]
Eu pensava assim antes, mas depois tinha dificuldades pois esquecia vários cenários. Depois que comecei a estudar A&POO entendi que primeiro devem ser pensadas as funcionalidades de um sistema e não suas entidades. Dessa forma você não esquece dos cenário em que o sistema será submetido. Isso na minha opinião, claro.[/quote]
Com certeza,o cara vai pegar o projeto e precisa saber oque esse projeto vai fazer para depois codificar,eu só falei que o cara saber todas as relações do banco de dados vai ajudar ele a desenvolver o projeto,ele sabendo qual tabela está relacionada com outra,ele vai codificar essa relação de acordo com a tecnologia que esteja utilizando,imagina você desenvolver uma aplicação que a principio não tinha relação com tabela,e depois ela passou a ter relação com tabela,dai você tem que modificar o codigo… já aconteceu comigo,sorte que era projeto pequeno.
NÃO FAÇA ISSO! Isso não desenvolvimento orientado a objetos. Tabelas não são objetos. Muito cuidado! Deve-se primeiro modelar o sistema e depois criar as tabelas e não ao contrário. O banco de dados deve funcionar como um repositório para os objetos. Contudo, não se esqueça do banco de dados. Nem todo o relacionamento entre objetos pode ser facilmente mapeado para um banco de dados relacional. Deve se pensar também em desempenho, evitando que para realizar um cálculo tenha que se carregar todo o banco de dados para a memória![/quote]
Mas fica bem dificil você desenvolver o sistema sem ter uma minima ideia de como será a persistencia dele no banco de dados…[/quote]
Eu pensava assim antes, mas depois tinha dificuldades pois esquecia vários cenários. Depois que comecei a estudar A&POO entendi que primeiro devem ser pensadas as funcionalidades de um sistema e não suas entidades. Dessa forma você não esquece dos cenário em que o sistema será submetido. Isso na minha opinião, claro.[/quote]
O caminho é por ai, porém pensar em funcionalidades é meio procedural! Classes são mais que um grupo de funcionalides. Classes tem estado e comportamento! Classes com somente comportamento (funcionalidades) são conhecidas como serviços.
As funcionalidades estão muito relacionadas aos requistos funcionais. Por isso deve-se tomar cuidado. Um modelo OO transcende os requisitos. Existe uma série de relacionamentos e operações entre classes que devem ser modeladas e que não são especificadas pelas funcionalidades do sistema. Por isso que é tão importante entender o négócio, para somente depois implementa-lo.
NÃO FAÇA ISSO! Isso não desenvolvimento orientado a objetos. Tabelas não são objetos. Muito cuidado! Deve-se primeiro modelar o sistema e depois criar as tabelas e não ao contrário. O banco de dados deve funcionar como um repositório para os objetos. Contudo, não se esqueça do banco de dados. Nem todo o relacionamento entre objetos pode ser facilmente mapeado para um banco de dados relacional. Deve se pensar também em desempenho, evitando que para realizar um cálculo tenha que se carregar todo o banco de dados para a memória![/quote]
Mas fica bem dificil você desenvolver o sistema sem ter uma minima ideia de como será a persistencia dele no banco de dados…[/quote]
Eu pensava assim antes, mas depois tinha dificuldades pois esquecia vários cenários. Depois que comecei a estudar A&POO entendi que primeiro devem ser pensadas as funcionalidades de um sistema e não suas entidades. Dessa forma você não esquece dos cenário em que o sistema será submetido. Isso na minha opinião, claro.[/quote]
Com certeza,o cara vai pegar o projeto e precisa saber oque esse projeto vai fazer para depois codificar,eu só falei que o cara saber todas as relações do banco de dados vai ajudar ele a desenvolver o projeto,ele sabendo qual tabela está relacionada com outra,ele vai codificar essa relação de acordo com a tecnologia que esteja utilizando,imagina você desenvolver uma aplicação que a principio não tinha relação com tabela,e depois ela passou a ter relação com tabela,dai você tem que modificar o codigo… já aconteceu comigo,sorte que era projeto pequeno.[/quote]
Acho que não. Os módulos ou classes de um sistema devem ser livremente unidos, até para facilitar incrementos futuros. O correto seria codificarmos para uma interface, e não para uma tabela. É claro que eu ainda sou apenas um iniciante, e que ainda não consigo colocar muitas dessas boas ideias em prática. Mas estou lutando por isso.
NÃO FAÇA ISSO! Isso não desenvolvimento orientado a objetos. Tabelas não são objetos. Muito cuidado! Deve-se primeiro modelar o sistema e depois criar as tabelas e não ao contrário. O banco de dados deve funcionar como um repositório para os objetos. Contudo, não se esqueça do banco de dados. Nem todo o relacionamento entre objetos pode ser facilmente mapeado para um banco de dados relacional. Deve se pensar também em desempenho, evitando que para realizar um cálculo tenha que se carregar todo o banco de dados para a memória![/quote]
Mas fica bem dificil você desenvolver o sistema sem ter uma minima ideia de como será a persistencia dele no banco de dados…[/quote]
Por que? Existe sistemas inteiros que não possuem qualquer método de persistência, então por que a persisência é importante? Isso vem do velho modelo que ensinado nas faculdades no qual você tem que fazer o levantamento de requisitos funcionais, não funcionais, depois modelar os dados e ai começar a codificação! Só que assim você não esta modelando um sistema OO, esta implementando uma consulta a dados!
Um sistema OO é um modelo baseado em alguma coisa. Se você quer modelar um carro, vai desenvolver classes que representam cada peça do carro. Porém, se você pensar no carro em termos de banco de dados o que vai sair dali não é um carro, mas um modelo da representação de um carro no banco de dados. Isso é uma péssima prática, baseada em um modelo antigo de análise, que cria uma série de problemas.[/quote]
Nunca tinha pensado dessa forma,bem interessante,até porque conheço apenas com desenvolvimento de sistemas que fazem consultas em banco de dados…
[quote=Júlio Murta]
Acho que não. Os módulos ou classes de um sistema devem ser livremente unidos, até para facilitar incrementos futuros. O correto seria codificarmos para uma interface, e não para uma tabela. É claro que eu ainda sou apenas um iniciante, e que ainda não consigo colocar muitas dessas boas ideias em prática. Mas estou lutando por isso.[/quote]
Geralmente,codifica uma interface para obrigar a classe que irá implementa-la a ter os metodos da interface implementada…
NÃO FAÇA ISSO! Isso não desenvolvimento orientado a objetos. Tabelas não são objetos. Muito cuidado! Deve-se primeiro modelar o sistema e depois criar as tabelas e não ao contrário. O banco de dados deve funcionar como um repositório para os objetos. Contudo, não se esqueça do banco de dados. Nem todo o relacionamento entre objetos pode ser facilmente mapeado para um banco de dados relacional. Deve se pensar também em desempenho, evitando que para realizar um cálculo tenha que se carregar todo o banco de dados para a memória![/quote]
Mas fica bem dificil você desenvolver o sistema sem ter uma minima ideia de como será a persistencia dele no banco de dados…[/quote]
Eu pensava assim antes, mas depois tinha dificuldades pois esquecia vários cenários. Depois que comecei a estudar A&POO entendi que primeiro devem ser pensadas as funcionalidades de um sistema e não suas entidades. Dessa forma você não esquece dos cenário em que o sistema será submetido. Isso na minha opinião, claro.[/quote]
Com certeza,o cara vai pegar o projeto e precisa saber oque esse projeto vai fazer para depois codificar,eu só falei que o cara saber todas as relações do banco de dados vai ajudar ele a desenvolver o projeto,ele sabendo qual tabela está relacionada com outra,ele vai codificar essa relação de acordo com a tecnologia que esteja utilizando,imagina você desenvolver uma aplicação que a principio não tinha relação com tabela,e depois ela passou a ter relação com tabela,dai você tem que modificar o codigo… já aconteceu comigo,sorte que era projeto pequeno.[/quote]
Novamente porque? Se for em um sistema procedural, orientadado a dados blz. Mas em um sistema OO isso não é valido. Em um sistema OO ele deveria analisar um diagrama de classes nunca um diagram ER. Em um sistema OO ideal, o modelo deveria ser desvinculado do sistema de persistencia, de modo que seja possível mudar o sistema de persistência sem mudar o modelo. Da forma como você coloca, você acopla o sistema de persistência ao modelo tornando-o extremamente depende.
Existem muitos projeto legados com essa abordagem. Porém iniciar um novo projeto dessa forma é um equivoco.
NÃO FAÇA ISSO! Isso não desenvolvimento orientado a objetos. Tabelas não são objetos. Muito cuidado! Deve-se primeiro modelar o sistema e depois criar as tabelas e não ao contrário. O banco de dados deve funcionar como um repositório para os objetos. Contudo, não se esqueça do banco de dados. Nem todo o relacionamento entre objetos pode ser facilmente mapeado para um banco de dados relacional. Deve se pensar também em desempenho, evitando que para realizar um cálculo tenha que se carregar todo o banco de dados para a memória![/quote]
Mas fica bem dificil você desenvolver o sistema sem ter uma minima ideia de como será a persistencia dele no banco de dados…[/quote]
Eu pensava assim antes, mas depois tinha dificuldades pois esquecia vários cenários. Depois que comecei a estudar A&POO entendi que primeiro devem ser pensadas as funcionalidades de um sistema e não suas entidades. Dessa forma você não esquece dos cenário em que o sistema será submetido. Isso na minha opinião, claro.[/quote]
Com certeza,o cara vai pegar o projeto e precisa saber oque esse projeto vai fazer para depois codificar,eu só falei que o cara saber todas as relações do banco de dados vai ajudar ele a desenvolver o projeto,ele sabendo qual tabela está relacionada com outra,ele vai codificar essa relação de acordo com a tecnologia que esteja utilizando,imagina você desenvolver uma aplicação que a principio não tinha relação com tabela,e depois ela passou a ter relação com tabela,dai você tem que modificar o codigo… já aconteceu comigo,sorte que era projeto pequeno.[/quote]
Novamente porque? Se for em um sistema procedural, orientadado a dados blz. Mas em um sistema OO isso não é valido. Em um sistema OO ele deveria analisar um diagrama de classes nunca um diagram ER. Em um sistema OO ideal, o modelo deveria ser desvinculado do sistema de persistencia, de modo que seja possível mudar o sistema de persistência sem mudar o modelo. Da forma como você coloca, você acopla o sistema de persistência ao modelo tornando-o extremamente depende.
Existem muitos projeto legados com essa abordagem. Porém iniciar um novo projeto dessa forma é um equivoco.[/quote]
Entendi,realmente o codigo fica muito dependente do banco de dados da maneira que eu imaginava um sistema,mas então o ideal seria oque? pensar em quais diagramas primeiro? no diagrama de classe e de caso de usos? qual seria a ordem de planejamento do projeto?