Dicas para Reestruturação de projeto
Hoje surgiu a idéia de reescrever completamente um produto aqui da empresa.
Gostaria de compartilhar idéias com os demais usuários sobre isso.
O produto que vai ser reescrito foi desenvolvido 100¬ por estagiários, nenhum sabia programar, todos apreenderam a programar com esse projeto, inclusive eu.
O programa é em 3 camadas com borland socket server (client-server), mas o grande problema é que a aplicação servidora só executa os SQL, não tem nenhuma regra de negócio no servidor, tudo é feito no cliente, ou seja o servidor está ai só pra atrapalhar.
Agora, depois de entender os conceitos de POO, me dá vontade se jogar tudo no lixo e começar do zero, mas isso não é possível, pois temos vários clientes, que por incrível que pareça estão bem satisfeitos, pois o programa é bom, mas é muito ruim dar manutenção nele.
Idéias que temos para nova versão:
Orientação a objetos.
Suporte a diversos BD (firebird, mySql, SQLServer...)
Versão para linux
Gostaria de receber idéias. Ahh reclamar de como foi feito é mais do que permitido, mas passado é passado, o objetivo é o presente para um futuro melhor.
Gostaria de compartilhar idéias com os demais usuários sobre isso.
O produto que vai ser reescrito foi desenvolvido 100¬ por estagiários, nenhum sabia programar, todos apreenderam a programar com esse projeto, inclusive eu.
O programa é em 3 camadas com borland socket server (client-server), mas o grande problema é que a aplicação servidora só executa os SQL, não tem nenhuma regra de negócio no servidor, tudo é feito no cliente, ou seja o servidor está ai só pra atrapalhar.
Agora, depois de entender os conceitos de POO, me dá vontade se jogar tudo no lixo e começar do zero, mas isso não é possível, pois temos vários clientes, que por incrível que pareça estão bem satisfeitos, pois o programa é bom, mas é muito ruim dar manutenção nele.
Idéias que temos para nova versão:
Orientação a objetos.
Suporte a diversos BD (firebird, mySql, SQLServer...)
Versão para linux
Gostaria de receber idéias. Ahh reclamar de como foi feito é mais do que permitido, mas passado é passado, o objetivo é o presente para um futuro melhor.
Diegotiemann
Curtidas 0
Respostas
Osocram
11/09/2009
Ola.
Espero que até março de 2010 possamos fazer isso tbm.
Imagine que que o pessoal que ja trabalhou aqui antes, alguns começaram sua carreira aqui (os que começaram o projeto), então ta uma blz, sem comentarios, cheio de metodos alternativos (POG), sem documentação nenhum, sem DER e algumas tabelas sem relacionamento.
Estou fazendo um outro sistema que vai ter q integrar com esse banco ja existente, e ja esta sendo ruim por causa da falta de relacionamente e um padrão p criar tabelas e campos.
Faço a minha programação bastante coisa OOP, não é 100¬. Tenho mto o que aprender ainda. Mas é so fazendo que se aprende.
Qto a flexibilidade de banco aqui é uma perda de tempo, pois os clientes vão usar o que agente falar p usar. Isso não é algo a ser discutido. Mas mesmo assim o outro sistema usa componentes p MySql e o que eu estou fazendo usa DBExpress assim posso conectar em qq banco. Mas tem que tomar cuidado para não usar nada especifico do seu banco, ou melhor ainda usar uma classe que trata isso p vc.
Versão p Linux acho que não é possivel, pelo menos com o delphi não. (Pelo menos eu não sei como)
Espero que até março de 2010 possamos fazer isso tbm.
Imagine que que o pessoal que ja trabalhou aqui antes, alguns começaram sua carreira aqui (os que começaram o projeto), então ta uma blz, sem comentarios, cheio de metodos alternativos (POG), sem documentação nenhum, sem DER e algumas tabelas sem relacionamento.
Estou fazendo um outro sistema que vai ter q integrar com esse banco ja existente, e ja esta sendo ruim por causa da falta de relacionamente e um padrão p criar tabelas e campos.
Faço a minha programação bastante coisa OOP, não é 100¬. Tenho mto o que aprender ainda. Mas é so fazendo que se aprende.
Qto a flexibilidade de banco aqui é uma perda de tempo, pois os clientes vão usar o que agente falar p usar. Isso não é algo a ser discutido. Mas mesmo assim o outro sistema usa componentes p MySql e o que eu estou fazendo usa DBExpress assim posso conectar em qq banco. Mas tem que tomar cuidado para não usar nada especifico do seu banco, ou melhor ainda usar uma classe que trata isso p vc.
Versão p Linux acho que não é possivel, pelo menos com o delphi não. (Pelo menos eu não sei como)
GOSTEI 0
Diegotiemann
11/09/2009
O nosso programa também usa DBexpress, como você falou os nossos clientes também vão usar o banco que nós definirmos, mas já que vai ser refeito tudo, estamos estudando essa possibilidade, porque senão daqui a 5 anos vamos estar pensando ´que merda porque não projetamos isso aqui melhor, porque agora precisamos usar o banco XXXX´.
Tipo essas são nossas dúvidas vale a pena esse trabalho? Ou é melhor definir um banco e usar os recursos que ele oferece?
A clube delphi deste mês fala de Aplicações multi-banco, mas ainda não consegui ler o artigo.
E 3 camadas, ou n-tier, vale a pena? Nossos clientes são em sua maioria usuários domésticos, 10¬ são empresas dentre elas só uma acessa o programa via internet.
Tipo essas são nossas dúvidas vale a pena esse trabalho? Ou é melhor definir um banco e usar os recursos que ele oferece?
A clube delphi deste mês fala de Aplicações multi-banco, mas ainda não consegui ler o artigo.
E 3 camadas, ou n-tier, vale a pena? Nossos clientes são em sua maioria usuários domésticos, 10¬ são empresas dentre elas só uma acessa o programa via internet.
GOSTEI 0
Afarias
11/09/2009
|O nosso programa também usa DBexpress, como você falou os nossos
|clientes também vão usar o banco que nós definirmos,
DBExpress permite que a aplicação seja multi-banco. Basta que vc tome os cuidados para isto e use o driver específico do banco
|porque senão daqui a 5 anos vamos estar pensando ´que merda porque
|não projetamos isso aqui melhor, porque agora precisamos usar o banco
|XXXX´.
Daqui a 5 anos seu código vai ser uma m* por melhor q vc faça hoje ;-)
|Tipo essas são nossas dúvidas vale a pena esse trabalho? Ou é melhor
|definir um banco e usar os recursos que ele oferece?
Esta é sempre uma escolha difícil, mas geralmente que não vale o desgaste de pensar muito nela (principalmente se escolher um bom banco).
Aplicações OO ou em camadas acabam tornando a aplicação multi-banco. Minhas aplicações em camadas são multi-banco. As demais não são, mas acaba q em 10 anos nunca precisei mudar o banco mesmo...
|E 3 camadas, ou n-tier, vale a pena? Nossos clientes são em sua maioria
|usuários domésticos, 10¬ são empresas dentre elas só uma acessa o
|programa via internet.
Camadas é ótimo! Mas para usuários domésticos ou empresas pequenas, poucos usuários e tals eu acho q apenas adiciona complexidade sem grandes ganhos.
No seu caso acho q seguir práticas OO seria mais importante que implementar em 3-camadas.
O problemas fica apenas quanto ao acesso via internet. Neste caso vc resolveria com um ´túnel seguro´ ou uma VPN ou terminal remoto.
De qualquer forma, só vc e sua equipe pode mesmo decidir, visto que envolve muitos detalhes (técnicos e comerciais/de mercado) q só vcs dominam.
Meu conselho aqui é apenas o seguinte: REFAZER do zero é uma m* ... parece atraente e a melhor coisa a fazer mas geralmente não é.
Então, se puder apenas ir MELHORANDO o que vc já tem (REFACTORING... REFACTORING... REFACTORING... ), é uma opção bem melhor
T+
|clientes também vão usar o banco que nós definirmos,
DBExpress permite que a aplicação seja multi-banco. Basta que vc tome os cuidados para isto e use o driver específico do banco
|porque senão daqui a 5 anos vamos estar pensando ´que merda porque
|não projetamos isso aqui melhor, porque agora precisamos usar o banco
|XXXX´.
Daqui a 5 anos seu código vai ser uma m* por melhor q vc faça hoje ;-)
|Tipo essas são nossas dúvidas vale a pena esse trabalho? Ou é melhor
|definir um banco e usar os recursos que ele oferece?
Esta é sempre uma escolha difícil, mas geralmente que não vale o desgaste de pensar muito nela (principalmente se escolher um bom banco).
Aplicações OO ou em camadas acabam tornando a aplicação multi-banco. Minhas aplicações em camadas são multi-banco. As demais não são, mas acaba q em 10 anos nunca precisei mudar o banco mesmo...
|E 3 camadas, ou n-tier, vale a pena? Nossos clientes são em sua maioria
|usuários domésticos, 10¬ são empresas dentre elas só uma acessa o
|programa via internet.
Camadas é ótimo! Mas para usuários domésticos ou empresas pequenas, poucos usuários e tals eu acho q apenas adiciona complexidade sem grandes ganhos.
No seu caso acho q seguir práticas OO seria mais importante que implementar em 3-camadas.
O problemas fica apenas quanto ao acesso via internet. Neste caso vc resolveria com um ´túnel seguro´ ou uma VPN ou terminal remoto.
De qualquer forma, só vc e sua equipe pode mesmo decidir, visto que envolve muitos detalhes (técnicos e comerciais/de mercado) q só vcs dominam.
Meu conselho aqui é apenas o seguinte: REFAZER do zero é uma m* ... parece atraente e a melhor coisa a fazer mas geralmente não é.
Então, se puder apenas ir MELHORANDO o que vc já tem (REFACTORING... REFACTORING... REFACTORING... ), é uma opção bem melhor
T+
GOSTEI 0
Diegotiemann
11/09/2009
Meu conselho aqui é apenas o seguinte: REFAZER do zero é uma m* ... parece atraente e a melhor coisa a fazer mas geralmente não é.
Então, se puder apenas ir MELHORANDO o que vc já tem (REFACTORING... REFACTORING... REFACTORING... ), é uma opção bem melhor
Bem lembrado, eu esqueci de comentar:
=>No ano que vem precisamos lançar uma nova versão do programa, isso pq nossos contratos são de dois anos e estão vencendo, dai se tivermos uma nova versão, podemos vender essa nova versão pro cliente, se não tivermos nova versão ele só vai continuar pagando mensalidade.
Dai entra a questão, como preparar uma nova versão, sem liberar pro cliente. Separar os fontes? Mas se na versão atual forem corrigidos bugs, vou ter que alterar nos fontes da versão velha e assim vai. (chute trabalhei dessa maneira)
Estamos pensando em reescrever justamente por causa da necessidade de lançar uma nova versão. Já estamos melhorando o programa a um tempão, mas assim o cliente não percebe que é uma nova versão.
E outra, poucos formulários usam herança, pra implementar herança vamos ter que alterara formulário por formulário e acho que não vai ficar bom.
GOSTEI 0
Osocram
11/09/2009
O melhor seria poder ir fazendo os Refactoring. Quando possivel.
Mas no caso aqui da empresa eu acho impossivel, ou melhor dizendo, mais trabalho do que refazer do zero.
1) não tem herança de cadastro nem um padrão visual, ja desenvolvi um framework aqui para um outro projeto e estamos testando, assim que ficar OK iremos refazer esse sistema usando esta framework
2) esta em SDI tudo com showmodal, quero passar para MDI
3) foi feito uma logica mto confusa, onde tem mto acoplamento, tem uma unit que criarão p poder chamar de qualquer form, até ae tudo certo. So que adicionaram no uses dessa unit quase todos os forms, pois em vez de passar umas variaveis como parametro nos metodos eles fazem referencia ao proprio form.
O dilema que encontramos agora, tempo para fazer a manutenção, o que não é pouco, apesar de estavel, não travar o cliente, da muita manutenção, e tempo para terminar o outro projeto.
Então decidimos eu vou tocando o outro projeto sozinho e o outro na manutenção, e la pelo mes de março esperamos que de uma estabilizada e assim vamos refazer. Pois precisamos de um tempo p aprendermos as regras de negocios tbm, já que somos novos aqui na empresa
XD
Tudo de bom.
Mas no caso aqui da empresa eu acho impossivel, ou melhor dizendo, mais trabalho do que refazer do zero.
1) não tem herança de cadastro nem um padrão visual, ja desenvolvi um framework aqui para um outro projeto e estamos testando, assim que ficar OK iremos refazer esse sistema usando esta framework
2) esta em SDI tudo com showmodal, quero passar para MDI
3) foi feito uma logica mto confusa, onde tem mto acoplamento, tem uma unit que criarão p poder chamar de qualquer form, até ae tudo certo. So que adicionaram no uses dessa unit quase todos os forms, pois em vez de passar umas variaveis como parametro nos metodos eles fazem referencia ao proprio form.
O dilema que encontramos agora, tempo para fazer a manutenção, o que não é pouco, apesar de estavel, não travar o cliente, da muita manutenção, e tempo para terminar o outro projeto.
Então decidimos eu vou tocando o outro projeto sozinho e o outro na manutenção, e la pelo mes de março esperamos que de uma estabilizada e assim vamos refazer. Pois precisamos de um tempo p aprendermos as regras de negocios tbm, já que somos novos aqui na empresa
XD
Tudo de bom.
GOSTEI 0
Osocram
11/09/2009
esqueci de comentar...
Sobre o banco eu não acho que vale o trabalho deixar multibanco.
Vc usando o DBExpress ja é um grande passo p mudar de banco.
E pense que de tempos em tempos vc tem q reescrever o sistema dae vc ja tem um bom motivo. Pelo menos eu acho que uma forma de evoluir seu sistema é amadurecendo a regra de negocio, dae vc refaz , mas isso depende de mtas outras coisas, é o que queremos fazer aqui.
Por isso queremos deixar o sistema mais OOP, assim poderemos ir fazendo Refactory em vez de refazer tudo do zero.
Sobre o banco eu não acho que vale o trabalho deixar multibanco.
Vc usando o DBExpress ja é um grande passo p mudar de banco.
E pense que de tempos em tempos vc tem q reescrever o sistema dae vc ja tem um bom motivo. Pelo menos eu acho que uma forma de evoluir seu sistema é amadurecendo a regra de negocio, dae vc refaz , mas isso depende de mtas outras coisas, é o que queremos fazer aqui.
Por isso queremos deixar o sistema mais OOP, assim poderemos ir fazendo Refactory em vez de refazer tudo do zero.
O nosso programa também usa DBexpress, como você falou os nossos clientes também vão usar o banco que nós definirmos, mas já que vai ser refeito tudo, estamos estudando essa possibilidade, porque senão daqui a 5 anos vamos estar pensando ´que merda porque não projetamos isso aqui melhor, porque agora precisamos usar o banco XXXX´.
Tipo essas são nossas dúvidas vale a pena esse trabalho? Ou é melhor definir um banco e usar os recursos que ele oferece?
A clube delphi deste mês fala de Aplicações multi-banco, mas ainda não consegui ler o artigo.
E 3 camadas, ou n-tier, vale a pena? Nossos clientes são em sua maioria usuários domésticos, 10¬ são empresas dentre elas só uma acessa o programa via internet.
GOSTEI 0
Diegotiemann
11/09/2009
Ossocram,
Aqui na empresa a situação é a mesma, não tem padrão visual. se quiser mudar a cor do programa, ou a imagem de um botão, tem que passar form por form.
Acho que esse tópico vai nos ajudar um monte, pois acho que muita gente já passou por isso e deve ter uma dica para nos passar.
Mas no caso aqui da empresa eu acho impossivel, ou melhor dizendo, mais trabalho do que refazer do zero.
1) não tem herança de cadastro nem um padrão visual, ja desenvolvi um framework aqui para um outro projeto e estamos testando, assim que ficar OK iremos refazer esse sistema usando esta framework
Aqui na empresa a situação é a mesma, não tem padrão visual. se quiser mudar a cor do programa, ou a imagem de um botão, tem que passar form por form.
Acho que esse tópico vai nos ajudar um monte, pois acho que muita gente já passou por isso e deve ter uma dica para nos passar.
GOSTEI 0
Osocram
11/09/2009
Ja que estamos no mesmo barco.
Eu penso assim...
Vamos começar a mapear as regras de negócios de todas as telas, que tem no programa. E tbm as regras de negócios que realmente deveria ter. Pois pode ser que qdo foi feito não tinham todos os recursos que temos agora, e a visão de programação agora tbm é diferente.
É bom ir preparando essas coisas antes de começar a refazer pois senão vai perder mto tempo depois.
Seria interessante fazer um cronograma tbm.
Aqui na empresa a situação é a mesma, não tem padrão visual. se quiser mudar a cor do programa, ou a imagem de um botão, tem que passar form por form.
Acho que esse tópico vai nos ajudar um monte, pois acho que muita gente já passou por isso e deve ter uma dica para nos passar.[/quote:b3cf6c9277]
Eu penso assim...
Vamos começar a mapear as regras de negócios de todas as telas, que tem no programa. E tbm as regras de negócios que realmente deveria ter. Pois pode ser que qdo foi feito não tinham todos os recursos que temos agora, e a visão de programação agora tbm é diferente.
É bom ir preparando essas coisas antes de começar a refazer pois senão vai perder mto tempo depois.
Seria interessante fazer um cronograma tbm.
Ossocram,
[quote:b3cf6c9277]Mas no caso aqui da empresa eu acho impossivel, ou melhor dizendo, mais trabalho do que refazer do zero.
1) não tem herança de cadastro nem um padrão visual, ja desenvolvi um framework aqui para um outro projeto e estamos testando, assim que ficar OK iremos refazer esse sistema usando esta framework
Aqui na empresa a situação é a mesma, não tem padrão visual. se quiser mudar a cor do programa, ou a imagem de um botão, tem que passar form por form.
Acho que esse tópico vai nos ajudar um monte, pois acho que muita gente já passou por isso e deve ter uma dica para nos passar.[/quote:b3cf6c9277]
GOSTEI 0
Pestana_
11/09/2009
A questão de se fazer um refinamento no código ou começar do zero, isso depende de cada caso, pode ser que para o osocram seja mais indicado que se faça um refatoramento no código e para o diego o ídeal seria o começar do zero, ou vice-versa ou para ambos eu não sei...
Quando se faz um refatoramento e quando se começa do zero? pelo os meus conhecimentos eu só começo um projeto do zero quando a maior parte do código (candidato a refatoração) esteja em um nível de complexidade muito grande para que seja feito um refinamento, ou seja, fazendo um refinamento no código é mais trabalhoso e complexo do que se começar do zero, se você tem muitas partes no código para se refatorar talvez o indicado seja comerçar do zero, caso contrario, se você indentificar que se fazendo um refatoramento seja mais rápido, menos trabalhos e que contenha poucas partes do código candidatos a refatoração, então refatoramento seja o melhor caminho.
Isso é uma assunto em que você e sua equipe de trabalho deve decidir qual é a melhor abordagem para ser aplicado!
Opinião minha, o DER é muito importante, isso não pode faltar no projeto, como o osocram citou que o projeto não tem o DER. A minha indicação seria que isso seja feito em primeira mão, antes de fazer qualquer coisa no Delphi. Faça uma engenharia reversa, logo em seguida normalize o DER (caso seja necessário) depois parta para o Delphi.
bom as minhas dicas estão ai, espero que alguma coisa possa ser útil.
boa sorte nesta caminhada!!!
Quando se faz um refatoramento e quando se começa do zero? pelo os meus conhecimentos eu só começo um projeto do zero quando a maior parte do código (candidato a refatoração) esteja em um nível de complexidade muito grande para que seja feito um refinamento, ou seja, fazendo um refinamento no código é mais trabalhoso e complexo do que se começar do zero, se você tem muitas partes no código para se refatorar talvez o indicado seja comerçar do zero, caso contrario, se você indentificar que se fazendo um refatoramento seja mais rápido, menos trabalhos e que contenha poucas partes do código candidatos a refatoração, então refatoramento seja o melhor caminho.
Isso é uma assunto em que você e sua equipe de trabalho deve decidir qual é a melhor abordagem para ser aplicado!
Opinião minha, o DER é muito importante, isso não pode faltar no projeto, como o osocram citou que o projeto não tem o DER. A minha indicação seria que isso seja feito em primeira mão, antes de fazer qualquer coisa no Delphi. Faça uma engenharia reversa, logo em seguida normalize o DER (caso seja necessário) depois parta para o Delphi.
bom as minhas dicas estão ai, espero que alguma coisa possa ser útil.
boa sorte nesta caminhada!!!
GOSTEI 0
Diegotiemann
11/09/2009
O nosso projeto tem o DER, mas também é só isso.
Acho que no meu caso a melhor coisa é começar do zero pois, não tem nada, mas nada mesmo orientado a objeto no sistema, teremos que refaturar tudo, então considero melhor começar do zero.
Na clube delphi (109) tem um artigo do Guinter Pauli, falando sobre OO, só que essa primeira parte ainda está muito didática, ele ainda não chegou a por implementar os conceitos de OO em um sistema com formulários de cadastro. Herança, polimorfismo, encapsulamento estou cansado de estudar na na faculdade (java), mas nunca usei isso na prática na prática.
Se alguém puder me enviar as classes de um cadastro de cliente por exemplo (formulário, classe, DTO...) para que eu posso ver como isso realmente funciona.
Acho que no meu caso a melhor coisa é começar do zero pois, não tem nada, mas nada mesmo orientado a objeto no sistema, teremos que refaturar tudo, então considero melhor começar do zero.
Na clube delphi (109) tem um artigo do Guinter Pauli, falando sobre OO, só que essa primeira parte ainda está muito didática, ele ainda não chegou a por implementar os conceitos de OO em um sistema com formulários de cadastro. Herança, polimorfismo, encapsulamento estou cansado de estudar na na faculdade (java), mas nunca usei isso na prática na prática.
Se alguém puder me enviar as classes de um cadastro de cliente por exemplo (formulário, classe, DTO...) para que eu posso ver como isso realmente funciona.
GOSTEI 0
Pestana_
11/09/2009
Eu sempre digo que a melhor métodologia é aquela que você domina!
Eu entendo pouco sobre OO na teoria, tenho esperiência com o método estruturada, então no meu caso a melhor métodologia seria a estruturada!
Digo isso, porque imagine se você tem pouco conhecimento sobre OO e pretende aplicar no projeto, certamente o seu sistema corre o risco de não utilizar totalmente os recursos de OO ou deixar o seu sistema muito Acoplado e futuramente você vai gastar tempos e tempos com refatoração de código (manutenção), custos e por ai vai... Eu não quero ser pessímista eu só queria que você entendesse bem o que eu disse no primeiro paragrafa!
Agora se você deseja e tem vontade de aplicar a métodologia OO no seu projeto, então ´estude muito´ para cometer o minimo de erros no seu projeto, caso contrario, continue com a métodologia Estruturada.
Como você citou que esta querendo construir um novo sistema, então esta ai uma boa oportunidade de aperfeiçoar os conceitos de OO e comecar aplicar neste novo projeto!
boa sorte!
Eu entendo pouco sobre OO na teoria, tenho esperiência com o método estruturada, então no meu caso a melhor métodologia seria a estruturada!
Digo isso, porque imagine se você tem pouco conhecimento sobre OO e pretende aplicar no projeto, certamente o seu sistema corre o risco de não utilizar totalmente os recursos de OO ou deixar o seu sistema muito Acoplado e futuramente você vai gastar tempos e tempos com refatoração de código (manutenção), custos e por ai vai... Eu não quero ser pessímista eu só queria que você entendesse bem o que eu disse no primeiro paragrafa!
Agora se você deseja e tem vontade de aplicar a métodologia OO no seu projeto, então ´estude muito´ para cometer o minimo de erros no seu projeto, caso contrario, continue com a métodologia Estruturada.
Como você citou que esta querendo construir um novo sistema, então esta ai uma boa oportunidade de aperfeiçoar os conceitos de OO e comecar aplicar neste novo projeto!
boa sorte!
GOSTEI 0
Diegotiemann
11/09/2009
Agora se você deseja e tem vontade de aplicar a métodologia OO no seu projeto, então ´estude muito´ para cometer o minimo de erros no seu projeto, caso contrario, continue com a métodologia Estruturada.
Estou estudando bastante. Eu ainda sou novo (20 anos) tenho só dois anos de experiência em programação procedural. Agora na faculdade estamos estudando OO em java, entendi os conceitos perfeitamente bem, agora estou indo atrás pesquisando como implantar isso realmente na prática, com banco de dados relacional, mas estou encontrando muita dificuldade, quase todo material de OO só fala do básico, é muito difícil (não impossível) encontrar algo sobre como ligar os formulários ao modelo de classe. (Atualmente estou estudando o MVC, mas os exemplos que encontrei são muito pobres e ainda não atendem minha necessidade). [/code]
GOSTEI 0
Pestana_
11/09/2009
é isso ai diego, pé na tábua, continue estudando! Sobre OO eu fico devento, porque tambem conheço muito pouco. Voce citou alguma coisa sobre banco de dados, precisando ajuda sobre DER é só entrar em contato que estarei ajudando na medida do possível!
Acredito que os colegas do fórum possam te ajudar você sobre OO!
Acredito que os colegas do fórum possam te ajudar você sobre OO!
GOSTEI 0
Diegotiemann
11/09/2009
Estive lendo o artigo Aplicações Win32 com MVC - Rodrigo Mourão da edição 102 da Clube Delphi.
Achei bem interressante e explicativo, pena que ele explica como fazer a implementação com DAO.
Se alguém souber onde posso encontrar algo interressante sobre DAO, agradeço.
Achei bem interressante e explicativo, pena que ele explica como fazer a implementação com DAO.
Se alguém souber onde posso encontrar algo interressante sobre DAO, agradeço.
GOSTEI 0
Diegotiemann
11/09/2009
Estudando ou melhor trabalhando para fazer a reestruturação do sistema me deparei com um problema no together.
Abaixo o link do tópico, onde explico o problema que estou enfrentando:
http://forum.devmedia.com.br/viewtopic.php?t=102181
Abaixo o link do tópico, onde explico o problema que estou enfrentando:
http://forum.devmedia.com.br/viewtopic.php?t=102181
GOSTEI 0
Carlosfim
11/09/2009
Caro diegotiemann,
Como você pediu idéias, vou dar algumas. Já de antemão gostaria de frisar que são apenas ´idéias´, não tenho o intuito de provar que são as melhores.
Vamos a elas:
Freqüentemente precisamos reestruturar nossos softwares aqui na empresa. Já observamos que, por mais bem feito que o sistema seja, sua evolução natural acaba deteriorando a qualidade, demandando sempre de refatoração. Para não ter que ficar sempre refazendo seu sistema ´do zero´, recomendo a divisão deste em componentes.
NÃO CONFUNDA COMPONENTES VISUAIS (BOTÕES, EDITS, ETC) COM COMPONENTIZAÇÃO!
Entenda como componente uma estrutura fechada, com uma interface bem definida, que interage com o meio externo apenas através desta interface. Este componente pode ser um simples objeto (a interface deste componente seria seus métodos e propriedades públicas), um conjunto de objetos com uma interface comum, um pacote, uma dll, enfim, qualquer estrutura que encapsule o comportamento interno e exponha suas funcionalidades através de uma interface bem definida.
Definindo os componentes e suas fronteiras (interfaces), você poderá refatorar, ou mesmo refazer, cada um dos componentes de maneira individual. Isso vai permitir que você:
- Evolua seu sistema gradativamente
- Diminua o impacto de mudanças futuras
- Gerencie melhor os projetos de manutenção, reestruturação, etc
- Reutilize alguns componentes em outros projetos
- Facilite os testes, entre outras.
Uma boa solução seria criar uma camada de acesso a dados: esta camada estaria entre o DB e o resto da sua aplicação. Desta forma, independente do banco que você vier a utilizar, caso seja necessário realizar alguma alteração, você só irá precisar atualizar esta camada.
Aqui na empresa desenvolvemos uma camada de acesso a dados utilizando IBX. Esta camada é utilizada por 5 de nossos sistemas, e TODAS as comunicações com o banco de dados são realizadas através dela. Qualquer erro que surgir com relação ao banco de dados, ou quando quisermos mudar de banco, esta será a única camada na qual precisaremos trabalhar.
Usar herança de cadastros (User interfaces) não significa usar orientação a objetos: ´pensar orientado a objetos´ é que trará os benefícios reais para o seu projeto. Ao invés de se preocupar se você está usando ou não todos os conceitos OO (herança, polimorfismo, ...), preocupe-se com as seguintes questões:
- Como posso facilitar a manutenção do meu software?
- Como posso desenvolver as partes mais desacopladas possível?
- Como posso simplificar o entendimento do meu código, para mim e para os outros?
- Como posso evitar o retrabalho e/ou promover o reuso de partes do sistema, dentro do mesmo ou fora dele?
Estas são as verdadeiras questões. OO, camadas, componentes, programação estruturada ou qualquer que seja o ´nome bonito´ devem ser as respostas, e não as perguntas.
Às vezes questões simples como métodos bem definidos, nomes de variáveis inelegíveis, programação defensiva e bom senso são mais do que suficientes para construir um software de ótima qualidade.
Espero ter contribuído com alguma coisa!
[/code]
Como você pediu idéias, vou dar algumas. Já de antemão gostaria de frisar que são apenas ´idéias´, não tenho o intuito de provar que são as melhores.
Vamos a elas:
Hoje surgiu a idéia de reescrever completamente um produto aqui da empresa.
Gostaria de compartilhar idéias com os demais usuários sobre isso.
Freqüentemente precisamos reestruturar nossos softwares aqui na empresa. Já observamos que, por mais bem feito que o sistema seja, sua evolução natural acaba deteriorando a qualidade, demandando sempre de refatoração. Para não ter que ficar sempre refazendo seu sistema ´do zero´, recomendo a divisão deste em componentes.
NÃO CONFUNDA COMPONENTES VISUAIS (BOTÕES, EDITS, ETC) COM COMPONENTIZAÇÃO!
Entenda como componente uma estrutura fechada, com uma interface bem definida, que interage com o meio externo apenas através desta interface. Este componente pode ser um simples objeto (a interface deste componente seria seus métodos e propriedades públicas), um conjunto de objetos com uma interface comum, um pacote, uma dll, enfim, qualquer estrutura que encapsule o comportamento interno e exponha suas funcionalidades através de uma interface bem definida.
Definindo os componentes e suas fronteiras (interfaces), você poderá refatorar, ou mesmo refazer, cada um dos componentes de maneira individual. Isso vai permitir que você:
- Evolua seu sistema gradativamente
- Diminua o impacto de mudanças futuras
- Gerencie melhor os projetos de manutenção, reestruturação, etc
- Reutilize alguns componentes em outros projetos
- Facilite os testes, entre outras.
O nosso programa também usa DBexpress, como você falou os nossos clientes também vão usar o banco que nós definirmos, mas já que vai ser refeito tudo, estamos estudando essa possibilidade, porque senão daqui a 5 anos vamos estar pensando ´que merda porque não projetamos isso aqui melhor, porque agora precisamos usar o banco XXXX´.
Uma boa solução seria criar uma camada de acesso a dados: esta camada estaria entre o DB e o resto da sua aplicação. Desta forma, independente do banco que você vier a utilizar, caso seja necessário realizar alguma alteração, você só irá precisar atualizar esta camada.
Aqui na empresa desenvolvemos uma camada de acesso a dados utilizando IBX. Esta camada é utilizada por 5 de nossos sistemas, e TODAS as comunicações com o banco de dados são realizadas através dela. Qualquer erro que surgir com relação ao banco de dados, ou quando quisermos mudar de banco, esta será a única camada na qual precisaremos trabalhar.
1) não tem herança de cadastro nem um padrão visual, ja desenvolvi um framework aqui para um outro projeto e estamos testando, assim que ficar OK iremos refazer esse sistema usando esta framework
Usar herança de cadastros (User interfaces) não significa usar orientação a objetos: ´pensar orientado a objetos´ é que trará os benefícios reais para o seu projeto. Ao invés de se preocupar se você está usando ou não todos os conceitos OO (herança, polimorfismo, ...), preocupe-se com as seguintes questões:
- Como posso facilitar a manutenção do meu software?
- Como posso desenvolver as partes mais desacopladas possível?
- Como posso simplificar o entendimento do meu código, para mim e para os outros?
- Como posso evitar o retrabalho e/ou promover o reuso de partes do sistema, dentro do mesmo ou fora dele?
Estas são as verdadeiras questões. OO, camadas, componentes, programação estruturada ou qualquer que seja o ´nome bonito´ devem ser as respostas, e não as perguntas.
Às vezes questões simples como métodos bem definidos, nomes de variáveis inelegíveis, programação defensiva e bom senso são mais do que suficientes para construir um software de ótima qualidade.
Espero ter contribuído com alguma coisa!
[/code]
GOSTEI 0