Em um ambiente onde a infra-estrutura e a arquitetura de software promovam o uso de componentes distribuídos (ou mesmo locais) e exista uma área que centraliza este conhecimento, a exemplo das áreas de arquitetura e/ou governança de TI, é extremamente necessário haver um gerenciamento efetivo e eficaz destes componentes e do conhecimento gerado.
Como exemplo prático cito uma companhia que tem diversos sistemas e usa uma arquitetura componentizada, onde vários componentes são reutilizados por esses diversos sistemas, para promover o reuso e evitar redundâncias.
Alguém trabalha em um cenário deste tipo? Como gerenciam estes componentes e o conhecimento?
Entendam por componente, por exemplo, os pacotes JAR, WAR, EAR gerados e que devem ser disponibilizados no container ou mesmo para as equipes de desenvolvimento ou consultorias de outsourcing.
Agradeço antecipadamente o compartilhamento do conhecimento e das experiências.
O ambiente aqui é bem parecido com cenario que vc descreveu.
O conhecimento de como utilizar essas bibliotecas postamos no Wiki e controle de versão utilizamos o SVN
Eu trabalho numa empresa que tem (ou deveria ter) esse controle de componentes/conhecimento. Vou tentar explicar como as coisas aqui funcionam:
Existe uma área chamada “administração de dados e componentes” que é responsável por:
A) Definir os nomes e a localização dos componentes (componentes aqui são EJBs, ORMs, tabelas, etc) e
B) Cuidar do reuso destes componentes.
Eles cadastram todos estes dados numa aplicaçãozinha web. Se eu pesquiso, por exemplo, por um nome de ORM, consigo ver em que projeto ela está, quais EJBs a utilizam, etc. Assim eu consigo reutilizar o que já foi implementado. Isso não funciona muito bem aqui por 2 motivos, basicamente:
Pra definir os nomes dos componentes, alguém daquela área pega um documento de visão (que não é bem um DV) e um monte de casos de uso, supostamente lê tudo, “caga” os nomes dos componentes e diz “isso aqui vocês vão criar neste projeto, aquilo já tem no projeto tal, etc”. Não se pode criar nada diferente daquele bolo marrom que eles determinam. Aí você soma a isso uma arquitetura de caixinha (todos os projetos usam a mesma arquitetura, as necessidades de negócio e oportunidades de simplificação não importam) e se vê no meio de um Bean com mais de 12KLOC, métodos com mais de 200 linhas, etc. Sem testes, ninguém que percebe o tamanho da encrenca (e são poucos aqui que percebem isso) tem coragem de refatorar. Isso se eles liberassem a criação de novos componentes.
O cadastro dos componentes na ferramenta de consulta é feita manualmente. Se alguém esquece de cadastrar o componente lá, ou se alguém não consulta antes de fazer, o reuso vai pro ralo.
Desculpe a choradeira, mas como você não disse que queria uma experiência boa, eu falei da minha. Cada vez mais acredito que o melhor jeito de fazer isso é tendo boas pessoas nos times, escrevendo um monte de testes e disseminando o conhecimento da todas as formas possíveis (pair programming, apresentações das releases para todos da empresa, fórum eletrônico interno, pessoas participativas, etc).
Gostei muito da sua experiência. Não foge muito do que eu havia pensado.
O software para gerenciar isso é feito por vocês ou vocês compraram/licença free?
Como o projeto aqui é imenso e quem faz os sistemas são consultorias em outsourcing, e como todo o sistema está em desenvolvimento paralelo (não existia nada pré-existente em java), então fica bem mais difícil essa gestão, mas precisamos controlar para não ficarmos perdidos ou vendidos.
No momento estou levantando os sistemas e suas dependência, para que eu posso criar diagramas de componentes, para ter uma visão geral do que temos e para onde estamos indo. Depois cadastrar e manter esses componentes, para então ser capaz de gerenciá-los da melhor forma possível.
Gostou? Hehehe… Eu que não estou gostando nem um pouco
[quote=danieldestro]
O software para gerenciar isso é feito por vocês ou vocês compraram/licença free?[/quote]
Foi feito internamente. É bem simples mesmo. É só um sisteminha de cadastros e consultas.
[quote=Taz]
Maven. Não só componentes internos, mas tb externos.
Ahh, e ainda tem plugin para Eclipse.[/quote]
Não sei se o Maven faz esse tipo de controle. O Maurício Linhares indicou uns links de download para um livro “Better Builds with Maven” aqui no GUJ. Se ajudar, dá uma pesquisada.
[quote=Adolfo Rodrigues][quote=danieldestro]
Gostei muito da sua experiência. Não foge muito do que eu havia pensado.
[/quote]
Gostou? Hehehe… Eu que não estou gostando nem um pouco [/quote]
Gostei que tenha compartilhado a sua experiência… hehehe!
Daniel, acho que wiki+SVN+Maven podem ajudar bastante.
Deixa a parte “burocrática” num wiki, crie meios de organizar o versionamentos desses componentes via VCS mesmo, tags ou coisa do tipo, congelando os fontes das releases e o Maven para que cada sistema que utilize esses componentes possa gerenciar as versões que utiliza de cada um.
É uma maneira simplória mas se bem definida e organizada pode ajudar bastante.
Nome componente: Persistência Base XYZ Descrição: Faz a persistência dos dados da base de dados XYZ, envolvendo as operações básicas (CRUD), além das buscas específicas para cada entidade. Entidades envolvidadas - Pessoa, Departamento, Empresa, Endereco. Projeto: XYZ Responsável: Zé da Silva - TI - ze.silva@acme.com Tags: persistência modelo java dao ejb XYZ
Nome componente: Gestão Recursos Humanos Descrição: Faz a gestão dos recursos humanos, blá blá blá. Projeto: RH Responsável: Tião Macalé - RH - tiao.macale@acme.com Dependências: Persistência Base XYZ Tags: rh java
Nome componente: Persistência Base XYZ Descrição: Faz a persistência dos dados da base de dados XYZ, envolvendo as operações básicas (CRUD), além das buscas específicas para cada entidade. Entidades envolvidadas - Pessoa, Departamento, Empresa, Endereco. Projeto: XYZ Responsável: Zé da Silva - TI - ze.silva@acme.com Tags: persistência modelo java dao ejb XYZ
[/quote]
Acho que o Maven resolve. No começo dói pra vc entedê-lo, mas depois de muita fé e persistência é 10 a 0 no ant.
Taz, o Maven parece ser útil, mas não neste estágio e para este propósito.
O Wiki, como já disseram, parece útil. A gente chegou a ver um sistema comercial que faz isso e se integra com SVN. Está sob avaliação da direção.
Na verdade queria mais opiniões à cerca do processo desta gestão.
