Fato divertido, pensei que xa escribira este post, pero cando quería referilo, descubrín que non. Neste post, gustaríame describir o meu enfoque ao escoller unha dependencia. Primeiro vou definir o que quero dicir por dependencia no contexto desta publicación. Entón, vou listar unha rede de varios criterios para analizar posibles dependencias con. Que é unha dependencia? Unha dependencia é literalmente algo do que depende o seu software: infraestrutura como un sistema de ficheiros ou unha base de datos, rede, etc. No contexto desta publicación, con todo, gustaríame restrinxir o alcance a unha dependencia de software que necesite compilar / executar. Diferentes pilas de software teñen diferentes nomes para esta biblioteca: O I.E 
 
 
 
 
 
 
 Ruby chámalle unha xoia Rust chámalle unha cratera Python e Node.js chámanlle paquete Chámaselle un módulo Maven/Gradle chámalle unha dependencia, de aí o nome que uso no título etc Teña en conta que a industria pasou a unha arquitectura baseada en servizos por razóns puramente de ingresos. Pódese acceder aos servizos a través dunha API REST ou algo máis. Construír vs. Comprar Cando necesitas un novo software, o habitual é construílo fronte a compralo.O mesmo razoamento podería aplicarse cunha nova dependencia, cunha opción adicional importante: Open Source.As razóns para escoller un sobre outro foron discutidas en moitos detalles ao longo dos anos. Aquí está a miña modesta contribución, a partir da miña experiencia persoal. Nos meus proxectos, son moi conservador en canto á visibilidade. Intento manter o acceso externo ao mínimo. tanto como sexa posible, incluíndo en construtores. Con todo, non pode usar construtores privados en probas. Xa que logo, ampliou a visibilidade para o paquete protexido, pero quería unha forma de documentalo. private No pasado, usei comentarios regulares ata que un colega apuntaba a Guava. Eu convertinme nun gran fan de inmediato. e aínda así, eu non traería a dependencia para Se esa é a única anotación que teño para Guava, entón prefiro crear a miña propia. Proba de visibilidade @VisibleForTesting Se eu precisase outras clases de Guava, con todo, eu reavaliaría a miña decisión. , un mapa con posibles valores múltiples almacenados baixo unha clave, require moito máis tempo para desenvolver. Supoño que engadiría a dependencia. Multimedia Multimap Como podedes ver, a decisión é bastante contextual. No resto deste post, asumiremos que a elección de construír non foi a mellor solución, e necesitamos seleccionar unha dependencia do que existe. Xestión de riscos Escoller unha adicción é un risco, e como con calquera risco, ten que aplicar correctamente : Técnicas de xestión de riscos 
 
 
 
 
 Identificar riscos: na seguinte sección, listarei varios elementos que podes considerar. Análise de cada risco. Considere a probabilidade e o seu impacto.As organizacións son diferentes.Unha considera o impacto dun risco específico como Baixo no seu contexto, pero outra o ve como ALTO.Non podo axudarche alí. Para cada risco, documentar as accións de mitigación e os seus custos asociados Monitor! A xestión de riscos non é unha actividade estática realizada unha vez. Mesmo no contexto das dependencias, poden aparecer novos riscos, por exemplo, un novo CVE crítico. Ademais, un risco pode aumentar a súa probabilidade, por exemplo, un comitente principal deixa o proxecto e reduce o factor de autobús a un nivel crítico. Criterios de elección A súa Escribín é a base sobre a que vou construír. Blurxo Licenzas e aspectos legais Creo que este é o aspecto máis importante de lonxe. tes que mirar a licenza. GitHub fai que sexa fácil de verificar: en primeiro lugar, anima a que os proxectos teñan unha arquivo; logo, amósase prominentemente na parte superior se é unha das licenzas de código aberto recoñecidas. LICENSE Ten que asegurarse de que entende a licenza. , é moi sinxelo: outros xa fixeron o traballo por ti. Para outros tipos, pode ser máis difícil. Algunhas dependencias son liberadas baixo unha licenza dual: unha Open Source e unha comercial. Na maioría das veces, pode asumir que a licenza Open Source é bastante restritiva e necesitará a comercial. Licenzas aprobadas Prezo O prezo ten tres modelos (que eu coñezo): 
 
 
 
 Prezo fixo Prezo variable baseado nalgúns factores, por exemplo, número de CPUs, número de usuarios, etc. Unha combinación do anterior A licenza pode ser por un tempo limitado ou para sempre. O meu mellor consello sería escribir os seus requisitos, o seu alcance e o seu orzamento. Entón, probablemente debería delegar a compra ao seu departamento de compras: son profesionais e son os mellores para negociar. Gobernanza Os proxectos comerciais son gobernados por unha empresa. O principal beneficio dun proxecto gobernado por unha empresa é o apoio financeiro. Pode converterse nun punto de inflexión se o proxecto non devolve os ingresos esperados. Outros beneficios probablemente incluirán habilidades profesionais para alavancar así como apoio (ver ligazón:#baixo). Os de código aberto ofrecen varias alternativas en canto á gobernanza: unha fundación, unha comunidade de desenvolvedores, ou unha única.As fundacións son a forma máis estable de gobernanza, semellante ás empresas.Algúns poden incluso apoiar proxectos financeiramente. , o , e o Funcionan baixo modelos moi diferentes. Fundación Apache Fundación Eclipse Fundación Linux A Fundación Apache baséase nos méritos individuais das persoas que traballan en proxectos.Eles proporcionan a infraestrutura (SCM, correo electrónico, construír infraestrutura, etc.), pero vostede está no seu propio máis aló. , parte da Fundación Linux, constrúe sobre empresas. Unha empresa convértese en parte da CNCF pagando unha contribución. cnc A influencia pode ser tan grande como dirixir o roteiro na dirección que quere, e tan pequeno como obter un bug fixado, ou mesmo obter a súa propia corrección fusionado. En calquera caso, espera xogar política para avanzar o seu obxectivo, aínda que con diferentes políticas dependendo do órgano gobernante. Maturidade Engadir unha dependencia é un compromiso: aforra tempo, pero perde o control.Se constrúe o seu software sobre un proxecto que non se mantén, terá que migrar o seu código para reducir a dependencia ou mantelo vostede mesmo. Aquí están algúns puntos de datos para avaliar a madurez dun proxecto: 
 
 
 
 
 Cando foi creado o proxecto?Proxectos máis antigos xeraron máis confianza. Cal é o seu historial de lanzamento? Canto máis regular a frecuencia de lanzamento, mellor é. O proxecto anuncia o seu roteiro?Se é así, canto é detallado?Un roteiro borroso, ou ningún, traizoa unha falta de visión; un demasiado detallado, especialmente no futuro afastado, podería ser un sinal de falta de axilidade ou realismo. Para proxectos comerciais, hai algo como soporte a longo prazo? Actividade Para proxectos de código aberto, debes comprobar a súa actividade. Un proxecto podería ter sido moi activo no pasado, pero perdeu a súa unidade ao longo do camiño. 
 
 
 
 How many issues are open? What's the median time to resolve an issue? What's the most common resolution status? What's the longest open issue? Answering these should give you a hint about the project's overall health. Cantas contas se comprometen ao proxecto? Cantas contas regularmente o fan, é dicir, cantos comitentes principais son? noutras palabras, cal é o factor Bus? Canto maior sexa o factor Bus, maior será a probabilidade de que o proxecto continúe se un comitente se detén. En relación co anterior, cal é a historia do compromiso dos principais comitentes? ¿Os comitentes están espallados entre varios proxectos non relacionados, ou se centran no que depende? Apoio O apoio inclúe tanto o apoio comercial como o apoio comunitario. Para a maioría das organizacións maduras, o soporte comercial é un requisito. As dependencias comerciais proporcionan tal soporte por natureza. Para proxectos de código aberto, o soporte varía de ningunha a empresas que proporcionan soporte a proxectos como parte do seu negocio principal. Na maioría das veces, estas empresas empregan desenvolvedores que traballan no proxecto. e Ofrecemos apoio ao Xestionado pola Fundación Apache. Tomiño heroínas Motor de Tomcat Servlet O apoio da comunidade é gratuíto, pero tamén un mellor esforzo.Non hai garantía de que alguén responderá ás túas peticións, e se o fai, cando. , GitHub, Slack, Grupos de Google, etc., e comproba: e. de g 
 
 
 
 O número de persoas que responden O atraso entre unha resposta e a pregunta A calidade das respostas Experiencia de desenvolvedor A experiencia do desenvolvedor, tamén coñecida como DX, é un dos principais diferenciadores entre un bo proxecto e un gran. e grupos de contido nos seguintes grupos: tutoriais, guías de como, guías de referencia e explicacións. Divisións do sistema A maioría dos proxectos proporcionan documentación de referencia exhaustiva. Algúns ofrecen un inicio rápido. A miña primeira iniciativa de DevRel nun novo proxecto é xeralmente crear (ou facer que outros creen) un cando falta. Outro compoñente de DX provén do uso da propia dependencia. Recomendaría un prototipo dentro dun pequeno proxecto de caixa de tempo, utilizando a dependencia proporcionada. Daralle unha boa sensación para a Experiencia do Desenvolvedor. Se invistes moito, ten sentido prototipar un par de dependencias competidoras en paralelo. Adopción do mercado e ecosistema Eu mencionei anteriormente que a elección dunha dependencia é a xestión de riscos. Porque somos animais sociais, podemos confiar en que as persoas que elixiron a dependencia antes de nós tomaron unha decisión correcta. Ergo, canto máis organizacións usan a dependencia, maior é a probabilidade de que sexa a elección correcta. Con todo, teña coidado coa síndrome da mentalidade do rabaño: vexo moitas organizacións facendo só iso e elixindo algo que outros examinaron nun contexto completamente diferente. Tose, microservizos, tose. Eu tamén recomendaría comprobar o ecosistema ao redor, se se aplica. Unha dependencia de análise de CSV obviamente non se cualifica, pero unha lectura / escritura LDAP fai. Que provedores LDAP soporta? é compatible con Azure Directory, etc.? Finalmente, verifique se un ou máis membros do equipo xa están familiarizados coa dependencia. Miscela Nunca usei ningún dos seguintes criterios; non vou desenvolver. con todo, poden ser relevantes no seu contexto. 
 
 
 
 
 
 
 Xestión de vulnerabilidades e tempo de resposta Dependencia saúde e actualización de frecuencia Política de Seguridade Pública Benchmarks públicos e métricas de rendemento Exemplos de escalabilidade do mundo real Estabilidade da empresa e transparencia financeira Resumo Neste post, enumerei varios criterios que podes usar para avaliar as dependencias. Publicado orixinalmente en A Java Geek o 2 de novembro de 2025. Xogos de Java Geek

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Este audio está producido na lingua orixinal da historia!

Como elixir unha dependencia: construír vs compra, xestión de riscos, e máis

About Author

COMENTARIOS

Etiquetas colgantes

ESTE ARTIGO FOI PRESENTADO EN

Related Stories

Coñece R Systems: HackerNoon empresa da semana

HackerNoon Decoded 2024: Celebrating Our Programming Community!

HackerNoon Decoded 2024: Celebrating Our HackerNoon Community!

HackerNoon Decoded 2024: Celebrating Our Media Community!

Coñece R Systems: HackerNoon empresa da semana

HackerNoon Decoded 2024: Celebrating Our Programming Community!

HackerNoon Decoded 2024: Celebrating Our HackerNoon Community!

HackerNoon Decoded 2024: Celebrating Our Media Community!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps