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).
