Arquitetura: tentativas, sugestões

Bom, parece normal para mim :thumbup:
Está usando as patterns VO, DAO e Command. Que tal tirar o VO dali?

O meu arrepio comecou aqui.

Desenvolver um framework ANTES de desenvolver uma aplicacao nao da certo: ou voce acaba com a aplicacao tendo que fazer gambiarras em cima do framework, ou a aplicacao nao sai ate mudarem o framework. Eh melhor fazer uma aplicacao primeiro, refatorar ela e tirar os pedacos genericos e transformar num framework do que tentar advinhar o que eh generico e o que nao eh. Alias, risque a palavra advinhar do dicionario.

Rafael Nunes:

Pelo que andei conversando com o Philip, o cv, e lendo vários posts daqui e outras coisas mais, modelei mais ou menos como vai ser a arquitetura, gostaria de sugestões e/ou críticas vossas:

Vou ter um objeto que será a base para toda regra de negócio. Ele vai seguir uma sequência de inicialização, execução e finalização, que toda regra de negócio deverá implementar para seguir tal regra. EM outras palavras, vou ter uma interface com três métodos abstratos: init(), execute() e finalize(), e todo Business Object deverá implementar esta interface, e seus métodos.
Vou ter uma camada de DAO, utilizando um objeto padrão(DAOFactory) para as operações básicas de persistência, e esta camada DAO é quem fará a comunicação com a camada de persistência em si. Provavelmente Hibernate ou Entity Beans.

Bom, algumas observacoes:

• O que acontece se o objeto nao puder seguir o padrao init/execute/finalize?

• Por que um objeto de negocios - que trata de uma regra de negocio especifica - vai ter que implementar uma interface alien dessa, que modela coisas que sao inicializaveis, executaveis e paraveis, sem necessariamente serem inicializaveis, executaveis ou paraveis?

• Por que ter uma “camada” de DAOs se voce nem sabe de que tipo de persistencia e nem de que tipo de queries voce precisa?

• finalize() eh um metodo que ja tem na java.lang.Object e serve pra outra coisa. Voce vai ter que arrumar outro nome :mrgreen:

E, como uma imagem vale mil palavras, eis a minha descricao mais completa da sua arquitetura ate agora:

Habla chico…

Segundo isso, você deve ter objetos assim:

AdicionarUsuarioBO
RemoverUsuarioBO
editarUsuarioBO

Certo?

Se isso é verdade, me diz qual a diferença entre isso e um design procedural com funções com os mesmos nomes? (nota: esse excesso de Commands é sintoma de uso de Struts… acertei?)

Antes de pensar nas ações tomadas pelo sistema, pense nos objetos do sistema. Ops, problema aí: como pensar em objetos de sistemas futuros?

Fazer um framework tão genérico e manter boas práticas não é muito fácil… mais fácil você manter umf ramework vertical, sobre aquilo que sua emrpesa costuma ldiar (objetos relacionados ao negócio).

Se você trabalha com telecom, por exemplo, provavelmente vai conseguir ter uns objetos Assinante, BaseTerrestre, blablabla reutilizáveis, mas eles vêm com o tempo

Acho que você está se preocupando muito com o RAD da coisa

cv, se ele decidiu usar a Pattern Command, é necessário ter um interface comum a todos os comandos, não é?

E Rafael, apesar dos exelentes comentários de ambos, não se desespere, o jeito que você fez é melhor do que muita coisa por aí.

Sobre o comentário do cv sobre fazer a solução antes de surgir o problema, esclareço uma coisa a você: MVC não é um framework. Desenvolver uma maneira padrão para comunicação entre as camadas poderia ser um framework.

Aliás, tem certeza que não há algo pronto no mercado para a necessidade de vocês? Se o objetivo é produção e não aprendizado, há o Genesis.

Olá

Rafael Nunes:

Aqui no trampo vamos desenvolver um ‘framework’ pra servir de padrão no desenvolvimento de todos aplicativos(são todos pra uso próprio).

1. Suponho que além do obrigatório e basico Effective Java, você leu os 2 livros do Rod Johnson e percebeu claramente o trampo que virá pela frente.

2. É óbvio que você conhece muito bem os patterns Template Method, Strategy, Command, FrontController, ServiceToWorker e outros mais.

3. Tenho a certeza que você já estudou e usou muito os frameworks atuais como Struts, Webwork e Spring

4. Por fim você realmente precisa reinventar a roda.

Se respondeu sim a todas as 4 afirmações então siga em frente e boa sorte.

[]s
Luca

Sim, o ponto eh que Command != Business Object… Command eh um metodo transformado em classe, pra poder ser tratado com uma granularidade um pouco diferente, ou quando voce tem parametros meio confusos e quer simplificar a coisa. Usar esse pattern pra “representar tudo” eh meio pisada de bola (de novo, olhem pra foto do cachorro) - e eh um dos defeitos do Prevayler, inclusive.

Sem duvida. So de voce ter parado pra pensar e perguntar sobre isso ja torna o mundo um lugar melhor. :mrgreen:

Rafael,

O CV disse tudo:

Todo o framework tem um determinado nível de “genericidade”, ou seja, ele é generico e configurável até certo ponto. Como o framework é para a sua empresa e nada mais, eu sugiro vc criar o framework fortemente acoplado as decisões da sua empresa.

Lembre-se que se acontecer alguma mudança nessas decisões, alguém da sua empresa pode alterar o framework em nível de código fonte. Vc não precisará criar inúmeros arquivos de configuração para utilizar o framework, e com isso, você ganha muito tempo de desenvolvimento.

Em outras palavras, fazer coisas genéricas nem sempre é a melhor saída, porque, além de esperar por uma mudança que talvez nunca aconteça, é possível que o código ainda esteja errado.

Como disse o CV, crie o seu framework ao longo do tempo em que desenvolve o sistema. Assim que detectar que algo pode ser “genérico” você o faz e separa dos fontes da aplicação.

Refactoring é a palavra mágica

Hun, deixa eu dividir por partes então.
Acho mais fácil situar-me primeiro. Onde trabalho é uma Universidade, logo, tudo que for desenvolvido é pra uso próprio. Já respondendo a última proposição do Lipe, usar algo terceiro está fora de cogitação, o que eles querem mesmo é desenvolver um framework, um padrão que deverá ser seguido por todas aplicações aqui desenvolvidas.

O VO que se refere é o Controller?
Bem o sistema aqui é distribuído, os .jsp ficam em máquina separada dos .class. Iremos usar um Session Bean para comunicação entre a View e o restante da aplicação, sendo que não conheço maneira mais simples de comunicação RMI. Aliás, eu consigo conversar com o Hibernate através de RMI?

Bingow, é exatamente isso!!!O que estamos querendo é um padrão para comunicação E desenvolvimento.

Rafael Nunes:

O VO que se refere é o Controller?
Bem o sistema aqui é distribuído, os .jsp ficam em máquina separada dos .class. Iremos usar um Session Bean para comunicação entre a View e o restante da aplicação, sendo que não conheço maneira mais simples de comunicação RMI. Aliás, eu consigo conversar com o Hibernate através de RMI?

JSP longe dos .class?

Isso me diz que você está usando JSP como se fosse ASP, e isso por si só já é um problema

(aliás, conceitualmente isso não é possível, já que suas JSP viram .class )

Passando ao próximo passo, sua camada de View não deve contatar a camada onde o Hibernate está localizado, para isso coloque uma camada de modelo/negócios no meio.

Nessa camada ficam os objetos de domínio, para acessá-la você pode até utilizar um Stateless Session Bean se estiverem em computadores diferentes, ams não faça isso se não souber quando NÃO utilizar um EJB

Logo, não tem proque voc~e acessar o hibernate, DAOs e etc. pela View, se você precisar colocar sua camada de persistência numa máquina diferente, é outro papo, mas aidna assim a comunicação é entre a camada do meio e a de persistência

É exatamente isso Carlos, queremos criar por exemplo um padrão para todas aplicações por exemplo conversarem com o banco. Estamos entre duas opções, Hibernate e Entity Beans. Ou seja, toda aplicação, ou todo processo que quiser conversar com o banco, deverá passar pelo DAO e este conversará com o Hibernate/Entity

Como assim?Isto não será por objeto, e sim por caso de uso, os métodos serão na verdade preCondicoes(), execute() e posCondicoes(). Onde serão responsáveis respectivamente por executar pré condições antes do caso de uso, executá-lo em si, e alguma tarefa que deva ser executada após a sua finalização.

A persistência será Hibernate ou Entity Beans, o que não quero e creio que não seria recomendável, é dentro do meu objeto de negócio chamar diretamente os métodos do Hibernate/Entity

Na verdade o nome dele é posCOndicoes(). É que não quis estragar a surpresa… ;o)

Luca:

1. Suponho que além do obrigatório e basico Effective Java, você leu os 2 livros do Rod Johnson e percebeu claramente o trampo que virá pela frente.

Na verdade só o FrontController, que é o que usamos aqui hoje.

Struts e Webwork sim, mas acho meio complicado implementar eles pras necessidades que temos aqui.

O que ando um pouco receoso é de usar uma porrada de frameworks e componentes terceiros e acabar tendo de ajustar minhas aplicações pras necessidades deles.

pcalcado:

JSP longe dos .class?
Isso me diz que você está usando JSP como se fosse ASP, e isso por si só já é um problema
(aliás, conceitualmente isso não é possível, já que suas JSP viram .class )

É exatamente isso que eu tentei fazer com meus Business Objects e DAO´s.

Hoje já utilizamos o Session Bean pra isso, e provavelmente é o que continuaremos a utilizar, pois não encontrei maneira mais fácil.

Acho que não me expliquei direito. É exatamente isso que não quero fazer, convesar diretamente minha View com minha camada de persistência. Por isso que coloquei os BO e DAO´s. E provavelmente teremos a camada de persistência em uma outra máquina e pra isso acho que será mais Session Beans pra conversar DAO com Persistência

uhhhmmm… Rafael, acho que antes de mais nada, você precisa entender o conceito de “Domain Model” de uma aplicação:

http://www.martinfowler.com/eaaCatalog/domainModel.html

E um dos problemas que causam Domain Models ruins:

(quantas vezes esse link já foi dado no GUJ?)

Vou dar uma lida nestes artigos.(O que provavelmente vai me obrigar a abrir uma outra thread pra tirar as dúvidas que certamente terei).

Só para mim, acho que você já recomendou umas 10 vezes esse link…

Edit:
A impresão que tenho olhando essa pseudo-arquitetura que fiz, é que posso gerar um enorme trabalho desnecessário, ou engessar demais o desenvolvimento das aplicações, como o cachorro do cv. Mas é só uma impressão, tipo que eu to sempre esquecendo algo quando saio pra viajar. Talvez sim, talvez não.

Quanto a JSP numa máquina e “.class” em outra não faz a menor diferença. Basta apontar o form da sua JSP para o Servlet correto na outra máquina.

Cacete, isso que é especialização, Lipe! Eu quero ter um servidor de config files também :mrgreen:

Isso me cheira uma serviço para TOP (Table oriented programming).

Alguém já ouviu falar ?

É que neste caso, ao menos na estrutura da aplicação que ja tem rodando aqui, os servlets estão na mesma máquina do JSP, o que está em máquina diferente são os EJB´s e Business Objects.

Não tem uma thread aqui no guj sobre isso?

Esse negóciod e tabelas é engraçado… vamos colcoar tudo em tabelas e as manipular! Claro, mas… não é isso que programas estruturados fazem com registros, struts, resultsets, datasets…?

hehe Shoes

Rafael, então realmente precisa de uma estrutura de comunicação. EJBs fazem o serviço para você, mas se quiser, pode dar uma olhada no DualRpc.
Pode resolver o seu problema com muito mais facilidade.

O Business Delegate não pode ficar na mesma máquina que os JSP/Servlets e invocar os EJB´s via JNDI que aponta pra outra máquina?

Pra que DualRpc?

É que aqui tá sobrando dinheiro e máquinas, então provavelmente terão uma máquina pros servlets e jsp´s; uma máquina pros Business Object e DAO´s, e uma outra máquina pra persistência.
Talvez tenham uma pra jogar paciência nos horários de folga… ;o)

Ao invés de EJBs.

LIPE:

Ao invés de EJBs.

Invés de RMI, tu diz, né?

Tudo a mesma coisa.

Lipe, que está sempre certo.

:XD:

Padrões, Java, J2EE, EJB, Hibernate, Patterns, Domain Model, Anemic Domain Model, DualRPC…

Estou considerando seriamente a possibilidade de ir pro interior vender patos e javali. Aliás, carne de javali é bem saborosa, interessa?

hehe Rafael, por isso simplesmente falei que seu plano parecia bom. Quando começa a entrar nesse mundo, melhor ir devagar, sem se preocupar tanto. Tenha consciência que quanto mais estudar, mais nojo vai ter do código que escreveu.

Por isso, sendo contrário ao que falaram, atenha-se ao seu plano básico. Mas saiba que, sem a experiência necessária, é bastante improvável que saia um framework do seu trabalho todo; é mais provável surgir uma solução completamente engessada e fedida (como aconteceu comigo). E tudo bem! Já que é para aprendizado, se esbalde com seus erros

Felizmente disso eu tenho consciência, que daqui há alguns meses ou anos, vou achar esta minha solução uma afronta a moral e bons costumes. Mas de alguma forma eu tenho de começar.

E em todo caso, sempre haverão patos e javalis… ;o)

Sinceramente, não faz sentido fazer um framework do zero a menos que você esbarre em um problema que não foi resolvido de forma satisfatória. Se você não pode usar outros frameworks, não pode usar Hibernate também e, lógico que isso não faz o menor sentido. Assim como escrever um framework do zero por escrever…

Michael, um framework pode ser a soma de outros frameworks também oras. Contudo, considerando isso, tem razão sobre o uso deles; o Rafael poderia muito bem usar Webwork de um lado, a parte de comunicação do Genesis no meio e Hibernate no fim.

Mas aí o aprendizado seria bem menor. Pense nos pobres patinhos :mrgreen:

Nunca disse que não Ele é que mencionou antes nessa thread que não podia usar frameworks de terceiros. Isso que quis enfatizar: não faz sentido não usar! Inclusive, a melhor solução a longo prazo sempre acaba sendo construir um framework em cima de outros frameworks que você usa nos seus projetos. Mas isso só pode ser feito após alguns projetos

o Rafael poderia muito bem usar Webwork de um lado, a parte de comunicação do Genesis no meio e Hibernate no fim.

Mas aí o aprendizado seria bem menor

Não. Depende do que você quer aprender. Se você faz tudo no braço (inclusive a persistência), você aprende as coisas no nível mais baixo, mas a tendência é que sua “overall architecture” seja uma porcaria. E, no dia a dia, é (geralmente) muito mais importante que você saiba escrever uma solução clara e fácil de manter, não a que é mais eficiente que o Hibernate, por exemplo.

Tava considerando aqui a utilização de um framework tipo Webwork, pra fazer o controle. Mas acho que ele iria gerar um trabalho desnecessário.
O que ele faria é simplesmente direcionar as chamadas da View pra camada dos Business Object. Aí lá vinha mais bibliotecas, mais xml, mais configuração, e isso eu poderia resolver com um simples servlet, estou errado?

Só um comentário sobre o uso indiscriminado do padrão Command, e o sistema altamente procedural resultante.

Eu conheço um certo sistema produzido com algo muito próximo dessa estrutura que você sugeriu, só que ele usa Session Beans como os “business objects” do framework que vc fez.

Resultado? Hoje existem quase 400 Session Beans, cada um faz uma coisa apenas (adiciona usuário, remove usuário), o deployment descriptor é ilegível (ok, nenhum descriptor é lá muito legível…) e simplesmente não escala.

Hoje a gente já tem um ERP aqui que utiliza esse pattern Command. Utiliza Session Bean também, porém os Session Beans utilizam um Façade, só implementam um método que chama um business object.
E temos um Session Bean por módulo, por exemplo, um Session Bean pra módulo financeiro, um Session Bean pra módulo acadêmico, outro pra relatório.
Ao invés de termos um Session Bean pra cada caso de uso, temos um Session Bean com milhares de métodos, e esses chamam os objetos de negócio.

Ps:Tá muito ‘procedural’ esta arquitetura?

Ao invés de EJBs.

Você ainda pode usar JNDI com classes simples no Container. Não Pode?

Olá

Rod Johnson, autor de J2EE Design and Development, um dos melhores livros de arquitetura J2EE que conheço e cujo capítulo 4 é de leitura obrigatória para todo cara que pretende escrever código Java além do Hello World. Ele escreveu também J2EE Development without EJB e é o criador do Spring.

Rod Johnson:

Why (and How) Not to reinvent the Wheel

São cerca de cinco páginas dizendo o que o CV já disse, que eu repeti e o Michael corroborou.

Eu sou tão fã do Rod Johnson que vou afirmar o seguinte: assim como alguns dizem que programador Java que nunca leu Effective Java tem grande chance de escrever código merda e ilegível, arquiteto de sistemas que nunca leu Rod Johnson tem grande chance de criar sistemas dificeis de manter e extender (como casas que não servem para morar).

E finalmente os patterns que citei são os mínimos necessários para escrever um framework meia boca. Se você não conhece Template Method e Strategy tem grande chance de também nunca ter ouvido falar em inversão de controle. O Service To Worker é como o Command é usado pelos frameworks para preparar a resposta dinâmica para a camada de apresentação. A importância de conhece-lo bem é para não usar Dispatcher View que viola o MVC.

[]s
Luca

Grato, vou dar uma olhada nesses patterns.

Eu acho que acabei usando o termo errado, creio eu que o que estou fazendo não é bem um framework, é tipo criar um padrão, um contrato para o desenvolvimento das aplicações internas.
Andei reavaliando o esquema todo, e me incomodou um pouco esta estrutura de Command, de toda regra que negócios ter de seguir um fluxo herdado da interface. Mas me incomoda mais ainda deixar o desenvolvimento dos objetos de negócio a esmo, não criar um contrato para isso. Principalmente porque a maioria dos programadores são ou vieram do mundo procedural, o que eu queria era tipo obrigá-los a programar OO(sim, eu sei que é bem difícil eu conseguir isso se não houver um comprometimento deles, e não, ameaças de morte/demissão/desconto de salário não são viáveis neste caso).

Alguma sugestão?

Rafael Nunes:

Grato, vou dar uma olhada nesses patterns.

Eu acho que acabei usando o termo errado, creio eu que o que estou fazendo não é bem um framework, é tipo criar um padrão, um contrato para o desenvolvimento das aplicações internas.
Andei reavaliando o esquema todo, e me incomodou um pouco esta estrutura de Command, de toda regra que negócios ter de seguir um fluxo herdado da interface. Mas me incomoda mais ainda deixar o desenvolvimento dos objetos de negócio a esmo, não criar um contrato para isso. Principalmente porque a maioria dos programadores são ou vieram do mundo procedural, o que eu queria era tipo obrigá-los a programar OO(sim, eu sei que é bem difícil eu conseguir isso se não houver um comprometimento deles, e não, ameaças de morte/demissão/desconto de salário não são viáveis neste caso).

Alguma sugestão?

Matá-los’:?:’

talvez fosse interesante mostrar porque eles deveriam aprender OO?
em que esta padronização sua melhoraria todo o processo?
E a você se realmente é necessária uma mudança nesse sentido?

Caso consiga algum volutário depois disso
pode iniciar com eles, com o tempo os demais vão se juntando ao grupo.

A gente trabalha com uma plataforma OO, não faria sentido programar proceduralmente com ela.

Hoje temos uma equipe de 9 programadores, todos vieram e ainda programam em tecnologias procedurais. O problema é que hoje na hora do desenvolvimento, cada um cria as classes, os objetos a esmo. Acha o jeito mais fácil ou mais cômodo de fazer e sair criando classes e métodos. Pode imaginar como está a arquitetura e manutenção desta aplicação?

Sim, pelos motivos acima.

Uma sugestão que pode ajudar em casos assim, mas não é todo mundo que pode, é contratar um consultor especializado.

Só cuidado com picaretas, e essa é a parte difícil em contratar um consultor. Desconfie de muitas siglas de empresas e certificações pop.

A sugestao do Kiviano eh otima, mas esconder os corpos eh sempre uma tarefa ingrata. O que voce pode fazer eh uma workshopzinha rapida de Test-Driven Development, e rejeitar qualquer codigo no CVS que nao tenha um teste unitario provando que ele deve existir, e que ele funciona. Enfase no “provando que ele deve existir”, por favor.

Demora uma ou duas semanas pra montar um sistema de build automatizado que toma conta disso pra voce, caso voce nao tenha nenhuma experiencia com a coisa (de uma olhada no DamageControl, CruiseControl e CruiseControl.NET).

Isso, por si so, ja aumenta a qualidade do codigo - mesmo que seja uma porcaria nao-OO, pelo menos voce sabe se funciona ou nao inspecionando os testes unitarios, e como tem sempre uma base de testes por perto, fica facil refatorar e fazer a coisa mais OO.

Outro esquema que pode ajudar bastante eh se livrar de metade das maquinas da sala, e botar todo mundo pra fazer pair programming. Assim, a comunicacao na equipe aumenta, e a troca de conhecimentos e aprendizados se agiliza. Dai, ja que voce ta fazendo integracao continua e pair programming, mesmo, aproveite pra dar uma lida sobre XP, e adapte as ideias que mais convierem (ou force aqueles que decidem esse tipo de coisa a adota-las. Armas apontadas pra cabeca do individuo e/ou familiares dele geralmente resolvem essas decisoes com uma eficacia incrivel)

Samuel esnobe diz que nao demora nao :mrgreen:

Montei o ambiente em 4 dias com DamageControl, Maven, CVS e Eclipse. Ficou bem legal (servidor HPUX rodando DC e Maven, repositorio central do Maven para desenvolvedores e servidor, CVS em outro servidor e Eclipse para desenvolvimento) … recomendo, o trabalho de manutencao é incrivelmente baixo (quase nulo) depois que estiver tudo redondo.

smota, quer tentar “implantar” essa idéia aqui? PVT-me.

Rafael Nunes:

Sim, pelos motivos acima.

Fiz as indagações porque hoje há um grande BOOM entorno de OO,
Padrões, e bla bla, e ta cheio de especialistas nisso

Aqui mesmo quando aparece um cara querendo saber fazer uma
jsp + servlet, ja aparecem vários experts mandando o cara estudar padrões,
que isso ta erado, que aquilo ta á errado.

PS: foi ironia mesmo…

Enfim, você nunca vai chegar a usar padrões se não sabe OO,
e isso vale para seus desenvolvedores.
A curva de aprendizado é muito ingrime, e quando você chegar ao topo dela,
vai olhar pra baixo e dizer “putz, subi um degrau”,
ai quando tiver chegando no segundo vai olhar pra traz e dizer "putz, meu primeiro degrau não suporta o segundo"
vamos reestudar, refatorar, reeaprender, e assim o ciclo segue.

Só queria atentar ao fato de que não use OO, não use, Padrões,
não use qualquer coisa se não tiver certeza de que no futuro vai agregar algum valor,
e se não souber o que está fazendo.

Do contrário continuará programando estruturalmetne o resto da vida mesmo usando Java.
Ou acham que quem usa Java obrigatoriamente programa OO?

é preciso tomar cuidado quando se diz vamos programar OO,
maravilha, somos fodas, ai agente põe uns padrõezinhos aqui e
ali e fica show. Que show : ))

no mais estude OO(sempre), padrões(sempre), e atentando ao fato de que sempre mudam, e que NÃO deve adotar a idéia de alguém completamente, mesmo este sendo O CARA, formule as suas idéias, e proponha novas idéias.

PS2: saiu uma redação
PS3: foi um desabafo sim

Uma coisa que eu já vi funcionar e não é tão radical quanto a idéia do cv é atrelar o resultado do programador a métricas de software.

Diga que existe uma limite X para LOC/método, metodos/classe, atributos/classe, complexidade ciclomática e violações da lei de Demeter.

O código inicial vai ser caótico, mas em pouco tempo ou cai a ficha que sem OO não vai para frente ou explode.

louds:

Uma coisa que eu já vi funcionar e não é tão radical quanto a idéia do cv é atrelar o resultado do programador a métricas de software.

Diga que existe uma limite X para LOC/método, metodos/classe, atributos/classe, complexidade ciclomática e violações da lei de Demeter.

O código inicial vai ser caótico, mas em pouco tempo ou cai a ficha que sem OO não vai para frente ou explode.

isso não cairia numa prática de métodologia agil chamada refactoring?

Em um outro projeto a gente colocou isso no CVS… um commit demorava alguns minutinhos, pq ele tinha que analisar o codigo antes de aceitar o commit, mas valia a pena. O codigo so entrava no CVS se, e somente se, ele nao tivesse nenhum problema com sintaxe, imports inuteis, nenhum warning nem utilizacao de metodo ou API deprecada. Depois, a gente foi deixando a coisa mais divertida: nenhum commit passava se o codigo tivesse alguma dependencia circular, ou se o cliente usasse classes do servidor (ele tinha que falar com o servidor atraves do pacote de classes comuns), e todos os arquivos .java tinham que ter o copyright e a licenca no topo.

Quando alguem pegava uma classe pra editar que violasse algum desses requisitos, tinha que arrumar ou nao fazia commit. Em 6 semanas o codigo tava lindinho de novo

Kivanio, sei que há uma certa tendência em modismo a querer aplicar OO em tudo. Sei que ainda falta muuuito, mas muito a se estudar, porém de algum lugar tenho de começar, se for deixar pra usar este tipo de coisa quando for um expert, creio que ainda passaremos uns bons anos produzindo lixo. Concorda?

Quanto a dica do Phillip de contratatr um consultor eu cheguei a cogitar, porém foi refutada no primeiro comentário que fiz. Por um lado é ruim pois sei que vou quebrar muito a cabeça pra resolver coisas simples que poderiam ser resolvidas sem tanta burocracia, por outro creio que vai ser bom porque ou eu aprendo alguns padrões, ou aprendo como não utilizar certos padrões, de qualquer forma, aprendo.

Quanto ao build no CVS que o cv dugeriu, nós usamos o Source Safe , vou tentar adaptar alguma dessas ou outra ferramenta nele, foi bem legal a idéia.

Rafael Nunes:

Quanto ao build no CVS que o cv dugeriu, nós usamos o Source Safe , vou tentar adaptar alguma dessas ou outra ferramenta nele, foi bem legal a idéia.

Concordo, mas cuidado para não criar um clima ruim, deixe claro os propósitos da ferramenta, antes que alguém coloque um desenho seu como alvo de tachinhas no banheiro

Aproveita, entra numa clínica dessas por aí, isntala o Subversion e larga as drogas Esse Microsoft SourceSafado ninguém merece!

Hun, creio que deu pra amadurecer um pouco a idéia, já faço uma nova imagem da minha arquitetura:

Achei interessante essa abordagem de não deixar o código ser commitado se não está de acordo com algumas métricas e/ou padrões de codificação.

Mas como vocês estão fazendo essa análise do código antes do commit no cvs? Através de um build file do ant?

Desculpe minha ignorância do assunto…

Voce pode fazer isso com um buildfile do ant, sim, mas a gente tava usando um scriptzao Python bonito. Configurar o CVS (ou SVN) pra isso eh super simples, e qualquer livro ou artigo mais detalhado no assunto te ajuda.

O importante eh nao tornar as sessoes de commit infernais, tambem… pq antes codigo ruim gerenciado pelo CVS do que codigo ruim esquecido na maquina de alguem…

Interessante cv! Eu andei pesquisando e pelo que entendi tenho que adicionar um script ou algo parecido no commitinfo no servidor CVS. Então antes de cada commit o CVS vai validar o arquivo através deste script… certo?

Eu achava que essa validação era feita no cliente, mas aí ficava meio sem sentido a coisa…

Valeu pela resposta!

Share! :twisted: :twisted: