Poucas bibliotecas grandes ou muitas bibliotecas pequenas?


9

Ao longo de alguns meses, criei uma pequena estrutura para o desenvolvimento de jogos que atualmente incluo em todos os meus projetos.

A estrutura depende do SFML, LUA, JSONcpp e outras bibliotecas. Ele lida com áudio, gráficos, redes, threading; possui alguns utilitários úteis do sistema de arquivos e recursos de agrupamento de LUA. Além disso, possui muitos métodos utilitários "aleatórios" úteis, como auxiliares de análise de cadeias e utilitários matemáticos.

A maioria dos meus projetos usa todos esses recursos, mas não todos:

  • Eu tenho um atualizador automático que utiliza apenas o sistema de arquivos e os recursos de rede
  • Eu tenho um jogo sem recursos de rede
  • Eu tenho um projeto que não precisa de JSONcpp
  • Eu tenho um projeto que só precisa daqueles utilitários string / math

Isso significa que eu tenho que incluir as bibliotecas compartilhadas SFML / LUA / JSON em todos os projetos, mesmo que não sejam usadas. Os projetos (não compactados) têm um tamanho mínimo de 10 MB dessa maneira, a maioria dos quais não é utilizada.

A alternativa seria dividir a estrutura em muitas bibliotecas menores, que eu acho que seriam muito mais eficazes e elegantes, mas também teriam o custo de manter mais arquivos e projetos DLL.

Eu precisaria dividir minha estrutura em várias bibliotecas menores:

  • Gráficos
  • Rosqueamento
  • Trabalho em rede
  • Sistema de arquivo
  • Utilitários menores
  • Utilitários JSONcpp
  • Utilitários LUA

Essa é a melhor solução?


1
Lembre-se de que você poderá criar um gráfico direcionado de suas dependências. Se alguns de seus módulos dependem de módulos que dependem deles, você está apenas pedindo problemas. Se você não pode estruturar isso de modo que as dependências não sejam circulares, não deve mexer com isso.
22413 Bobson

É também dependem de como o de programação e ambiente de programação relacionada, administra bibliotecas e conceitos relacionados tais bibliotecas, embalagens, namespace, e tanto ...
umlcat

Para mim, uma biblioteca é apenas um contêiner de remessa - é o tamanho e as interdependências (e dependências externas) das caixas que estão dentro que importam. Contanto que você projete as caixas únicas (arquivos de objetos, por exemplo) como peças funcionais independentes, sem dependências desnecessárias, os dois modos são adequados.
tofro

Respostas:


14

Eu pessoalmente procuraria muitas bibliotecas pequenas.

  • Desestimula os desenvolvedores a criar dependências entre pacotes não relacionados.
  • Bibliotecas menores e mais gerenciáveis, muito mais focadas.
  • É mais fácil desmembrar e ter equipes separadas para gerenciar cada biblioteca.
  • Depois de ter um novo requisito suficientemente complexo, é melhor adicionar um novo módulo em vez de encontrar uma biblioteca existente para inserir o novo código. Bibliotecas pequenas incentivam esse padrão.

No geral, concordo, embora tenha visto casos em que a abordagem de pequenas bibliotecas não foi bem gerenciada e ficou fora de controle. Em um projeto, cada biblioteca tinha código de camada de acesso a dados semi-duplicado. Por outro lado, havia muitos relacionamentos dependentes entre bibliotecas.
jfrankcarr

@jfrankcarr É verdade que o mau gerenciamento de código pode afetar qualquer projeto. Meu sentido é que projetos com bibliotecas monolíticas são mais suscetíveis a projetos com pequenas 'micro-bibliotecas'.
PSWG

Apenas uma observação - o SFML em si é dividido em vários módulos, para que você não precise vincular ao módulo de rede, por exemplo, se o seu jogo for apenas para um jogador.
sjaustirni

4

Você deu um lado do compromisso, mas não o outro. Sem uma "justa e equilibrada" das pressões sob as quais você está operando, não podemos lhe dizer.

Você diz que dividir as bibliotecas tornará todos os seus projetos menores. Essa é uma vantagem clara. Eu posso imaginar vários desvantagens:

  • dividir as bibliotecas é em si um esforço, mesmo que tenha que ser feito apenas uma vez.
  • manter versões de muitas bibliotecas de maneira consistente é um esforço adicional pequeno, mas persistente.
  • não é tão fácil ter certeza de que todo projeto realmente reúne as coisas de que precisa
  • a divisão pode não ser possível da maneira mais limpa que você acredita no momento, e introduzir trabalho extra, talvez até ameaçar a integridade conceitual de alguns módulos.

Dependendo da probabilidade / importância de tais contra-argumentos, a divisão pode ou não ser a escolha certa para você. (Observe que a dicotomia entre "divisores" e "montantes" é considerada por muitos como um traço fundamental de personalidade que não é suscetível à lógica em primeiro lugar!)

Dito isto, as diferentes tarefas que você diz que seus módulos estão fazendo estão tão distantes uma da outra que eu consideraria pelo menos uma divisão provavelmente necessária.


2

Não há uma resposta clara. O melhor fator determinante em que consigo pensar é como as bibliotecas estão inter-relacionadas agora e você espera que elas se relacionem mais tarde. Se você tiver uma rede complexa de dependências, uma grande biblioteca provavelmente será mais fácil; se você tiver relacionamentos mínimos, poderá dividi-los de maneira limpa.


0

Isso pode ser muito subjetivo e depende de sua psicologia e sensibilidade, mas minhas bibliotecas mais duradouras que venho usando para meus projetos pessoais e que não começaram a odiar ao longo dos anos sempre foram as menores e mais isoladas (sem dependências externas para outras bibliotecas).

É porque é preciso apenas uma idéia idiota ou arcaica para mexer com toda a minha percepção da biblioteca. Como se eu tivesse um código C perfeitamente razoável para rasterizar formas em uma biblioteca de desenhos, exceto que depende de uma biblioteca de imagens e matemática que escrevi nos anos 90 contra imagens de 16 bits que, em retrospecto, agora são totalmente desprezíveis. Eu também poderia ter uma biblioteca de análise C ++ com algum código de análise decente e código AST, exceto que eu a juntei a um fluxo de análise monolítico que, em retrospecto, era um design realmente tolo e impraticável. Então agora tudo parece uma merda. A maior parte do meu código C ++ dos anos 90 é uma porcaria total para mim agora, porque eu realmente não sabia como projetar efetivamente em C ++ naquela época e fiz coisas idiotas como usar a herança para "estender" e forneça funcionalidades de superconjunto, formando classes com mais de 100 membros e abstrações patetas, em vez de modelar subtipos adequados com interfaces minimalistas. Mais do meu código C sobreviveu ao meu filtro de merda, embora apenas uma fração. Principalmente eu vim com uma montanha de merda. As pequenas pepitas de ouro que pude escolher sempre foram o código minimalista mais dissociado, com a maior singularidade de propósito e, muitas vezes, dependendo de pouco mais do que tipos de dados primitivos.

Então, eu nem quero mais me incomodar com essas bibliotecas, exceto talvez portar o código para uma nova lib que não se incomode com elas e que funcione apenas contra pixels brutos de 32 e 128 bits e enfatize a matemática do vetor em vez de depender de alguma biblioteca matemática externa para, digamos, a biblioteca de rasterização. Então o código dura muito mais e me deixa feliz. Sou meio cínico com minhas visões de bibliotecas. Costumo julgá-los pelos elos mais fracos, em vez dos mais fortes. Não posso ignorar o mal a favor do bem até que o mal seja completamente eliminado dessa biblioteca.

Por isso, voto nas bibliotecas menores e mais independentes, pois elas têm uma probabilidade menor, pelo menos para mim, de sentir que são uma merda mais tarde. Se você estiver trabalhando em uma equipe, eu votaria ainda mais com padrões mais fortes para manter as bibliotecas separadas, uma vez que elas podem ficar bagunçadas muito rápido com muitas mãos, a menos que tenham um objetivo e um objetivo muito singulares em direção ao minimalismo (procurando razões para não adicionar mais em vez de sempre encontrar razões para adicionar mais - você não pode odiar o que não adiciona) ... embora parecesse a pergunta de que isso era mais para projetos pessoais onde talvez fatores psicológicos em mais. Mas, além disso, eu votaria para separar peças de funcionalidade muito dissociadas. Você não precisa necessariamente dividir sua estrutura para todas as peças que deseja imediatamente. EU'

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.