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.
[quote=Rafael Nunes]
Sim, pelos motivos acima.[/quote]
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.
[quote=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.[/quote]
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.
[quote=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.[/quote]
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: