Práticas recomendadas para compartilhar minúsculos fragmentos de código entre projetos

Se eles são realmente métodos / classes reutilizáveis, você pode escrevê-los em um pequeno número de bibliotecas 'Swiss Army Knife'. Fazemos isso com bastante frequência na minha empresa; nós os chamamos de bibliotecas de estrutura:

• Framework.Data - Utilitários para trabalhar com consultas de banco de dados.
• Framework.ESB - Métodos padrão para interagir com o nosso barramento de serviço corporativo
• Framework.Logging - Sistema de registro unificado
• Framework.Services - Utilitários para interagir com serviços da web
• Framework.Strings - Utilitários para manipulação avançada de strings / pesquisa de strings difusas, etc.
• ...

No total, existem cerca de uma dúzia de bibliotecas. Você pode realmente distribuir o código da maneira que achar melhor, para que você não tenha centenas ou despeje tudo em uma montagem gigante. Acho que essa abordagem se encaixa porque apenas alguns de nossos projetos precisarão de Framework.Data e apenas alguns precisarão de Framework.Strings , para que os consumidores possam selecionar apenas as partes da estrutura que são relevantes para seu projeto específico.

Se eles são realmente apenas trechos, e não métodos / classes reais que podem ser facilmente reutilizados, você pode tentar apenas distribuí-los como trechos de código no IDE (por exemplo, Snippets de código do Visual Studio ). As equipes com quem trabalhei no passado tinham uma biblioteca de snippets comuns que facilitou para que todos pudessem seguir nossas práticas de codificação padrão com código interno também.

Eu não concordo com a resposta aceita por muitas razões.

Na minha experiência, quando vejo bibliotecas "diversas" como a resposta aceita, elas são uma desculpa para reinventar a roda (ou não inventado aqui (NIH) ) - um pecado muito maior do que violar Don't Repeat Yourself (DRY) .

Às vezes, violar DRY pode ser um compromisso razoável, é melhor do que introduzir um acoplamento rígido. A reutilização é uma preocupação secundária em comparação ao bom design orientado a objetos. Um pouco (quero dizer pequena quantidade, aplique o Regra dos Três ) de duplicação é mais fácil de entender do que um base de código de espaguete.

A abordagem de inúmeras bibliotecas de propósito geral é um mau exemplo. Isso leva a uma granularidade fina de montagem e muitas montagens são ruins. Recentemente, reduzi internamente de 24 bibliotecas para 6 bibliotecas. Melhorou o tempo de compilação de vários minutos a ~ 20 segundos. O Visual Studio também é mais lento para carregar e responde menos com mais montagens. Ter bibliotecas demais também leva a confusão sobre onde o código deve viver; prefira menos regras mais simples.

Por que as coisas no .Net Framework não são boas o suficiente? A estrutura é bem grande; muitas vezes vi código que reimplementa coisas que já existem lá. Realmente certifique-se de que seus frameworks preencham lacunas no framework .Net e não existam apenas por razões estéticas (por exemplo, "Eu não gosto do framework .Net aqui" ou talvez algum otimização prematura )

A introdução de outra camada em sua arquitetura tem um custo de complexidade significativo. Por que a camada existe? Eu vi falsa reutilização, com isso quero dizer que o código é construído sobre uma estrutura interna. Teria sido muito mais eficiente implementá-lo diretamente sobre as bibliotecas padrão.

O uso de tecnologias padronizadas (como a estrutura .Net e bibliotecas populares de código aberto / de terceiros) tem benefícios que muitas vezes superam os ganhos tecnológicos comparativos da construção por conta própria. É mais fácil encontrar talentos que conheçam essas tecnologias e seus desenvolvedores atuais investirão mais no aprendizado.

Minhas recomendações:

• Não compartilhe este código.
• Crie uma nova biblioteca se ela tiver um propósito coeso e não use o padrão de design de bola de barro .
• Reutilize as bibliotecas de terceiros existentes sempre que possível.
• Prefira menos montagens, com regras mais simples sobre onde o código deve viver.

Para pequenos pedaços de código - digamos, uma única classe sem dependências - tendemos a copiar e colar o código em projetos. Isso soa como uma violação do DRY, e eu admito que pode ser às vezes. Mas, a longo prazo, tem sido muito melhor do que ter algum tipo de projeto massivo e multi-liderado por alguns motivos.

Primeiro, é mais simples ter o código à mão, especialmente ao criar e depurar coisas.

Em segundo lugar, invariavelmente você vai querer fazer um pequeno ajuste no código comum para esse projeto. Se você tem uma cópia local da fonte, basta fazer o ajuste e chamá-la por dia. Se houver uma biblioteca compartilhada, você poderá fazer ajustes nessa biblioteca e, em seguida, verificar se não quebra todos os outros aplicativos ou criar um pesadelo de controle de versão.

Então, se não for robusto o suficiente para o seu próprio espaço de nomes, tendemos a empurrá-lo para os bits apropriados do projeto e chamá-lo por um dia.

A segunda solução que você descreve não é tão ruim assim. No .NET, você também faz referência a um assembly do GAC, mesmo que você use apenas uma única classe dele. "Arrastar código irrelevante" não é um problema como você imagina. Nesse caso, é vital, pelo menos, manter métodos e classes relacionados organizados de forma limpa em diferentes namespaces. Além disso, boas práticas para o design da API devem ser aplicadas para evitar que essa solução se torne uma bagunça.

Se se tratar de pequenos pedaços de código, acho que a seguinte abordagem é um bom complemento para um projeto comum: permitir que eles sejam duplicados em diferentes soluções. Lide com eles como práticas recomendadas: documente e comunique-os à equipe.

Eu só trabalhei em ambientes "corporativos" onde esse tipo de coisa tem sido um problema e cada vez que é a segunda opção adotada. Na maior parte do tempo, funcionou bem, porque não houve qualquer restrição ao uso de aplicativos.

No entanto, tendo passado a última semana com uma start-up que está executando seu próprio servidor Nuget, estou inclinado a sugerir isso como uma alternativa viável. É claro que as questões que eu espero que surjam serão em torno da capacidade de descobrir.

Se os projetos são adequadamente granulares e os namespaces são sensatos, então eu posso ver isso se tornando uma abordagem popular em alguns lugares.

Eu tenho pensado recentemente sobre isso e o que me ocorreu foi uma grande biblioteca de métodos comuns, como foi mencionado até agora, mas com uma torção. O projeto da biblioteca permite que você configure em tempo de compilação quais partes estão incluídas como o projeto BusyBox . Com essa abordagem, você pode ter um repositório de biblioteca de estilo de pia de cozinha, mas apenas pegue as ferramentas necessárias ao compilar.

O GitHub tem uma ferramenta bastante útil para salvar os snippets de código link

Ele armazena seus snippets como repositórios git que você pode manter privados ou usar para compartilhar snippets com outras pessoas.

Dependendo do tamanho da equipe / projeto / empresa, isso será algo difícil de se fazer, a menos que já esteja embutido em seu ambiente, e toda solução que você encontrar (se for implementada) custará algum dinheiro . (Pode ser mais seguro para você, mas você não poderá medir facilmente). Você terá que verificar se vale a pena o preço. Tenha em mente também que as soluções reutilizáveis tendem a se tornar abstratas e muitas vezes se encaixam em muitas situações, mas sem serem ideais.

De qualquer forma, se você quiser fazer isso para o código produzido por mais de uma pessoa, primeiro você precisará da conscientização de todos e da cooperação. Isso inclui desenvolvedores e gerentes.

Em seguida, você precisará verificar o escopo em que deseja fazer isso. Equipe? Projeto? Departamento? Empresa? Dependendo da resposta, o tipo de código que você colocará nessas soluções variará, assim como a granularidade com a qual você personalizará as dlls. Uma vez que você tenha decidido sobre isso, alguém (preferivelmente com algum entusiasmo pela idéia - você?) Deveria se sentar e começar a colocar alguma estrutura nisso.

Apenas criar essas dlls não será suficiente para fazer o truque, no entanto. Para torná-los úteis, você precisará publicá-los (para usuários e colaboradores) e mantê-los como qualquer outro software, o que geralmente significa que você precisa colocar alguém no comando por um longo tempo. Você também precisará de documentação confiável, que também precisará de manutenção. Com alguma sorte e cooperação, você pode acabar com algumas das melhores práticas, mas pode facilmente evoluir para um projeto próprio, dependendo do tamanho e do número de equipes envolvidas. E para isso você ainda precisará de suporte de gerenciamento.

Eu enfrentei muitos problemas, e minha solução preferida é postar o código em um repositório habilitado para web github / pubic. resolve muitos problemas -

1. acesso fácil e fácil de compartilhar. O cvs / svn / enterprise-repos significa verificar o projeto em vários espaços de trabalho do IDE e, às vezes, ter que alternar espaços de trabalho ou computadores apenas para se referir a um pequeno trecho de código.
2. supondo que esses trechos de código não sejam códigos de propriedade / classificados e sejam variações de conhecimento disponível publicamente, postá-los em um repositório público como o github significa que outros o verão e podem até mesmo contribuir.
3. postar algo em domínio público sob o seu nome tem uma pressão extra de reputação. você checará e atualizará as coisas, já que reflete sobre suas habilidades como programador.
4. atualizações. A única coisa sobre a manutenção de trechos de código em um repositório é, se um trecho não foi usado em um longo tempo, ele pode ficar obsoleto (conter apis / libs desatualizados). exemplo - trecho de código java para ler um arquivo. você pode ter descoberto a melhor maneira de fazer isso em 2009, mas em 2014 uma nova API de arquivo é lançada e muda tudo. seu trecho? ainda preso em 2009. em um repositório público, as coisas serão atualizadas, seja por você (porque o marcador 3), seus colegas de equipe ou algum membro da população geral programadora, e no processo, você pode até obter sugestões para corrigir algo que você pode estar fazendo errado por um longo tempo.

Uma coisa que eu recomendaria - não importa onde você guarde seus trechos, sempre use o Google antes de usá-lo. as coisas mudam o tempo todo. os snippets salvos economizam tempo, mas também geram complacência .

Temos um projeto separado "utilitários", onde armazenamos todos esses pequenos métodos juntos com os testes.

Quando um projeto precisa de algum utilitário, basta adicionar o arquivo de origem com o método necessário com "add as link".

Isso significa que não há dependências de tempo de execução adicionadas (a menos que o arquivo incluído precise de uma).

O sistema funcionou bem, mas como todos os outros, ele precisa decifrar o que é um utilitário. Requiering alta cobertura de teste tem funcionado bem para nós e testes também são boa documentação de uso. A descoberta ainda é um problema não resolvido para nós.

Uma complexidade com o projeto de utilidade é decidir o nível de visibilidade dos itens. Uma regra geral é que os métodos devem ser internos e as estruturas de dados públicas.

Minha empresa usa serviços da Web intranet-locais. Temos alguns serviços da Web configurados como serviços da Web internos comuns e, quando outro projeto precisa de acesso a um dos serviços, ele envia uma solicitação http com uma interface definida. Como está na intranet, hospedada no mesmo farm de servidores, essas solicitações são muito rápidas.

Obviamente, isso só funciona com aplicativos da Internet (e só funciona em milissegundos quando na mesma rede local), mas tem algumas vantagens muito boas.

Recentemente, criei este serviço: Snip2Code ( link ).

É uma maneira interessante de compartilhar apenas seus snippets (não todas as bibliotecas) com sua equipe. Isso quebra o ponto usual de criar bibliotecas comuns que devem ser referenciadas em outros projetos e, na minha opinião, essa é uma visão valiosa.

Além disso, existem muitos cenários em que o uso de uma biblioteca comum simplesmente não se aplica: vamos considerar, por exemplo, alguns Padrões de Design como Singleton, Strategy ou Observer. Você pode criar bibliotecas para suportar esses padrões, mas ainda assim não há cobertura de 100%.

A necessidade real é ter uma ferramenta para compartilhar práticas comuns entre a equipe. Eu tentei usar os conceitos do Github, mas eu estou preso com a procura deles (muito pobre) e com o fato de que eu não posso compartilhá-los apenas entre o meu time e não com outros ...

(Aviso: Eu sou um dos fundadores do Snip2Code, e eu fui - junto com meus co-fundadores - em sua mesma mentalidade há algum tempo: é por isso que decidimos começar este projeto !!)