En el transcurso 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 útiles del sistema de archivos y capacidades de ajuste LUA. Además, tiene muchos métodos útiles de utilidad "aleatoria", como ayudantes de análisis de cadenas y utilidades matemáticas.
La mayoría de mis proyectos usan todas estas características, pero no todas:
- Tengo un actualizador automático que solo utiliza el 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 esas herramientas de cadena / matemáticas
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 DLL y proyectos.
Tendría que dividir mi marco en muchas bibliotecas más pequeñas:
- Gráficos
- Enhebrar
- Redes
- Sistema de archivos
- Utilidades más pequeñas
- Utilidades JSONcpp
- LUA utils
¿Es esta la mejor solución?
fuente
Respuestas:
Yo personalmente iría por muchas bibliotecas pequeñas.
fuente
Has 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 decírselo.
Dices que dividir las bibliotecas hará que todos tus proyectos sean más pequeños. Esa es una clara ventaja. Puedo imaginar varios inconvenientes:
Dependiendo de cuán probable / importante sean tales argumentos contrarios para usted, la división puede ser o no la mejor opción para usted. (¡Tenga en cuenta que la dicotomía entre "divisores" y "lumpers" es considerada por muchos como un rasgo fundamental de la personalidad que no es susceptible a la lógica en primer lugar!)
Dicho esto, las diferentes tareas que dice que están haciendo sus módulos están tan alejadas unas de otras que consideraría que al menos algunas divisiones probablemente requieran.
fuente
No hay una respuesta clara. El mejor factor que puedo pensar es cuán interrelacionadas están las bibliotecas ahora, y esperas que se relacionen más adelante. Si tiene una red compleja de dependencias, entonces una biblioteca grande probablemente será más fácil, si tiene relaciones mínimas, puede dividirlas limpiamente.
fuente
Esto puede ser muy subjetivo y depende de su psicología y sensibilidad, pero mis bibliotecas más duraderas que he estado usando para mis proyectos personales y que no comencé a odiar a lo largo de los años siempre fueron las más pequeñas y aisladas (sin dependencias externas de otras librerías).
Es porque solo se necesita una idea tonta o arcaica para confundir toda mi percepción de la biblioteca. Al igual que podría tener un código C perfectamente razonable para rasterizar formas en una biblioteca de dibujo, excepto que depende de una imagen y una biblioteca matemática que escribí en los años 90 contra imágenes de 16 bits que, en retrospectiva, ahora son totalmente claras. 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 allí, excepto que lo acoplé a una secuencia de análisis monolítico que, en retrospectiva, era 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 90 es una mierda total para mí ahora, ya que realmente no sabía cómo diseñar de manera efectiva en C ++ en ese momento e hice cosas tontas como usar la herencia para "extender" y proporciona una funcionalidad de superconjunto que forma clases con más de 100 miembros y abstracciones tontas en lugar de modelar subtipos adecuados con interfaces minimalistas. Más de mi código C ha sobrevivido a mi filtro shite, aunque solo una fracción. Sobre todo se me ocurrió una montaña de mierda. Las pequeñas pepitas de oro que pude elegir siempre fueron el código minimalista más desacoplado con la mayor singularidad de propósito y, a menudo, dependían de poco más que tipos de datos primitivos.
Entonces, ya ni siquiera quiero molestarme con estas bibliotecas, excepto tal vez portar el código a una nueva biblioteca que no se molesta con ellas y solo funciona contra píxeles de 32 bits y 128 bits sin procesar y alinea las matemáticas vectoriales en lugar de depender de alguna lib matemática externa para, por ejemplo, la lib rasterización. Entonces el código dura mucho más y me hace 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 a 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 probabilidad menor, al menos para mí, de sentir que son una mierda más adelante. Si está trabajando en un equipo, votaría por eso aún más con estándares más estrictos para mantener las bibliotecas desconectadas entre sí, ya que pueden desordenarse muy rápido con muchas manos sobre ellas, a menos que tengan un propósito muy singular y un objetivo hacia el minimalismo (buscando razones para no agregar más en lugar de encontrar siempre razones para agregar más, no puede odiar lo que no agrega) ... aunque sonaba por la pregunta de que esto era más para proyectos personales donde tal vez factores de psicología en más. Pero además votaría para dividir las piezas de funcionalidad muy desacopladas. No necesariamente tiene que dividir su marco en todas las piezas que desee de inmediato. YO'
fuente