Curioso hecho, pensé que ya había escrito este post, pero cuando quería referirse a él, descubrí que no lo era. En este post, me gustaría describir mi enfoque al elegir una dependencia. Primero definiré lo que quiero decir por dependencia en el contexto de este post. ¿Qué es una dependencia? Una dependencia es literalmente algo de lo que su software depende: infraestructura como un sistema de archivos o una base de datos, red, etc. En el contexto de este post, sin embargo, me gustaría restringir el alcance a una dependencia de software que necesita compilar / ejecutar, Diferentes pilas de software tienen diferentes nombres para esta biblioteca: El I.E 
 
 
 
 
 
 
 Ruby lo llama una joya Rust lo llama un cráter Python y Node.js lo llaman un paquete Lo llaman un módulo Maven/Gradle lo llama una dependencia, de ahí el nombre que uso en el título etc . Tenga en cuenta que la industria ha cambiado a una arquitectura basada en servicios por razones puramente de ingresos. Uno puede acceder a los servicios a través de una API REST u otra cosa. En cualquier caso, se aplican los mismos criterios de evaluación. Comprar vs. comprar Cuando necesitas un nuevo software, lo habitual es construirlo en comparación con comprarlo.El mismo razonamiento podría aplicarse con una nueva dependencia, con una opción adicional importante: Open Source.Los motivos para elegir uno sobre otro se han discutido en muchos detalles a lo largo de los años. Aquí está mi modesta contribución, de experiencia personal. En mis proyectos, soy muy conservador en cuanto a la visibilidad. Intento mantener el acceso externo al mínimo. tanto como sea posible, incluso en constructores. Sin embargo, no se puede utilizar constructores privados en las pruebas. Por lo tanto, amplié la visibilidad a los protegidos por paquete, pero quería una manera de documentarlo. private En el pasado, usé comentarios regulares hasta que un colega señaló los efectos de Guava. Me convertí en un gran fan de inmediato.Y sin embargo, no traería la adicción a Si esa es la única anotación que tengo para Guava, entonces prefiero crear mi propia. @VisibleTestado @VisibleForTesting Si necesito otras clases de Guava, sin embargo, reevaluaría mi decisión. , un mapa con posibles valores múltiples almacenados bajo una clave, requiere mucho más tiempo para desarrollar. Probablemente añadiría la dependencia. Multimedia Multimap Como podéis ver, la decisión es bastante contextual. En el resto de este post, asumiremos que elegir construir no fue la mejor solución, y necesitamos seleccionar una dependencia de lo que existe. Gestión de riesgos Elegir una adicción es un riesgo, y como con cualquier riesgo, es necesario aplicar adecuadamente : Técnicas de gestión de riesgos 
 
 
 
 
 Identificar riesgos: en la próxima sección, listaré varios elementos que puede considerar. Analizar cada riesgo. Considera la probabilidad y su impacto(s). Las organizaciones son diferentes. Uno considera el impacto de un riesgo específico como Bajo en su contexto, pero otro lo ve como ALTO. Para cada riesgo, documentar las acciones de mitigación y sus costes asociados Monitor! Gestión de riesgos no es una actividad estática hecha una vez. Incluso en el contexto de las dependencias, pueden aparecer nuevos riesgos, por ejemplo, un nuevo CVE crítico. Además, un riesgo puede aumentar su probabilidad, por ejemplo, un comisionado principal abandona el proyecto, y reduce el factor de autobús a un nivel crítico. Criterios de elección El Escribo es la base sobre la que construiré. Blurb Licencias y aspectos legales Creo que este es el aspecto más importante de todos los tiempos.Tienes que mirar la licencia.GitHub hace que sea fácil verificarlo: en primer lugar, anima a los proyectos a tener una archivo; luego, lo muestra prominentemente en la parte superior si es una de las licencias de código abierto reconocidas. LICENSE Usted debe asegurarse de que entiende la licencia. , es bastante fácil: otros ya han hecho el trabajo para usted. Para otros tipos, puede ser más difícil. Algunas dependencias se liberan bajo una doble licencia: una Open Source y una comercial. La mayoría de las veces, puede asumir que la licencia Open Source es bastante restrictiva y necesitará la comercial. Licencias aprobadas por OSI Precio El precio tiene tres modelos (de los que conozco): 
 
 
 
 Precio fijo Precio variable basado en algún factor (s), por ejemplo, el número de CPU, el número de usuarios, etc. Una combinación de lo anterior La licencia puede ser para un tiempo limitado o para siempre. Mi mejor consejo sería escribir sus requisitos, su alcance y su presupuesto.Entonces, probablemente debería delegar la compra a su departamento de compras: son profesionales y son los mejores con los que negociar. Gobernanza Los proyectos comerciales son gobernados por una empresa.El principal beneficio de un proyecto administrado por la empresa es el apoyo financiero. Puede convertirse en un punto de inflexión si el proyecto no devuelve los ingresos esperados.Otros beneficios probablemente incluirán habilidades profesionales para aprovechar así como apoyo (ver enlace:#abajo). Los de código abierto ofrecen varias alternativas en cuanto a la gobernanza: una fundación, una comunidad de desarrolladores, o una única. Las fundaciones son la forma más estable de gobernanza, similar a las empresas. , el , y el operan bajo modelos muy diferentes. Fundación Apache Fundación Eclipse Fundación Linux La Fundación Apache se basa en los méritos individuales de las personas que trabajan en proyectos. Ellos proporcionan la infraestructura (SCM, correo electrónico, construcción de infraestructura, etc.), pero usted está por su cuenta más allá de eso. , parte de la Fundación Linux, se basa en empresas. Una empresa se convierte en parte de la CNCF pagando una contribución. cncf Cuanto más grande sea el grupo que gobierna el proyecto, más tiempo será necesario para influir.La influencia puede ser tan grande como conducir el mapa de ruta en la dirección que desea, y tan pequeño como conseguir que un bug se fije, o incluso conseguir que su propia solución se fusione. En cualquier caso, espere jugar a la política para avanzar en su objetivo, aunque con diferentes políticas dependiendo del órgano de gobierno. madurez La adición de una dependencia es un compromiso: ahorras tiempo, pero pierdes el control.Si construyes tu software sobre un proyecto que no se mantiene, necesitarás migrar tu código para reducir la dependencia o mantenerlo tú mismo. Aquí hay un par de puntos de datos para evaluar la madurez de un proyecto: 
 
 
 
 
 ¿Cuándo se creó el proyecto?Los proyectos más antiguos generaron más confianza. ¿Cuál es su historia de lanzamiento?Cuanto más regular es la frecuencia de lanzamiento, mejor es. ¿Anuncia el proyecto su mapa de ruta? Si es así, ¿cuán detallado es?Un mapa de ruta borroso, o ningún, traiciona una falta de visión; uno demasiado detallado, especialmente en el futuro lejano, podría ser un signo de falta de agilidad o realismo. Para proyectos comerciales, ¿hay algo como soporte a largo plazo? Actividad Para proyectos de código abierto, debe comprobar su actividad.Un proyecto podría haber sido muy activo en el pasado, pero perdió su movimiento a lo largo del camino.En esta sección, debemos comprobar los siguientes elementos: 
 
 
 
 ¿Cuántos problemas están abiertos? ¿Cuál es el tiempo medio para resolver un problema? ¿Cuál es el estado de resolución más común? ¿Cuál es el problema abierto más largo? ¿Cuántas cuentas se comprometen al proyecto? ¿Cuántas cuentas lo hacen regularmente, es decir, cuántos comitentes principales son? En otras palabras, ¿cuál es el factor Bus? Cuanto mayor sea el factor Bus, mayor será la probabilidad de que el proyecto continúe si un comitente se detiene. En relación con lo anterior, ¿cuál es el historial de compromiso de los principales comitentes? ¿Los comitentes se distribuyen entre varios proyectos no relacionados, o se centran en el que usted depende? Apoyo El soporte abarca tanto el apoyo comercial como el apoyo de la comunidad. Para la mayoría de las organizaciones maduras, el apoyo comercial es un requisito. Las dependencias comerciales proporcionan tal apoyo por naturaleza. Para los proyectos de código abierto, el apoyo varía de ninguna a las empresas que proporcionan apoyo a los proyectos como parte de su negocio principal. y Ofrece apoyo a la Organizado por la Fundación Apache. Tomiño Héroes Motores de Tomcat Servlet El apoyo de la comunidad es gratuito, pero también un mejor esfuerzo.No hay garantía de que alguien responderá a sus peticiones, y si lo hacen, cuándo. , GitHub, Slack, Google Groups, etc., y compruebe: El E.G. 
 
 
 
 El número de personas que responden El retraso entre la respuesta y la pregunta La calidad de las respuestas Experiencia de desarrollador La experiencia del desarrollador, también conocida como DX, es uno de los diferenciadores clave entre un buen proyecto y un gran. Grupar el contenido en los siguientes grupos: tutoriales, guías de cómo hacer, guías de referencia y explicaciones. El sistema divino La mayoría de los proyectos proporcionan una documentación de referencia exhaustiva. Algunos ofrecen un inicio rápido. Mi primera iniciativa de DevRel en un nuevo proyecto es generalmente crear (o hacer que otros lo hagan) cuando falta. Otro componente de DX proviene del uso de la dependencia misma. Recomiendo un prototipo dentro de un pequeño proyecto de caja de tiempo, utilizando la dependencia proporcionada. Le dará una buena sensación para la Experiencia del desarrollador. Si invierte mucho, tiene sentido prototipar un par de dependencias competidoras en paralelo. Adopción del mercado y ecosistema I mentioned above that choosing a dependency is risk management. Because we are social animals, we can trust people who have chosen the dependency before us to have made a correct decision. Ergo, the more organizations use the dependency, the higher the chances it's the right choice. However, be careful with the herd mentality syndrome: I see many organizations doing just that and choosing something that others have vetted in a completely different context. Cough, microservice, cough. Still, a large market adoption increases the chance of activity and future support. También recomiendo comprobar el ecosistema, si se aplica. Una dependencia de análisis de CSV obviamente no se califica, pero una lectura / escritura LDAP lo hace. ¿Qué proveedores de LDAP soporta? ¿Es compatible con Azure Directory, etc.? Finalmente, compruebe si uno o más miembros del equipo ya están familiarizados con la adicción. Miscellano Nunca he utilizado ninguno de los siguientes criterios; no voy a desarrollarlos, sin embargo, pueden ser relevantes en su contexto. 
 
 
 
 
 
 
 Gestión de vulnerabilidades y tiempo de respuesta Dependencia de salud y frecuencia de actualización Política de Seguridad Pública Benchmarks públicos y métricas de rendimiento Ejemplos de escalabilidad en el mundo real Estabilidad de la empresa y transparencia financiera Resumen En este post, he listado varios criterios que puede utilizar para evaluar dependencias. Publicado originalmente en A Java Geek el 2 de noviembre de 2025. El nuevo Java Geek

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Este audio es producido en el idioma original de la historia!

Cómo elegir una dependencia: construcción vs compra, gestión de riesgos, y más

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Telegram: el puente de Crypto Island hacia el continente

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Telegram: el puente de Crypto Island hacia el continente

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps