In diesem Beitrag möchte ich meinen Ansatz bei der Auswahl einer Abhängigkeit beschreiben.Ich werde zuerst definieren, was ich mit Abhängigkeit im Kontext dieses Beitrags meine. Was ist eine Abhängigkeit? Eine Abhängigkeit ist buchstäblich etwas, von dem Ihre Software abhängt: Infrastruktur wie ein Dateisystem oder eine Datenbank, ein Netzwerk usw. Im Zusammenhang mit diesem Beitrag möchte ich den Umfang jedoch auf eine Softwareabhängigkeit einschränken, die Sie kompilieren / ausführen müssen. Verschiedene Software-Stacks haben unterschiedliche Namen für diese Bibliothek: I. E 
 
 
 
 
 
 
 Ruby nennt es ein Gem Rust nennt es ein Krater Python und Node.js nennen es ein Paket Go nennt es ein Modul Maven/Gradle nennt es eine Abhängigkeit, daher der Name, den ich im Titel benutze etc etc. Beachten Sie, dass sich die Branche aus reinen Einnahmengründen auf eine servicebasierte Architektur verlagert hat.Man kann über eine REST API oder etwas anderes auf Dienste zugreifen. Build vs. Kaufen Wenn Sie neue Software benötigen, ist es üblich, sie zu bauen oder zu kaufen. dasselbe Argument könnte mit einer neuen Abhängigkeit gelten, mit einer wichtigen zusätzlichen Option: Open Source. Die Gründe für die Wahl eines über das andere wurden im Laufe der Jahre in vielen Details diskutiert. Hier ist mein bescheidener Beitrag, aus persönlicher Erfahrung. In meinen Projekten bin ich sehr konservativ in Bezug auf Sichtbarkeit. Ich versuche, den externen Zugriff auf ein Minimum zu halten. So viel wie möglich, auch in Konstruktoren. Allerdings können Sie private Konstruktoren bei Tests nicht verwenden. Daher habe ich die Sichtbarkeit auf Paketgeschützte erweitert, aber ich wollte eine Möglichkeit, es zu dokumentieren. private In der Vergangenheit habe ich regelmäßige Kommentare verwendet, bis ein Kollege auf Guava's Ich wurde sofort zu einem großen Fan. Und doch würde ich die Abhängigkeit nicht mitbringen. Wenn das die einzige Annotation ist, die ich für Guava habe, dann würde ich lieber meine eigene erstellen. @VisibleTesting @VisibleForTesting Wenn ich jedoch andere Klassen aus Guava brauche, würde ich meine Entscheidung überdenken. , eine Karte mit möglicherweise mehreren Werten unter einem Schlüssel gespeichert, erfordert viel mehr Zeit zu entwickeln. Ich würde wahrscheinlich die Abhängigkeit hinzufügen. Multimap Multimap Wie Sie sehen können, ist die Entscheidung ziemlich kontextabhängig. Im Rest dieses Beitrags werden wir davon ausgehen, dass die Wahl zu bauen nicht die beste Lösung war, und wir müssen eine Abhängigkeit von dem auswählen, was existiert. Risikomanagement Eine Sucht zu wählen, ist ein Risiko, und wie bei jedem Risiko, müssen Sie richtig anwenden : Risikomanagement Techniken 
 
 
 
 
 Identifizieren Sie Risiken: Im nächsten Abschnitt werde ich einige Elemente auflisten, die Sie berücksichtigen können. Analysieren Sie jedes Risiko. Betrachten Sie die Wahrscheinlichkeit und ihre Auswirkungen. Organisationen sind unterschiedlich. Man betrachtet die Auswirkungen eines bestimmten Risikos als LOW in ihrem Kontext, aber ein anderer sieht es als HIGH. Für jedes Risiko dokumentieren Sie Abschwächungsmaßnahmen und die damit verbundenen Kosten Auch im Zusammenhang mit Abhängigkeiten können neue Risiken auftreten, z.B. ein neuer kritischer CVE. Darüber hinaus kann ein Risiko seine Wahrscheinlichkeit erhöhen, z.B. verlässt ein Kernbeteiligter das Projekt und reduziert den Busfaktor auf ein kritisches Niveau. Auswahlkriterien Die Ich schreibe ist das Fundament, auf dem ich bauen werde. Blur Lizenz und rechtliche Aspekte Ich glaube, dies ist der wichtigste Aspekt bei weitem. Sie müssen sich die Lizenz ansehen. GitHub macht es einfach, es zu überprüfen: Erstens ermutigt es Projekte, eine Datei; dann wird es prominent oben angezeigt, wenn es eine der anerkannten Open Source-Lizenzen ist. LICENSE Sie müssen sicherstellen, dass Sie die Lizenz verstehen. , es ist ziemlich einfach: Andere haben bereits die Arbeit für Sie getan. Für andere Typen kann es schwieriger sein. Einige Abhängigkeiten werden unter einer doppelten Lizenz veröffentlicht: eine Open Source und eine kommerzielle. OSI-genehmigte Lizenzen Preise Der Preis hat drei Modelle (die ich kenne): 
 
 
 
 Fixierter Preis Variable Preis basierend auf einigen Faktoren, z.B. Anzahl der CPUs, Anzahl der Benutzer usw. Eine Kombination der oben genannten Die Lizenz kann entweder für eine begrenzte Zeit oder für immer sein. Mein bester Rat wäre, Ihre Anforderungen, Ihren Umfang und Ihr Budget aufzuschreiben. Dann sollten Sie den Kauf wahrscheinlich an Ihre Einkaufsabteilung delegieren: Sie sind Profis und sind die besten, mit denen Sie verhandeln können. Governance Kommerzielle Projekte werden von einem Unternehmen regiert. Der Hauptvorteil eines von einem Unternehmen verwalteten Projekts ist finanzielle Unterstützung. Es kann zu einem Problem werden, wenn das Projekt die erwarteten Einnahmen nicht zurückgibt. Andere Vorteile umfassen wahrscheinlich professionelle Fähigkeiten zur Hebelwirkung sowie Unterstützung (siehe Link:# unten). Open Source-Fundationen bieten mehrere Alternativen in Bezug auf Governance: eine Stiftung, eine Community von Entwicklern oder eine einzige.Fundationen sind die stabilste Form der Governance, ähnlich wie Unternehmen. , die Und die Sie arbeiten unter sehr unterschiedlichen Modellen. Die Apache Foundation Die Eclipse Foundation Linux Stiftung Die Apache Foundation baut auf den individuellen Verdiensten der Menschen auf, die an Projekten arbeiten. Sie bieten die Infrastruktur (SCM, E-Mail, Build-Infrastruktur usw.), aber Sie sind selbst darüber hinaus. , Teil der Linux Foundation, baut auf Unternehmen auf. Ein Unternehmen wird Teil der CNCF, indem es einen Beitrag zahlt. CNCF Je größer die Gruppe, die das Projekt steuert, desto länger dauert es zu beeinflussen.Der Einfluss kann so groß sein, wie die Roadmap in die gewünschte Richtung treiben, und so klein, wie ein Bug behoben werden oder sogar Ihre eigene Fix zusammengeführt werden. Die Interaktion mit Entwicklern wird für technisch geistige Menschen einfacher sein.In jedem Fall erwarten Sie, dass Sie Politik spielen, um Ihr Ziel voranzutreiben, wenn auch mit unterschiedlicher Politik je nach Regierungsorgan. Maturität Das Hinzufügen einer Abhängigkeit ist ein Kompromiss: Sie sparen Zeit, aber Sie verlieren die Kontrolle. Wenn Sie Ihre Software auf einem Projekt aufbauen, das nicht aufrechterhalten wird, müssen Sie entweder Ihren Code migrieren, um die Abhängigkeit zu reduzieren oder sie selbst aufrechtzuerhalten. Hier sind ein paar Datenpunkte, um die Reife eines Projekts zu bewerten: 
 
 
 
 
 Wann wurde das Projekt gegründet?Altere Projekte erzeugen mehr Vertrauen. Was ist seine Veröffentlichungshistorie? Je regelmäßiger die Frequenz, desto besser ist es. Kündigt das Projekt seine Roadmap an? Wenn ja, wie detailliert ist es? Eine verschwommene Roadmap, oder überhaupt keine, verrät einen Mangel an Vision; eine zu detaillierte, vor allem in der fernen Zukunft, könnte ein Zeichen für einen Mangel an Agilität oder Realismus sein. Gibt es für kommerzielle Projekte so etwas wie langfristige Unterstützung? Aktivitäten Bei Open-Source-Projekten müssen Sie ihre Aktivität überprüfen.Ein Projekt könnte in der Vergangenheit sehr aktiv gewesen sein, verlor jedoch seinen Antrieb.In diesem Abschnitt sollten wir die folgenden Elemente überprüfen: 
 
 
 
 Wie viele Probleme sind geöffnet? Was ist die mediane Zeit, um ein Problem zu lösen? Was ist der häufigste Auflösungsstatus? Was ist das längste offene Problem? Wie viele Konten verpflichten sich zum Projekt? Wie viele Konten tun dies regelmäßig, d.h. wie viele Kernkommissare sind sie? Mit anderen Worten, was ist der Bus-Faktor? Je höher der Bus-Faktor, desto größer ist die Wahrscheinlichkeit, dass das Projekt fortgesetzt wird, wenn ein Kommissar aufhört. Im Zusammenhang mit dem oben genannten, was ist die Verpflichtungshistorie der wichtigsten Kommissare? Sind Kommissare unter mehreren unabhängigen Projekten verbreitet, oder konzentrieren sie sich auf das, von dem Sie abhängen? Unterstützung Der Support umfasst sowohl kommerzielle Unterstützung als auch Community-Unterstützung. Für die meisten reifen Organisationen ist kommerzielle Unterstützung eine Voraussetzung. kommerzielle Abhängigkeiten bieten solche Unterstützung von Natur aus. Für Open-Source-Projekte reicht die Unterstützung von null bis hin zu Unternehmen, die Projekte als Teil ihres Kerngeschäfts unterstützen. Meistens beschäftigen diese Unternehmen Entwickler, die an dem Projekt arbeiten. und bieten Unterstützung für die Es wird von der Apache Foundation gehostet. Tomitribe Heldinnen Tomcat Servlet Motoren Unterstützung von der Gemeinschaft ist kostenlos, aber auch eine beste Anstrengung. Es gibt keine Garantie, dass jemand auf Ihre Bitten antwortet, und wenn sie dies tun, wann. , GitHub, Slack, Google Groups usw. und überprüfen Sie: Die e.g. 
 
 
 
 Die Anzahl der Menschen, die antworten Die Verzögerung zwischen einer Antwort und der Frage Die Qualität der Antworten Entwickler Erfahrung Entwicklererfahrung, auch bekannt als DX, ist einer der Schlüsseldifferenzatoren zwischen einem guten Projekt und einem großen. Gruppen Sie Inhalte in folgende Gruppen: Tutorials, How-to-Guides, Referenz-Guides und Erläuterungen. Divisionsystem Die meisten Projekte bieten eine umfassende Referenzdokumentation. Einige bieten einen schnellen Start. Meine erste DevRel-Initiative bei einem neuen Projekt besteht im Allgemeinen darin, ein neues Projekt zu erstellen (oder andere dazu zu bringen, es zu erstellen), wenn es fehlt. Ein weiterer Bestandteil von DX kommt aus der Verwendung der Abhängigkeit selbst. Ich würde einen Prototyp innerhalb eines kleinen Zeitbox-Projekts empfehlen, wobei die angegebene Abhängigkeit verwendet wird. Es wird Ihnen ein gutes Gefühl für die Entwicklererfahrung geben. Wenn Sie viel investieren, ist es sinnvoll, ein paar konkurrierende Abhängigkeiten parallel zu prototypen. Marktadoption und Ökosystem Ich habe oben erwähnt, dass die Wahl einer Abhängigkeit das Risikomanagement ist. Weil wir soziale Tiere sind, können wir Menschen vertrauen, die die Abhängigkeit vor uns gewählt haben, dass sie eine richtige Entscheidung getroffen haben. Ergo, je mehr Organisationen die Abhängigkeit verwenden, desto höher sind die Chancen, dass es die richtige Wahl ist. Seien Sie jedoch vorsichtig mit dem Herdenmentalitätssyndrom: Ich sehe viele Organisationen, die genau das tun und etwas wählen, das andere in einem völlig anderen Kontext überprüft haben. Husten, Mikroservice, Husten. Ich empfehle auch, das Ökosystem zu überprüfen, wenn es zutrifft. Eine CSV-Auflösungsabhängigkeit ist offensichtlich nicht qualifizierend, aber ein LDAP-Lesen/Schreiben tut es. Welche LDAP-Anbieter unterstützen es? ist es Azure Directory kompatibel usw.? Schließlich prüfen, ob ein oder mehrere Teammitglieder bereits mit der Abhängigkeit vertraut sind. Missgeschicke Ich habe niemals eines der folgenden Kriterien verwendet; Ich werde es nicht entwickeln. 
 
 
 
 
 
 
 Schwachstellenmanagement und Reaktionszeit Abhängigkeit Gesundheit und Aktualisierung Frequenz Öffentliche Sicherheitspolitik Öffentliche Benchmarks und Leistungsmetriken Beispiele für Skalierbarkeit in der realen Welt Unternehmensstabilität und Finanztransparenz Zusammenfassung In diesem Beitrag habe ich mehrere Kriterien aufgelistet, die Sie verwenden können, um Abhängigkeiten zu bewerten. Ursprünglich veröffentlicht in A Java Geek am 2. November, 2025 Ein Java Geek

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Wie man eine Abhängigkeit wählt: Build vs. Buy, Risikomanagement und mehr

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon's DeFi Writing Contest with SORA Network: XSTUSD Use Cases

HackerNoon Decoded 2024: Celebrating Our AI Community!

HackerNoon Decoded 2024: Celebrating Our Management Community!

Genuine Content Creation in the Age of AI: Why Startups Need Quality Content

HackerNoon's DeFi Writing Contest with SORA Network: XSTUSD Use Cases

HackerNoon Decoded 2024: Celebrating Our AI Community!

HackerNoon Decoded 2024: Celebrating Our Management Community!

Genuine Content Creation in the Age of AI: Why Startups Need Quality Content

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps