design – ¿Es una buena idea una biblioteca común?

Pregunta:

Siempre pensé que una "biblioteca común" era una buena idea. Con eso me refiero a una biblioteca que contiene la funcionalidad común que a menudo necesitan algunas aplicaciones diferentes. Resulta en menos duplicación / redundancia de código.

Recientemente leí un artículo (no puedo encontrarlo ahora) que decía que esto en realidad es una mala idea y fui tan lejos como para decir que era un "anti-patrón".

Si bien hay ventajas en este enfoque. El control de versiones y la gestión de cambios significan una prueba de regresión para el conjunto de aplicaciones que utilizan esta biblioteca.

Estoy un poco atrapado en una rutina para mi nuevo proyecto (Golang). La deduplicación de código me ha sido martillada a lo largo de los años, pero siento que debería intentarlo esta vez.

Mientras escribo esto, estoy empezando a pensar que este enfoque de "biblioteca común" es el resultado de echar un vistazo a la arquitectura. ¿Quizás mi diseño necesita más reflexión?

Interesado en escuchar pensamientos.

Respuesta:

Las bibliotecas y la reutilización son absolutamente buenas. Tienen una desventaja gigante, que es que si no se manejan con cuidado, se convierten en el equivalente al cajón de su cocina que contiene todas las cosas que no van a ningún otro lado.

Vi esto en acción cuando me hice responsable de los primeros puertos de código de una unidad de negocios completa (en su mayoría nuevo para mí) a sistemas de 64 bits y realicé una revisión completa de nuestra compilación y empaque, mucho de lo cual se estaba haciendo. a mano y, a veces, no muy bien. * Teníamos a construir lo que enviamos a partir de una pila de aplicaciones, donde el cliente decía: "Me gustaría un sistema que haga A, B, D y F, además de cosas M y N que todavía no haces y un pegamento ligeramente diferente integrándolos todos ". Todo lo que tenía en común era una biblioteca de cajones de basura que, durante un par de décadas, ** había acumulado todas las cosas que la gente pensaba que deberían ser reutilizables. Para abreviar una larga historia, una fracción del código en la biblioteca no se usó en ningún lado y estaba arrastrando muchas dependencias en cada proyecto que enviamos . Dedicamos mucho tiempo valioso a construir y mantener esas dependencias solo para que se instalara la biblioteca común, no porque realmente las necesitáramos.

La moraleja es que las bibliotecas deben ser tratadas como clases y no sobrecargadas con demasiadas responsabilidades. No coloque su analizador JSON en la misma biblioteca con sus funciones de álgebra lineal, incluso si cada programa que está escribiendo usa ambos.

Mantenerlos discretos tiene muchos beneficios, el mayor de los cuales es que obliga a sus desarrolladores y empaquetadores a elaborar una contabilidad detallada de lo que realmente necesitan sus propios productos en lugar de solo incluir el cajón de basura y el equipaje que lo acompaña. Cuando configura un sistema usando los paquetes construidos, las dependencias detalladas aseguran que solo se instalen las partes necesarias. Incluso si descuida su repositorio y continúa compilando las cosas viejas y crudas, nada de lo que ya no está en uso se filtra en lo que envía.

Por supuesto, existen excepciones como libc que agrupan una gran cantidad de funciones en una biblioteca. Ese es uno de los casos en los que los beneficios de hacerlo de esa manera se pueden razonar en lugar de prestar atención ciegamente al fanático del pasillo que insiste en que cualquier otra forma que no sea X siempre es una mala práctica.


* En el proceso, descubrí un binario que se había pasado y no se había recompilado desde cero en seis años.

** No hay nada de malo en el código de hace décadas. Teníamos una serie de algoritmos críticos que habían sido tan bien probados que habríamos sido tontos al reescribirlos únicamente en interés de la modernidad.

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım