refactoring - una - librerias de visual studio 2017

¿Debería incluir bibliotecas de terceros que adopte en su proyecto? (16)

Cualquier incertidumbre sobre la elección de la biblioteca de terceros debe eliminarse al inicio del proyecto utilizando prototipos para probar la escalabilidad / idoneidad / cualquiera de las bibliotecas de terceros.
Si decide seguir adelante y proporcionar soporte completo de desacoplamiento / abstracción, el patrocinador del proyecto debe calcular el costo y, finalmente, aprobarlo. En última instancia, es una decisión comercial, ya que alguien tiene que pagar por ello y el trabajo requerido para hacerlo absolutamente trivial, en cuyo caso la api es probablemente de bajo riesgo de todos modos).
En general, un arquitecto experimentado elegirá una tecnología con la que pueda confiar razonablemente y con la experiencia y confianza en que durará toda la vida útil de la aplicación, o bien eliminará cualquier riesgo en la decisión al inicio del proyecto. eliminando así cualquier necesidad de hacer esto, la mayoría del tiempo

Una discusión que tuve hoy con un colega.

Afirma que siempre que utilice una biblioteca de terceros, siempre debe escribir para ello un contenedor. Por lo tanto, siempre puede cambiar las cosas más tarde y acomodarlas para su uso específico.

No estoy de acuerdo con la palabra siempre , surgió la discusión con respecto a log4j y afirmé que log4j ha probado y probado la API y la implementación, y que todo lo pensable puede configurarse a posteriori y no hay nada que deba incluir. Incluso si desea envolver, hay envoltorios comprobados como commons-logging y log5j.

Otro ejemplo que tocamos en nuestra discusión es Hibernate. Afirmé que tiene una API muy grande para ser envuelta. Además, tiene una API en capas que le permite ajustar su interior si lo necesita. Mi amigo afirmó que todavía cree que debería estar envuelto, pero no lo hizo debido al tamaño de la API (este compañero de trabajo es mucho más veterano que yo en nuestro proyecto actual).

Reclamé this , y esa envoltura se debe hacer en casos específicos:

No estás seguro de cómo se adaptará la biblioteca a tus necesidades.
solo utilizará una pequeña parte de una biblioteca (en cuyo caso solo podrá exponer una parte de su API).
no está seguro de la calidad de la API o la implementación de la biblioteca.

También mantuve que a veces puedes ajustar tu código en lugar de la biblioteca. Por ejemplo, colocar el código relacionado con su base de datos en una capa DAO, en lugar de envolver preventivamente todo el hibernado.

Bueno, al final esto no es realmente una pregunta, pero sus ideas, experiencias y opiniones son muy apreciadas.

Bueno, el beneficio obvio es para las tecnologías de conmutación. Si tiene una biblioteca que está en desuso y desea cambiar, puede terminar reescribiendo una gran cantidad de código para adaptarse al cambio, mientras que si estuviera ajustada, le resultaría más fácil escribir un nuevo contenedor para la nueva biblioteca. , que cambiando todo tu código.

Por otro lado, significaría que tiene que escribir un contenedor para cada biblioteca trivial que incluya, lo que probablemente sea una cantidad inaceptable de gastos generales.

Mi industria tiene que ver con la velocidad, por lo que la única vez que podría justificar la escritura de un envoltorio es si se tratara de una biblioteca crítica que probablemente cambie dramáticamente de forma regular. O, más comúnmente, si necesito tomar una nueva biblioteca y adaptarla a un código antiguo, lo cual es una realidad desafortunada.

Definitivamente no es una situación "siempre". Es algo que puede ser deseable. Pero el tiempo no siempre va a estar allí y, al final, si escribir una envoltura lleva horas y los cambios a largo plazo en la biblioteca de códigos serán pocos y triviales ... ¿Por qué molestarse?

Debes hacerlo siempre, a menudo, a veces, raramente, o nunca. Ni siquiera su colega lo hace siempre, pero los casos instructivos son siempre y nunca. Supongamos que a veces es necesario. Si nunca envolvió una biblioteca, la peor consecuencia es que un día descubrió que era necesario para una biblioteca que había usado por todos lados. Le tomaría un tiempo envolver esa biblioteca y realizar una cirugía de escopeta en los clientes. La pregunta es si esa eventualidad llevaría más tiempo que el suministro habitual de envoltorios que rara vez son necesarios, pero nunca teniendo que realizar la cirugía de escopeta.

Mi instinto es apelar al principio YAGNI (usted no lo va a necesitar) y optar por "raramente".

El factor principal para decidir envolver una biblioteca o no es el impacto que tendrá un cambio de biblioteca en el código. Cuando solo se llama a una biblioteca desde 1 clase, el impacto de cambiar de biblioteca será mínimo. Si en el otro lado se llama una biblioteca en todas las clases, es mucho más probable que haya un contenedor.

El problema aquí es parcialmente la palabra ''wrapper'', parcialmente una falsa dicotomía y parcialmente una falsa distinción entre el JDK y todo lo demás.

La palabra ''wrapper''

Envolver todo Hibernate, como usted dice, es una empresa completamente impráctica.

Por otra parte, restringir las dependencias de Hibernate a un conjunto de archivos fuente identificados y controlados puede ser práctico y lograr los mismos resultados.

La falsa dicotomia

La falsa dicotomía es el hecho de no reconocer una tercera opción: los estándares. Si usa, digamos, anotaciones JPA, puede intercambiar Hibernate por otras cosas. Si está escribiendo un servicio web y utiliza las anotaciones JAX-WS y JAX-B, puede intercambiar entre JDK, CXF, Glassfish, o lo que sea.

La falsa distincion

Claro, el JDK cambia lentamente y es poco probable que muera. Pero los principales paquetes de código abierto también cambian lentamente y es poco probable que mueran. No se cuentan miles de desarrolladores y proyectos que utilizan Hibernate. Realmente no hay más riesgo de que Hibernate desaparezca o realice cambios de API incompatibles radicales que el propio Java.

El propósito de envolver incluso una biblioteca de terceros bien probada y comprobada es que puede decidir cambiar de biblioteca en algún momento en el futuro. Envolverlo hace que sea más fácil cambiar sin cambiar ningún código en su aplicación principal. Solo la envoltura necesita cambiar.

Si está absolutamente seguro de que nunca (otro absoluto) utilizará un marco de registro diferente en su proyecto, siga adelante y omita el contenedor. Incluso habiendo dicho eso, probablemente no esperaría escribir el envoltorio hasta que supiera que lo necesitaba, como la primera vez que necesito cambiar.

En mi experiencia, la pregunta se vuelve bastante discutible si estás usando abstracciones lo suficiente. Acoplarse a una biblioteca es como acoplarse a cualquier otra interfaz. Por lo tanto, desea reducir el acoplamiento accidental y el alcance de la reescritura necesaria si necesita cambiar la implementación. No vincules la lógica de tu aplicación con alguna construcción, pero no solo formes un montón de envoltorios estúpidos (literalmente) alrededor de algo y esperes obtener algún beneficio.

Una envoltura no suele ganar nada a menos que esté respondiendo a un propósito específico (como polimorfizar una construcción no polimórfica). A menudo aparecen en refactorización, pero yo no recomendaría que se les forme una arquitectura. Hay algunas excepciones, por supuesto, pero las hay con cualquier principio.

Esto no habla hacia los adaptadores. Un adaptador puede ser un componente muy importante para cuando realmente desea modificar la interfaz de una biblioteca y su uso para estar en línea con la arquitectura, el código o los conceptos de dominio en su proyecto.

Envolver una biblioteca completa es repetitivo, ineficaz e incorrecto en la mayoría de los casos. Se puede hacer de una manera mucho más inteligente. Yo diría que envolver una biblioteca es apropiado principalmente en el caso de las bibliotecas de componentes de la interfaz de usuario, y una vez más, tiene que agregar algunas de las funciones centrales adicionales suyas a todos los componentes para que esto sea necesario.

Si se necesitan demasiadas modificaciones y adiciones, es probable que esta no sea la biblioteca que está buscando.
si hay una cantidad moderada de adiciones y modificaciones, siempre hay patrones de diseño que son útiles en esos casos. El patrón Decorator (por ejemplo, permite que se agregue dinámicamente comportamiento nuevo / adicional a un objeto existente), por lo que es más adecuado para la mayoría de los casos.
Las capacidades de búsqueda / reemplazo y refactorización de IDE ofrecen una manera fácil de cambiar su código en todos los lugares requeridos si se necesitan cambios importantes y aparece un objeto de ajuste. (por supuesto, las pruebas unitarias serían útiles aquí;))

Es un ejemplo perfecto para YAGNI :

es mas trabajo
infla tu proyecto
puede complicar su diseño
no tiene beneficio inmediato
el guión para el que lo escribas nunca se manifiesta
cuando lo hace, lo más probable es que su envoltorio deba volver a escribirse completamente porque está muy relacionado con la biblioteca concreta que estaba usando y la API del nuevo uno simplemente no coincide con la suya.

Esta es una pregunta divertida.

He trabajado en sistemas en los que hemos encontrado errores de showstopper en las bibliotecas que estábamos usando, y que upstream ya no mantenía o no estaba interesado en reparar. En un lenguaje como Java, por lo general, no se pueden corregir errores internos de un contenedor. (Afortunadamente, si son de código abierto, al menos puedes arreglarlos tú mismo). Por lo tanto, no sirve de ayuda aquí.

Pero a menudo trabajo en un idioma en el que puede modificar fácilmente las bibliotecas en cualquier momento, sin ver ni tener su código fuente. Por lo general, agrego nuevos métodos a las clases existentes, por ejemplo. Entonces, en este caso, no tiene sentido envolver: simplemente haga el cambio que desea.

Además, ¿su colega traza la línea en cosas que se llaman "bibliotecas"? ¿Qué pasa con Java en sí? ¿Envuelve las clases incorporadas? ¿Envuelve el sistema de archivos? ¿El programador de hilos? El kernel? (Es decir, con sus propios envoltorios, en cierto sentido, todo es un envoltorio alrededor de la CPU, pero parece que está hablando de envoltorios en su fuente de repositorio que están completamente bajo su control). He tenido la funcionalidad incorporada Cambia o desaparece cuando aparecen nuevas versiones. Java no es inmune a esto.

Así que la idea de escribir siempre una envoltura se reduce a una apuesta. Suponiendo que solo está envolviendo bibliotecas de terceros, parece estar apostando implícitamente a que:

La funcionalidad de "primera parte" (como Java, el kernel, etc.) nunca cambiará
cuando la funcionalidad de "terceros" cambia, siempre se hará de una manera que se pueda arreglar en una envoltura

¿Es eso cierto en tu caso? No lo sé. De los proyectos de Java medianos y grandes que he hecho, rara vez es cierto para mí. No gastaría ningún esfuerzo envolviendo todas las bibliotecas de terceros, porque parece una mala apuesta, pero su situación es ciertamente diferente a la mía.

Estoy de acuerdo con todo lo que se ha dicho bastante.

La única vez que es útil envolver el código de un tercero es útil (barra que viola YAGNI) es para pruebas de unidad.

Los simulacros de las estadísticas y demás requieren que envuelva el código, esta es una razón válida para escribir envoltorios para el código de terceros.

En el caso de código de registro, no es necesario sin embargo.

Hay una situación en la que con una buena razón puede envolver. Es decir, si necesita probar cosas, y el objeto de terceros predeterminado es un peso pesado. Entonces, tener una interfaz realmente puede hacer una diferencia.

Tenga en cuenta que esto no es para reemplazar la biblioteca, sino para que sea manejable donde no importa mucho.

No lo envolvería como una cosa a una, sino que colocaría la aplicación en capas para que cada parte sea reemplazable tanto como sea posible. El modelo ISO OSI funciona bien para todos los tipos de software :-)

No. Los arquitectos / wanna-bees de Java están demasiado ocupados diseñando contra cambios imaginarios.

Con el IDE moderno, es un pedazo de pastel cuando necesitas un cambio. Hasta entonces, que sea sencillo.

Si la biblioteca que planea envolver es única en sus "principios de acceso, metáforas e idiomas" de otras ofertas en el mismo dominio, entonces su envoltorio será similar a esa biblioteca y no le servirá de nada si un día, cambie a una biblioteca diferente, ya que necesitará un nuevo contenedor.

Si se accede a la biblioteca de forma similar a otras bibliotecas y el mismo envoltorio puede aplicarse a estas bibliotecas, es probable que se escriban en función de algún estándar existente y que ya exista alguna capa común para acceder a ellas.

Solo recurriría a envoltorios si estuviera seguro de que tendría que admitir múltiples y sustancialmente diferentes bibliotecas en producción.

Tiendo a estar de acuerdo con la mayoría de tus puntos. El uso de absolutos a menudo le causa problemas y decir que debe "siempre" hacer algo limita su flexibilidad. Yo añadiría algunos puntos más a tu lista.

Cuando utiliza un código de ajuste alrededor de una API muy común, como Hibernate o log4j, hace que sea más difícil atraer nuevos desarrolladores. Los nuevos desarrolladores ahora tienen que aprender una API completamente nueva, donde si no hubieras envuelto el código, habrían sido muy familiares de inmediato.

Por otro lado, también limita la vista de los desarrolladores a la API. El uso de una característica avanzada de la API lleva más tiempo porque debe asegurarse de que su envoltorio se implementa de una manera que pueda manejarlo.

Muchas de las capas de ajuste que he visto también son muy específicas de la implementación subyacente. Entonces, si escribe un contenedor de registro alrededor de log4j, está pensando en términos log4j. Si aparece un nuevo marco de referencia, puede cambiar todo el paradigma, por lo que su código de envoltura no migra tan bien como pensaba.

Definitivamente no estoy diciendo que el código de envoltura siempre sea malo, pero como usted dijo, hay muchos factores que debe considerar.