Recentemente me assustei com a bagunça e complexidade imensa causada pelo Nexus e os seus artifacts. A idéia é ter dezenas de módulos (ou artifacts) inter-dependentes para descrever o seu projeto. Isso gera uma complexidade absurda para fazer o build e qualquer alteração across artifacts é uma aventura. E o GIT não ajuda em nada, pelo contrário, os seus commits locais jogam para o PUSH a resolução de conflitos. Eu imagino que seja melhor resolver os conflitos a cada commit, como o SVN faz.
Então fica a pergunta, para que eu conheça os argumentos do lado negro da força.
Por que não colocar tudo sempre no mesmo projeto, no mesmo artifact e dividir os modulos (e tudo mais) em pacotes?
Isso torna o build ridículo (!!!) e permite que a IDE resolva qualquer inter-dependência entre os módulos as you type.
Já trabalhei numa empresa que adotava essa filosofia KISS, mas vejo muitas se perdendo na bagunça dos artifacts do Maven + Nexus.
Alguns projetos tem a idéia de modulos como o Spring.
Imagine alguém baixando todos os projetos do Spring em um único jar sendo que ele so precisaria de uma parte do projeto.
Se o seu projeto não tem essa necessidade não crie os módulos e simplifique.
[quote=diegolovison]Alguns projetos tem a idéia de modulos como o Spring.
Imagine alguém baixando todos os projetos do Spring em um único jar sendo que ele so precisa de um jar especifico.
Se o seu projeto não tem essa necessidade não crie os módulos e simplifique.[/quote]
Estava falando mais da base de código de um sistema de uma empresa, mas talvez dê para extrapolar pra tudo.
Qual é o problema de baixar um jar enorme ao invés de um jar pequeno? Espaço em disco? Banda para fazer um download? Acho que não…
É melhor oferecer um jar único com tudo e o cara usa o que quiser e precisar.
Mas a vantagem não é para o cara, e sim para o desenvolvimento interno. Build e integração. Como falei, updates que pegam mais de um artifact são um pé no saco pra fazer sem quebrar tudo.
[quote=diegolovison]Acho que é uma questão de cada projeto e de cada time.
Em alguns projetos é melhor quebrar em outros não. :shock:
[/quote]
A zona que vários módulos causam é tão grande que não vale a pena quebrar não… Pelo menos é o que parece… Vamos ver se alguém apresenta bons argumentos para o contrário… Deve ter porque tem muita gente fazendo isso… Ou talvez as pessoas continuam com atração fatal pela complexidade.
eu particularmente prefito o artifactory ao nexus, e também nunca trabalhei com GIT só com svn.
ao meu ver o problema é do profissional que as vezes não adota boas práticas.
ja trabalhei com gente que não gostava(ou não sabia) de usar dependency management do maven e a build era uma zona e eu mostrei como adotar a filosofia KISS pra eles no meio de toda a bagunça. no primeiro momento todo mundo falou que o que eu fazia não virava nada e depois todo mundo começou a fazer tb.
depois disso ficou mais facil organizar os códigos de cada módulo e de cada componente interno.
eu acho que sistemas complexos com bases de código muito grandes tem que ser quebrados em artefatos sim, pois é mais facil dar manutenção em um pedaço no que em um todo.
agora pra quebrar em artefatos , é preciso tem gente que saiba quebrar.
Eu nunca trabalhei com projetos muito grandes em Java e foi dessa forma simples que você fala que trabalhei, foi muito tranquilo desenvolvimento, evolução e manutenção. Mas gostaria de entender melhor o outro lado para fazer uma analogia à plataforma .NET que trabalho mais, pois sempre trabalhei com soluções muito grandes e na IDE Visual Studio é tudo muito tranquilo a organização para lidar com vários projetos relacionados. O trabalho flui que é uma beleza. Então se puder mostrar uma foto da “organização” complexa, assim seria mais fácil eu entender o que quer defender na prática, pois também sou contra a complexidade por preciosismo que mais atrapalha do que ajuda. Queria tipo esse print: http://www.ibm.com/developerworks/opensource/tutorials/os-ad-configureless/figure13.jpg (neste caso é o modo simples que você falou, queria visualizar o complexo).
Recentemente fiz uma grande atualização no Next, onde ao invés de um único projeto agora existem 21!!!
Essa separação foi feita por alguns motivos, primeiro que pessoas queriam utilizar determinadas funcionalidades, mas devido a dependencia de outras classes não era possível.
Segundo, pois separar em projetos te limita a usar determinada classe “sem querer”. Não é possível guardar todas as dependencias possíveis na cabeça. Tanto, que deu um bom trabalho reorganizar, pois algumas dependencias “inválidas” estavam presentes.
Também tem a vantagem de outro alguém mexer num módulo e ficar contido nele.
No meu caso, não existe nenhum problema em usar tantos projetos. Até ficou mais organizado e fácil.
Porém, não uso maven!!!
Os projetos são simples, seguem a mesma estrutura, e tem um único build.xml que serve para todos os projetos.
Quem controla a dependencia e a compilacao é o eclipse.
Isso soh faz sentido quando voce possui diferentes equipes ou diferentes ciclos de entrega para cada artifact. Por exemplo, no projeto onde estou trabalhando agora, um dos modulos requer downtime a cada atualizacao. Por conta disso foi necessario extrair uma API e esta eh mantida separadamente e permite que outras equipes atualizem seus modulos mais frequentemente e com menor risco.
Isso soh faz sentido quando voce possui diferentes equipes ou diferentes ciclos de entrega para cada artifact. Por exemplo, no projeto onde estou trabalhando agora, um dos modulos requer downtime a cada atualizacao. Por conta disso foi necessario extrair uma API e esta eh mantida separadamente e permite que outras equipes atualizem seus modulos mais frequentemente e com menor risco.
[/quote]
Boa resposta. O que eu vejo em quantidades assustadoras é pessoas quebrando tudo por que acham que fica mais isolado e bonito. Criam uma complexidade absurda para ter a ilusão de serem espertos pois conseguem gerenciar aos trancos e barrancos a complexidade que eles mesmo criaram. Tudo num projeto só é tão mais fácil que dá tristesa ver um build que ninguém entende.
Outro ponto é que empresas que tem como grande maioria de seus desenvolvedores pessoas ainda sem muita experiência em versionamento, pra evitar que 20 pessoas tenham que ficar fazendo commitando, atualizando e fazendo merge toda hora na mesma base de código, ou mesmo atualizando tudo, preferem separar projetos com grandes bases de código, e especializar equipes em algumas dessas partes, ai ninguém coloca a mão no brinquedo do outro e “teoricamente” o desenvolvimento flui melhor. Já vi muito esse esquema por empresas que passei.
Código comitado é código em produção. Disciplina é fundamental. O SVN não permite comitar coisas em conflito. Vc tem que resolver na hora. Já o GIT te permite fazer commits locais cheio de conflitos até que vc ou algum condenado tenha que fazer o push.
Ou assume-se a responsabilidade sobre os seus commits ou cria-se uma zona onde ninguém tem culpa de nada pois ninguém entende nada.
Triste ver que a maioria das empresas vai pelo caminha da complexidade, por inexperiência mas muitas vezes também por opção própria. Acreditam que complexidade é inevitável e que contratando condenados para gerenciá-la é o único jeito de tocar o business. Depois se espantam porque ninguém para no emprego. A verdade é que só maluco ou alguém que ganha muito tem saco para ficar lidando com bagunça. Ou não?
