Wie man von Open Source lernt

Ich sehe dieses Problem ziemlich oft. Ich mag ein bestimmtes Wertversprechen eines Open-Source-Projekts. Ich probiere die grundlegenden Tutorials aus. Großartig. Es klappt! Wenn ich mich jedoch komplexeren Problemen zuwende, verbringe ich Stunden mit Recherchen, Debugging, Frustrationen usw.

Welche Strategien verfolgen Sie, um die Motivation für Open Source aufrechtzuerhalten? Was ist die Belohnung für Open Source nach dem Erfolg grundlegender Tutorials? Welchen "Erfolg" von Open Source haben Sie erlebt?

Ich gehe davon aus, dass Sie sich kleine Open-Source-Bibliotheken ansehen, wie sie auf Github zu finden sind. In meinem Fall verwende ich oft einen, um ein bestimmtes Problem zu lösen. Wenn es nicht sauber gelöst werden kann, greife ich ein, lerne, wie der Code funktioniert, und nehme bei Bedarf Änderungen vor. Wenn meine Änderung etwas Nützliches oder eine Fehlerbehebung betrifft, versuche ich, den Open Source-Eigentümer zu kontaktieren oder meinen eigenen Zweig zu teilen.

In anderen Fällen passe ich nur etwas an meine eigenen Bedürfnisse an. In diesen Fällen behalte ich einfach meine Änderungen bei und gehe weiter. Ich füge Uhren hinzu oder schaue regelmäßig wieder vorbei, um zu sehen, was aktualisiert wurde.

Wie in den Anmerkungen ist dies jedoch das Leben der Softwareentwicklung. Es ist eine sich ständig verändernde Umgebung.

Sie fragen, wie Sie die Motivation behalten , ein bestimmtes Open-Source-API-Projekt zu verwenden?

Der Trick besteht darin, herauszufinden, welche Open Source-Projekte die guten sind. Die Hauptqualifikation in Open Source ist die Tatsache, dass Sie Zugriff auf den Quellcode haben. Dies ist äußerst nützlich, wenn Sie herausfinden möchten, wie die Dinge funktionieren (was normalerweise passiert, wenn sich das Verhalten in bestimmten Situationen ändern muss), dies jedoch nicht implizieren etwas anderes als das. Dies schließt die Qualität des Projekts ein, die völlig unabhängig von der Offenheit der Quelle ist.

Qualität besteht aus mehreren mehr oder weniger subtilen Dingen, wenn von einem Code-Projekt gesprochen wird:

• Wie gut ist die API gestaltet? Kann der Code, den Sie schreiben müssen, um die API tatsächlich aufzurufen, problemlos gelesen werden?
• Wie gut ist der tatsächliche Code in der API geschrieben? Ist es leicht zu verstehen, was los ist? Sind die Datenstrukturen gut ausgewählt und haben sie keine teuren Laufzeitmerkmale? Sind Variablennamen gut gewählt? Entspricht der Code einem Codierungsstandard?
• Ist die API dokumentiert? Dies ist sowohl das Design als auch das Javadoc des eigentlichen Codes, und ist es nützlich? Dies ist wichtiger als Sie vielleicht denken, da es die Reife des Codes zeigt.
• Hat das Projekt eine Webseite? Ist es aktualisiert und ohne defekte Links? Bietet es einfachen Zugriff auf Quellcode, Downloads und Dokumentation?
• Hat das Projekt eine Community und Mailinglisten? Sind die Archive verfügbar und zugänglich? Ist die Community hilfreich?

All diese Dinge sind nützlich, wenn Sie auswählen, ob Sie ein bestimmtes Open Source-Projekt verwenden möchten oder nicht. Jede Ableitung von den Besten sollte dazu führen, dass ein Warnzeichen in Ihrem Kopf blinkt, da dies ein Hinweis darauf ist, dass dies kein Best-of-Breed-Projekt ist.

Wenn Sie dann das Projekt gefunden haben und Ihnen gefällt, was Sie sehen, gibt es den letzten Test:

• Wie schwierig ist es, mit einem einfachen Programm, das die API auf nützliche Weise aufruft, von Grund auf neu zu starten?

Das sollte sein

1. Erklärt an einer leicht zu erkennenden Stelle auf der Projektwebsite und / oder in der Dokumentation im Download-Bundle.
2. leicht richtig zu machen - die Dokumentation muss genau sein, das Programm muss einfach zu schreiben oder anhand eines gegebenen, einfachen Beispiels anzupassen sein und sowohl gut erklärt als auch leicht verständlich sein.
3. schnell richtig zu machen - wenn Sie an dieser Stelle ein Debugging durchführen müssen, damit das Programm wie erklärt ausgeführt wird, stimmt etwas nicht.

Wenn es offensichtlich ist, dass dies ein vorweggenommener und priorisierter Anwendungsfall ist, sollte dies trivial einfach sein. Wenn es offensichtlich ist, dass sich das Projekt nicht um diese spezielle Sache kümmert, würde ich nachdrücklich in Betracht ziehen, sie nicht zu verwenden! Wenn es hier bergauf geht, geht es viele, viele Male später bergauf, und es ist besser, es einfach nicht zu benutzen.