Open Source für Dummies 3

Viele Open-Source-Programmierer sitzen nicht gemeinsam in einem geschlossenen Raum und hacken dort ihr ganzes Projekt zusammen. Viele wollen transparent über Entscheidungen informieren und zusammen Entscheidungen treffen. Um diese dann umzusetzen und nach außen zu tragen, werden häufig einschlägige soziale Netzwerke benutzt. Um bestimmte Ereignisse in den Codebasen zu beobachten und automatisiert zu testen, werden häufig automatisierte Bots und Dienste verwendet.

Kommunikation

Um sich mit anderen Projektmitgliedern abzustimmen, gibt es viele Wege. Da zumeist asynchron kommuniziert wird, haben sich folgende gängige Tools etabliert:

• Mailing-Listen/Foren/GitHub Discussions - Um asynchron zu diskutieren
• Slack/Discord/Matrix (ehemals Gitter) - Um sich synchron auszutauschen
• Twitter/Mastodon - Um wichtige Mitteilungen zu verbreiten

Wichtig zu wissen ist, dass jedes Projekt seine einigene Strategie verfolgt. Es gibt hier nicht den einen Weg, den alle gehen.

Tests

Um zu verhindern, dass sich Regressionen im Code einschleichen, möchte man Tests schreiben. Da Tests nur etwas nützen, wenn sie regelmäßig ausgeführt werden, haben sich Services wie Travis, CircleCI & Jenkins etabliert. GitHub Actions und Gitlab CI sind auf den entsprechenden Plattformen natürlich auch nativ eingebunden.

Tests an sich können verschiedene Zwecke erfüllen. Die verschiedenen Gruppen haben Namen. Die Gruppen untereinander sind nicht perfekt voneianander abrenzbar.

• Unit-Tests: Diese Tests prüfen zumeist einzelne Funktionen und Methoden. Private Funktionen werden zumeist nicht getestet, da sie als Implementationsdetails angesehen werden.
• Funktionale Tests: Diese Tests prüfen einzelne logische Funktionsteile der Applikation/Bibliothek ab.
• Integration-Tests: Diese Tests prüfen, ob die Integration in eine produktionsnahe Umgebung wahrscheinlich erfolgreich sein wird.

Codeanalysen

Auch wenn viele erfahrene Programmierer es schaffen, gängige Fehler zu vermeiden, so kommt es doch häufiger als gedacht vor, dass man Flüchtigkeitsfehler macht. Die gängigsten lassen sich mit statischer Code Analyse finden. Diese  werden - verbunden mit Tools, die den Stil des Codes überprüfen - häufig gemeinsam mit kontinuierlicher Integration (Continous Integration bzw. kurz CI) genutzt.

Damit man eine Übersicht im Dschungel der Projekte, zu denen man beiträgt, behält, gibt es hierfür Webseiten wie Codacy, Code Climate & Sider, welche einem die Ergebnisse ansehnlich präsentieren und Verbesserungsvorschläge machen.

Jede Programmiersprache, aber auch größere Frameworks, legen hierbei immer ihre eigenen Kataloge an Regeln fest. Die meisten Kataloge werden laufend mit neuen Versionen der Sprachen und Frameworks überarbeitet und erweitert. Hierbei ist es wichtig zu beachten, dass viele Kataloge absichtlich sich widersprechende Regeln beinhalten. Dies hat den Hintergrund, dass es je nach Projekt sinnvoll sein kann, das Regelset der Linter (Name der Gruppe an Tools, die gerade erklärt wird) anzupassen.