5 Tipps zur Auswahl des richtigen Open-Source-Codes

Von Google durchgeführte Studien zeigen, dass das Auffinden von Code im Internet für viele Entwickler einen Großteil des Tages in Anspruch nimmt. Es ist nicht immer einfach, eine einfache Funktion, eine Bibliothek, ein nützliches Paket, eine wiederverwendbare Komponente oder ein nützliches Blog-Tutorial zu finden. Zu wissen, ob Sie dem gefundenen Code vertrauen und ihn verwenden können, kann noch schwieriger sein.

Den richtigen Code zu finden bedeutet normalerweise, sich an die Götter von Google oder anderen Suchmaschinen zu wenden, eine Anfrage einzuwerfen und für einen schnellen Gewinn die Daumen zu drücken. Einfache funktionale Abfragen wie "Javascript hat eigene Eigenschaften" führen wahrscheinlich zu verschiedenen Foren und Blog-Posts, während Beschreibungen auf höherer Ebene ("React-Komponente x") Sie oft in GitHub oder NPM landen.

Aber selbst nachdem Sie den richtigen Code gefunden haben, ist es ein ganz anderes Problem, ihm zu vertrauen und ihn zu verwenden. Um zu verstehen, welchen Code Sie tatsächlich verwenden können, habe ich 5 Parameter zusammengestellt, die hilfreich sein können. Bei der richtigen Entscheidung sollten (unter anderem) diese Parameter sowie die Art der Aufgabe selbst berücksichtigt werden. Hier sind die fünf Schlüssel, die Sie bei der Auswahl des richtigen Codes berücksichtigen können.

#1. Ist der Code lesbar?

Lesbarer Code bedeutet viel mehr als nur gute Kommentare und Dokumentation. Das bedeutet, dass der Code selbst für Sie lesbar sein sollte. Unterschiedliche Parameter für die Lesbarkeit können gute Namenskonventionen für Bezeichner, gute Abstände, klare lesbare Logik, gut verstandene Bereiche und mehr sein. Unterm Strich sollte der Code für Sie lesbar sein . Wenn Sie ein Stück Code auswählen, auch wenn es funktioniert, aber Sie verstehen nicht ganz, wie es funktioniert – Sie bringen im Grunde eine Wartungszeitbombe in Ihre Codebasis ein.

Das Debuggen, Ändern, Aktualisieren und Pflegen von Code, den Sie nicht lesen können, sollten Sie unbedingt vermeiden. Der beste Weg, dies zu vermeiden, besteht darin, es nach Möglichkeit gar nicht erst zuzulassen.

#2. Wird der Code aktiv gepflegt?

Wir möchten, dass der Code, den wir auswählen, „lebendig“ ist. Das heißt, wir möchten wissen, dass Bugs, Probleme und Updates behandelt werden und dieser Code von den Entwicklern, die ihn geschrieben haben, aktiv gepflegt wird. Ein schönes Beispiel für einen Aktivitätsindikator können die offenen Probleme, Pull-Requests und der Pulse-Indikator von GitHub sein. Paketmanager liefern wartungsrelevante Informationen wie die Anzahl der Abhängigkeiten und abhängigen Projekte, haben jedoch Schwierigkeiten, in diesem Bereich eine vertrauenswürdige Metrik zu präsentieren.

Wenn ein großes populäres Projekt jedoch von einem anderen Paket abhängig ist, können wir davon ausgehen, dass Probleme mit hoher Wahrscheinlichkeit behoben werden (allerdings erinnern wir uns alle an die linke Tastatur). Wenn Sie jedoch Code aus einem Stack-Überlauf kopieren (was an sich schon ein Problem darstellt), können Sie nicht sicher sein, dass dieser Code beibehalten wird, außer dass Sie ihn bei Bedarf selbst aktualisieren (und wo immer Sie ihn dupliziert haben).

Kleine Kernfunktionalitäten ändern sich einfach nicht so sehr. In diesem Sinne basieren aus Bit importierte wiederverwendbare Komponenten auf einer einfachen inkrementellen Versionierung, die die Version der Komponente jedes Mal um 1 erhöht, wenn der Autor etwas geändert hat. Wenn Sie Ihre Komponenten in einer "neuesten aktualisierten" Version halten, können Sie Ihren Code bei guten Tests aktiv von seinem Betreuer warten lassen und gleichzeitig selbst kleine Funktionen oder Komponenten in Ihrem Code aktualisieren, ohne etwas zu beschädigen.

#3. Ist der Code gut getestet?

Die Auswahl eines funktionierenden Codes ist wahrscheinlich unsere erste Priorität. Tests sind eine großartige Möglichkeit, um herauszufinden, ob der von mir verwendete Code tatsächlich tut, was er tun soll. Die Testbeschreibung präsentiert auch verschiedene Anwendungsfälle und Randfälle, die uns helfen zu wissen, wie sich dieser Code in verschiedenen Situationen verhält. Die Verwendung getesteter Komponenten sorgt für eine wartungsfreundlichere Software insgesamt und spart Zeit und Mühe, wenn Sie versuchen, Änderungen vorzunehmen, bevor Sie in die Produktion gehen.

Aus dem Internet kopierte Snippets werden normalerweise nicht mit Tests geliefert. Selten, wenn überhaupt, beinhalten Funktionen, die aus Foren oder Blogbeiträgen kopiert wurden, Unit-Tests. Pakete und Bibliotheken können sehr wohl getestet werden, das Problem liegt darin, es schnell herausfinden zu können. Beim Durchsuchen einer Bibliothek auf GitHub können verschiedene Badges oder Dateien im Repository angeben, wie gut und wie viel von diesem Code getestet wurde. Wir müssen weiterhin Indikatoren verwenden, die von externen Tools bereitgestellt werden, um herauszufinden, ob die Tests bestanden wurden oder nicht. Bei der Suche nach einem Paket gibt es keinen wirklich zuverlässigen Weg zu wissen, welches Paket getestet wird und ob die Tests sinnvoll bestanden wurden. Dies ist ein großes Problem, wenn es um die Auffindbarkeit von Paketen geht. Wiederverwendbar

Bei der Suche nach einem Paket gibt es keinen wirklich zuverlässigen Weg zu wissen, welches Paket getestet wird und ob die Tests sinnvoll bestanden wurden. Dies ist ein großes Problem, wenn es um die Auffindbarkeit von Paketen geht. Wiederverwendbare Bit-Komponenten können getestet werden, wenn solche Tests vom Entwickler hinzugefügt werden. Der Bit Scope führt den Test aus, sodass die grünen Anzeigen und die Testbeschreibung online angezeigt werden können, bevor eine Komponente aus dem Bit-Community-Hub ausgewählt wird (oder über die CLI bei verteilter Verwendung auf Ihrem lokalen Computer).

#4. Wird der Code von anderen verwendet?

Popularität ist etwas, dem wir evolutionär vertrauen. Die öffentliche Meinung ist gut, um Entscheidungen zu treffen, die unserem Überleben helfen. Wenn wir sehen, wie jeder eine bestimmte Frucht von einem Baum isst, wissen wir, dass es uns wahrscheinlich nicht umbringen wird. Wenn wir alle aus dem Gebüsch rennen sehen, könnte bald ein hungriger Tiger folgen. Dasselbe gilt bis zu einem gewissen Grad für die Auswahl des Codes 2017.

In Programmierforen können wir verschiedene Angaben verwenden, wie ein „V“, das die richtigen Antworten markiert, die Anzahl der positiv bewerteten und lautstarken Nutzermeinungen. Dies sind hervorragende und beruhigende Funktionen, um die Wahrscheinlichkeit zu erhöhen, dass der Code einwandfrei funktioniert. Wenn es um GitHub geht, können wir uns auf Stars, Kollaborateure und andere soziale Kennzahlen verlassen, um ein Gefühl der Vertrauenswürdigkeit zu bekommen. Bei der Suche nach Paketen ist die Anzahl der Downloads für dieses Paket ein guter Indikator.

Bit-Komponenten, die auf dem Bit-Community-Hub gefunden werden, zeigen die Anzahl der Downloads, Mitwirkenden (auf Scope-Ebene), einfache „Gefällt mir“ und mehr (wie in diesem React-Umfang von Komponenten gezeigt). Denken Sie in jedem Fall daran, dass soziale Metriken ein guter Indikator sind – aber keine absolute Wahrheit in Bezug auf die Qualität des Codes. Menschen liegen oft falsch und die öffentliche Meinung kann sich schneller ändern, als wir denken.

#5. Ist der Code gut dokumentiert?

Die Dokumentation macht Code viel einfacher zu verstehen, zu verwenden und zu ändern. Es ist auch ein großartiges Indiz für die Sorgfalt und Sorgfalt des Entwicklers, der den Code geschrieben hat. Die Dokumentation für Code, der auf Stack Overflow oder verschiedenen Blog-Posts gefunden wird, kann sowohl aus den Kommentaren im Code selbst als auch aus der eigentlichen Antwort oder dem Blog bestehen, in dem er gefunden wurde. Wenn eine Forumsantwort eine nützliche Ausarbeitung des enthaltenen Codes enthält, dies könnte sehr gut eine Dokumentation sein, die es wert ist, hinzugefügt zu werden, auch wenn der Code selbst kopiert und eingefügt wird (auch hier bitte keinen Code kopieren).

Bei GitHub-Repositorys und -Paketen sind die Dinge etwas kniffliger. Normalerweise geben die Readme- und docs-Dateien, die auf GitHub oder NPM präsentiert werden, einen allgemeinen Hinweis auf die Qualität der Dokumentation. Die Dokumentation für Bit-Komponenten wird aus dem Code selbst heraus geparst und zeigt daher die eigentliche Beschreibung für die atomare Komponente und kann auch Verwendungsbeispiele und eine angegebene Signatur enthalten, einschließlich Argumenten und Rückgaben für verschiedene Funktionen und Verhalten für React-Komponenten und andere. In jedem Fall ist es nach Möglichkeit eine gute Entscheidung, dokumentierten Code zu wählen.

Bei GitHub-Repositorys und -Paketen sind die Dinge etwas kniffliger. Normalerweise geben die Readme- und docs-Dateien, die auf GitHub oder NPM präsentiert werden, einen allgemeinen Hinweis auf die Qualität der Dokumentation. Die Dokumentation für Bit-Komponenten wird aus dem Code selbst heraus geparst und zeigt daher die eigentliche Beschreibung für die atomare Komponente und kann auch Verwendungsbeispiele und eine angegebene Signatur enthalten, einschließlich Argumenten und Rückgaben für verschiedene Funktionen und Verhalten für React-Komponenten und andere. In jedem Fall ist es nach Möglichkeit eine gute Entscheidung, dokumentierten Code zu wählen.

Die Entscheidung treffen

Letztendlich ist das menschliche Gedächtnis begrenzt und es macht nicht viel Sinn, das Rad jedes Mal neu zu erfinden. Wenn Sie jedoch einen Open-Source-Code finden und verwenden, können die oben genannten Indikatoren dazu beitragen, dass Ihre Anwendung sicher, wartbar, funktionsfähig und in gutem Zustand bleibt.

Unterschiedliche Anwendungsfälle bedeuten, dass den unterschiedlichen Parametern ein unterschiedliches Gewicht beigemessen wird. Bei der Auswahl eines Pakets ist es schwer zu sagen, wie getestet, lesbar, dokumentiert und aktiv gewartet wird. Beim Kopieren von Code aus einem Online-Forum geben wir der Popularität möglicherweise Vorrang vor Tests, Wartung und so weiter. Bit-Komponenten kombinieren Informationen, die für den Import und die Wiederverwendung von Komponenten und atomaren Funktionalitäten relevant sind, wie Beschreibung, Beispiele, Downloads, Abhängigkeiten, Testbeschreibung, Testergebnisse und mehr. Durch sorgfältige Berücksichtigung dieser verschiedenen Parameter können wir eine fundierte Entscheidung treffen und das Labyrinth der Suche und Auswahl des richtigen Codes für den Job durchqueren.