¿Pocas bibliotecas grandes o muchas bibliotecas pequeñas?

7

A lo largo de algunos meses, he creado un pequeño marco para el desarrollo de juegos que actualmente incluyo en todos mis proyectos.

El marco depende de SFML, LUA, JSONcpp y otras bibliotecas. Se trata de audio, gráficos, redes, subprocesos; Tiene algunas utilidades de sistema de archivos útiles y capacidades de ajuste de LUA. Además, tiene muchos métodos de utilidad "aleatorios" útiles, como ayudantes de análisis de cadenas y herramientas matemáticas.

La mayoría de mis proyectos utilizan todas estas funciones, pero no todas:

  • Tengo un actualizador automático que solo hace uso del sistema de archivos y las funciones de red
  • Tengo un juego sin capacidades de red
  • Tengo un proyecto que no necesita JSONcpp
  • Tengo un proyecto que solo necesita esos string / math utils

Esto significa que tengo que incluir las bibliotecas compartidas SFML / LUA / JSON en cada proyecto, incluso si no se usan. Los proyectos (sin comprimir) tienen un tamaño mínimo de 10 MB de esta manera, la mayoría de los cuales no se utilizan.

La alternativa sería dividir el marco en muchas bibliotecas más pequeñas, lo que creo que sería mucho más efectivo y elegante, pero también tendría el costo de tener que mantener más archivos y proyectos DLL.

Tendría que dividir mi marco en muchas bibliotecas más pequeñas:

  • Gráficos
  • enhebrado
  • Redes
  • Sistema de archivos
  • utils más pequeños
  • JSONcpp utils
  • LUA utils

¿Es esta la mejor solución?

    
pregunta Vittorio Romeo 18.03.2013 - 16:56

4 respuestas

13

Yo personalmente iría a muchas bibliotecas pequeñas.

  • Desalienta a los desarrolladores a crear dependencias entre paquetes no relacionados de otra manera.
  • Bibliotecas más pequeñas y manejables que están mucho más enfocadas.
  • Es más fácil separarse y tener equipos separados para administrar cada biblioteca.
  • Una vez que tenga un nuevo requisito que sea lo suficientemente complejo, es mejor agregar un nuevo módulo en lugar de encontrar una biblioteca existente para introducir el nuevo código. Las bibliotecas pequeñas fomentan este patrón.
respondido por el p.s.w.g 18.03.2013 - 17:01
3

Ha dado un lado de la compensación, pero no el otro. Sin un "justo y equilibrado" de las presiones bajo las que está operando, no podemos decirle.

Usted dice que dividir las bibliotecas hará que todos sus proyectos sean más pequeños. Eso es un claro plus. Puedo imaginar varios inconvenientes:

  • dividir las bibliotecas es en sí mismo un esfuerzo, incluso si solo hay que hacerlo una vez.
  • mantener las versiones de muchas bibliotecas consistentemente es un esfuerzo adicional pequeño pero persistente.
  • no es tan fácil asegurarse de que todos los proyectos, de hecho, agrupen las cosas que necesitan
  • la división puede no ser tan limpia como cree en este momento, e introducir trabajo adicional, tal vez incluso amenazar la integridad conceptual de algunos módulos.

Dependiendo de la probabilidad / importancia de tales argumentos en su contra, la división puede o no ser la opción correcta para usted. (Tenga en cuenta que muchos consideran que la dicotomía entre "divisores" y "parachoques" es un rasgo fundamental de la personalidad que no es susceptible a la lógica).

Dicho esto, las diferentes tareas que dice que están haciendo sus módulos están tan alejadas unas de otras que consideraría al menos algunas la división probablemente solicitada.

    
respondido por el Kilian Foth 18.03.2013 - 17:05
2

No hay una respuesta clara. El mejor factor de conducción que se me ocurre es cuán interrelacionadas están las bibliotecas ahora, y espera que se relacionen más adelante. Si tienes una red compleja de dependencias, entonces una gran biblioteca probablemente será más fácil, si tienes relaciones mínimas, puedes dividirlas limpiamente.

    
respondido por el Sign 18.03.2013 - 17:30
0

Esto podría ser muy subjetivo y dependerá de su psicología y sensibilidad, pero mis bibliotecas más duraderas que he estado usando para mis proyectos personales y no empecé a odiar con el paso de los años siempre fueron las más pequeñas, más aisladas (no Dependencias externas a otras librerías).

Es porque solo se necesita una idea estúpida o arcaica para desordenar mi percepción de la biblioteca. Como si pudiera tener un código C perfectamente razonable para rasterizar formas en una biblioteca de dibujos, excepto que depende de una biblioteca de imágenes y matemáticas que escribí en los años 90 contra imágenes de 16 bits que, en retrospectiva, ahora son totalmente tontas. También podría tener una biblioteca de análisis de C ++ con algún código de análisis decente y código AST, excepto que lo acoplé a un flujo de análisis monolítico que, en retrospectiva, fue un diseño realmente tonto y poco práctico. Así que ahora todo se siente como una mierda. La mayor parte de mi código C ++ de los años 90 es una mierda total para mí ahora, ya que no sabía cómo diseñar efectivamente en C ++ en ese entonces e hice cosas tontas como usar la herencia para "extender" y proporcionar una funcionalidad de superconjunto formando clases con más de 100 miembros y abstracciones ridículas en lugar de modelar subtipos adecuados con interfaces minimalistas. Más de mi código C ha sobrevivido a mi filtro de shite, aunque solo una fracción. Sobre todo se me ocurrió una montaña de mierda. Las pequeñas pepitas de oro que pude seleccionar fueron siempre el código más desacoplado y minimalista con la mayor singularidad de propósito y, a menudo, dependiendo de poco más que los tipos de datos primitivos.

Entonces, ya no quiero molestar más con estas libretas, excepto tal vez transferir el código a una nueva libreta que no molesta a esas y simplemente funciona contra píxeles en bruto de 32 bits y 128 bits y en lugar del vector matemático de depender de algún lib matemático externo para, por ejemplo, el lib de rasterización. Entonces el código dura mucho más tiempo y me mantiene feliz. Soy un poco cínico con mis puntos de vista de las bibliotecas. Tiendo a juzgarlos por los enlaces más débiles en lugar de los enlaces más fuertes. No puedo pasar por alto lo malo en favor de lo bueno hasta que lo malo se elimine por completo de esa biblioteca.

Así que voto por las bibliotecas más pequeñas e independientes, ya que tienen una menor probabilidad, al menos para mí, de sentir que son una mierda más adelante. Si trabajas en un equipo, votaría a favor de eso aún más con estándares más fuertes para mantener las bibliotecas desconectadas unas de otras, ya que pueden ensuciarse muy rápido con muchas manos a menos que tengan un propósito y un objetivo muy singulares. hacia el minimalismo (buscar razones para no agregar más en lugar de encontrar siempre razones para agregar más, no puede odiar lo que no agrega) ... aunque la pregunta dice que esto fue más para proyectos personales donde quizás La psicología influye en más. Pero además votaría para separar piezas de funcionalidad muy desacopladas. No necesariamente tiene que dividir su marco en todas las piezas que desee de inmediato. Solo busco comenzar a construir bibliotecas de código estables, bien probadas, que sean mínimas y estén desconectadas en la naturaleza, cosas que te hacen sentir bien si duran un buen rato.

    
respondido por el user204677 18.12.2017 - 11:56

Lea otras preguntas en las etiquetas