Com ganhar expriência na area da Criação e Manutenção de Softwares

27 respostas
D

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.

27 Respostas

Julio_Murta

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.

D

Júlio Murta

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.

fredericomaia10

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.

Enfim, falei demais.

S

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 …

D

fredericomaia10

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.


Enfim, falei demais.

Que nada cara, muito bom conseguir atenção de alguem que se dispõe a ajudar as outras pessoas.

D

Slow17

vou pensar nisso no meu proximo projeto sobre um site de leitura de mangas.

S

Acho que se você fizer todas tabelas do banco e suas relações,não terá problema na hora de codificar as classes…

x111

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!

x111

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!

S

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!

Mas fica bem dificil você desenvolver o sistema sem ter uma minima ideia de como será a persistencia dele no banco de dados…

Julio_Murta

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!

Mas fica bem dificil você desenvolver o sistema sem ter uma minima ideia de como será a persistencia dele no banco de dados…

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.

x111

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!

Mas fica bem dificil você desenvolver o sistema sem ter uma minima ideia de como será a persistencia dele no banco de dados…

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.

Ataxexe

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!

Mas fica bem dificil você desenvolver o sistema sem ter uma minima ideia de como será a persistencia dele no banco de dados…

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.

S

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!

Mas fica bem dificil você desenvolver o sistema sem ter uma minima ideia de como será a persistencia dele no banco de dados…

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.

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.

x111

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!

Mas fica bem dificil você desenvolver o sistema sem ter uma minima ideia de como será a persistencia dele no banco de dados…

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.

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.

Julio_Murta

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!

Mas fica bem dificil você desenvolver o sistema sem ter uma minima ideia de como será a persistencia dele no banco de dados…

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.

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.

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.

S

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!

Mas fica bem dificil você desenvolver o sistema sem ter uma minima ideia de como será a persistencia dele no banco de dados…

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.

Nunca tinha pensado dessa forma,bem interessante,até porque conheço apenas com desenvolvimento de sistemas que fazem consultas em banco de dados…

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.

Geralmente,codifica uma interface para obrigar a classe que irá implementa-la a ter os metodos da interface implementada…

x111

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!

Mas fica bem dificil você desenvolver o sistema sem ter uma minima ideia de como será a persistencia dele no banco de dados…

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.

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.

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.

S

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!

Mas fica bem dificil você desenvolver o sistema sem ter uma minima ideia de como será a persistencia dele no banco de dados…

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.

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.

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.

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?

x111

Slow17:

Na verdade não é nada disso. Deve-se codificar para uma interface e não para uma CLASSE. Isso não tem nada haver com tabela e também não tem a intenção de fazer com que a classe que implementa a interface seja forçada a implementar algo.

A idéia da implementação de interfaces é desacoplar a implementação de uma classe, de modo que ela se torne genérica. Isso é codificar para um interface e não para uma classe. Um exemplo é uma impressora fiscal. Existem diversas impressoras fiscais no mercado com diferentes funcionamentos, porém todas tem como principal funcionalide a impressão de cupons fiscais. O acesso a essa funcionalidade é feita de diversas formas por diferentes impressoras. Se eu quiser usar isso no meu sistema, terei que utilizar uma série de IFs para realizar a impressão de um cupom.

Porém eu posso criar uma interface chamada ImpressoraFiscal com um método imprimirCupom(), por exemplo. Em todos os lugares que seja necessário imprimir um cupom, utiliza-se a interface. Isso desacopla a chamada ao metodo imprimirCupom da sua implementação. Todas as classes que queiram imprimir o cupom utilizam a interface e cada impressora implementa sua forma de impressão do cupom. Se eu quiser adicionar uma nova impressora isso se torna fácil, pois não é necessário alterar o código em todos os lugares que necessitam realizar a impressão.

Julio_Murta

x@ndy:
Slow17:

Na verdade não é nada disso. Deve-se codificar para uma interface e não para uma CLASSE. Isso não tem nada haver com tabela e também não tem a intenção de fazer com que a classe que implementa a interface seja forçada a implementar algo.

A idéia da implementação de interfaces é desacoplar a a implementação de uma classe, de modo que ela se torne genérica. Isso é codificar para um interface e não para uma classe. Um exemplo é uma impressora fiscal. Existem diversas impressoras fiscais no mercado com diferentes funcionamentos, porém todas tem como principal funcionalide a impressão de cupons fiscais. O acesso a essa funcionalidade é feita de diversas formas por diferentes impressoras. Se eu quiser usar isso no meu sistema, ira ter que utilizar uma série de IFs para realizar a impressão de um cupom.

Porém eu posso criar uma interface chamada ImpressoraFiscal com um método imprimirCupom(), por exemplo. Em todos os lugares que seja necessário imprimir um cupom, utiliza-se a interface. Isso desacopla a chamada ao cupom da sua implementação. Todas as classes que queiram imprimir o cupom utilizam a interface e cada impressora implementa sua forma de impressão do cupom. Se eu quiser adicionar uma nova impressora isso se torna fácil, pois não é necessário alterar o código em todos os lugares que necessitam imprimir o código.

x111

Slow17:

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?

Como disse a primeira coisa é entender o que deve-se implementar. Isso é fundamental. Se você vai implementar um modelo de um carro para simulação de consumo de combustivel, deve saber como um carro funciona, para que serve cada peça. Não adianta só saber que depois o carro vai ser usado para transportar pessoas. Agora se você vai implementar um sistema para um radio taxi, o carro vai ter outro papel no modelo, e caracteristicas que interessam a esse papel, nesse cenário. Vai ser necessário entender como funciona uma radio taxi para implementar o sistema.

Depois pode-se criar um modelo de classes, mas um modelo enxuto para organizar as idéias. Esse modelo não tem campos e praticamente não tem métodos. O foco dele deve estar no relacionamento com outras classes. O modelo é um rascunho do sistema e só isso.

Ai começa a implementação, nesse momento vão surgir novas idéias, e modelo que foi feito será alterado, talvez o resultado final seja totalmente diferente do modelo incial esboçado. Isso é muito importante, pois o sistema não deve ser dependente de um modelo previamente executado.

D

voltei aqui não estou mais entendendo é quse nada, mais obrigado ai galera pelomenos fiz um post que não so ajudou a min como está ajudando outras pessoas.

Obrigado a todos.

javaflex

Trabalhar em grupo ou com uma pessoa mais experiência é o melhor caminho. Se ofereça pra ajudar em algum freelance. E nesse processo esteja tranquilo para receber criticas e evoluir com isso.

MarkKnopfler

dsntnow, o que o pessoal está tentando te dizer é que há técnicas para se “modelar” um software. Provavelmente não é possível “entender” tudo de cara, isso deve ser estudado.

Procure estudar sobre:

  • Análise e projeto orientado a objetos
  • Padrões de projeto (design patterns)
  • Desenvolvimento dirigido por testes (TDD - test driven development)

Tudo isso vai te ajudar a “pensar” melhor o software, mas te aviso que terá um tempo de aprendizado até vc dominar tudo.

D


javaflex
Trabalhar em grupo ou com uma pessoa mais experiência é o melhor caminho. Se ofereça pra ajudar em algum freelance. E nesse processo esteja tranquilo para receber criticas e evoluir com isso.

vou procurar alguem…

obrigado pelas dicas agora estou vendo mais claro o que devo estudar.

Ruttmann

Aí que tá o negócio!

Lembro que quando eu fiz o primeiro cursinho de Java, também tinha “sangue no olho” e saía codificando que nem um macaco doido! :stuck_out_tongue:

Outro dia olhava praquilo que fiz e pensava “que porcaria eu fiz aqui?!?”

É normal, principalmente no começo. A gente fica animado com as possibilidades de criação que a linguagem proporciona, temos vontade de fazer tudo o que vem na cabeça, é normal acontecer isso…

O que você precisa agora é estudar um pouco de projetos, ver o que rola antes do serviço chegar na mão do programador.

Comparando meu comportamento de 2 anos atrás pra hoje eu vejo o quanto mudei. Em exercícios da faculdade não é difícil passar mais de meia hora planejando, montando estrutura de classes em UML, anotando tudo, para só depois codificar.

Você vai notar que se passa mais tempo projetando a estrutura e regras de negócio do que codificando. Codificar é só passar o que tá no papel pro computador. E logicamente, se você tem um bom planejamento e principalmente divisão correta de responsabilidades entre as classes, vai ter um código tinindo de lindo! :smiley:

Desenvolver é bem mais que passar o dia inteiro codificando na IDE, tem muito planejamento e estudo antes!

:wink:

Criado 9 de outubro de 2013
Ultima resposta 10 de out. de 2013
Respostas 27
Participantes 9