Entwicklernews - 25_KW47 - Kurzrückblick auf die DevCon

Wie in der News mit der Ankündigung bereits geschrieben, musste die diesjährige DevCon leider wieder kurzfristig auf unseren Discord-Server verlegt werden. Ein persönliches Treffen war aus verschiedenen Gründen leider nicht möglich. Als positiven Nebeneffekt ergab es sich hierdurch aber, dass durch das Treffen im World Wide Web doch noch weitere Mitglieder des Entwicklerteams stunden- bzw. tageweise dazustoßen konnten. Es wurde aber umgekehrt ziemlich schnell vereinbart, das persönliche Treffen in den ersten Monaten des neuen Jahres nachzuholen, da sich einige Themen bei einem Treffen in Person viel besser besprechen lassen und das gemeinsame Arbeiten damit nochmal etwas anderes ist als nur virtuell verbunden zu sein.

Inhaltlich drehte sich wie erwartet viel um DMXControl 3. Neben verschiedenen Bug-Fixes nahm das Thema Code-Styling einen großen Teil der Zeit ein. Das Ziel ist hier, den Quellcode von DMXControl 3 sowohl optisch als auch technisch aufzuräumen. Bekanntermaßen bestehen einige Teile des Quellcodes von DMXControl 3 schon seit 2008. Hier kam in der Zwischenzeit nicht nur viel Quellcode hinzu. Auch das Coding hat sich durch die Weiterentwicklung von C# selbst weiterentwickelt. Dies gemeinsam mit einem gut lesbaren Code hilft am Ende auch der weiteren Entwicklung und der Fehlerbehebung. Eine große Herausforderung bei dem Thema ist, dass schlussendlich ein Großteil der Sourcecode-Dateien bei diesem Code-Styling-Prozess angefasst werden müssen. Im Kontext von DMXControl 3 sprechen wir dabei von über 2.500 Dateien, die in diesem Zuge editiert werden. Noch komplizierter wird es dadurch, dass die Software-Entwicklung kein einzelner Entwicklungsstrang ist. Typischerweise werden für die Entwicklung neuer Features oder die Behebung von Bugs separate Branches, also Abzweige vom Hauptbranch angelegt, in denen dann die Entwicklung stattfindet. Ist das Feature oder der Bugfix fertig, werden diese wieder in den Hauptbranch "gemerged". Geschehen so zwischenzeitig im Hauptbranch Änderungen, müssen auch die Feature- bzw. Bugfix-Branches aktualisiert werden. Nun gibt es aber durch das Code-Styling sehr viele Änderungen, die auch in den Codeteilen stattfindet, die durch die Feature- bzw. Bugfix-Entwicklung angepasst werden. So entstehen leider sehr sehr viele Konflikte, die größtenteils händisch aufgelöst werden müssen. Hier sind die Entwickler gerade noch am schauen, welche Branches wirklich aktualisiert werden müssen und welche Dinge vielleicht doch nur ein Versuch waren, aber so nie in die Software finden werden. So soll der Aufwand für den händischen Abgleich nicht allzu sehr explodieren.

Zum Thema Code-Styling passte auch das Paket "Protobuf-Dateien". Diese definieren die Kommunikation zwischen den verschiedenen Programmteilen von DMXControl 3 untereinander. Wir haben mittlerweile auf unserem Github-Auftritt ein Repository mit diesem Projekt veröffentlicht, damit auch Programme anderer Entwickler mit DMXControl 3 kommunizieren können. Hier wurde aber bisher die bestehende Projektstruktur aus DMXControl 3 1:1 übernommen. Diese Struktur war zwar für die DMXControl 3-Entwickler optimal, aber für die Einbindung in andere Projekte leider nicht. Durch die Umstrukturierung kann unser öffentliches Protobuf-Schnittstellen-Repository ab der nächsten DMXC-Version dann sehr viel einfacher auch in Projekte mit anderer Programmiersprache integriert werden.

Ein weiterer Arbeitsbereich war das Thema 64-Bit-Version für den Kernel. Die Herausforderung ist hier, dass nicht alle DLLs der Ausgabeplugins für DMXControl 3 auch in einer 64-Bit-Version vorliegen. Leider sind nämlich 32-Bit-DLLs nur mit einer 32-Bit-Applikation kompatibel - wie es der Kernel aktuell nämlich ist. Somit können keine 32-Bit-DLLs einfach in einer 64-Bit-Applikation eingebunden werden, weil sich diese dort schlicht nicht laden lassen. Hier nutzte das Entwicklerteam die DevCon, um erste Gehversuche mit einem Handlingmodul zu unternehmen, welches sich (sofern nötig) als Schnittstelle zwischen den Kernel in der 64-Bit-Version und der 32-Bit-DLLs für das Ausgabeplugin hängt. So würde sich im Idealfall für den Nutzer nichts ändern und DMXControl 3 würde weiterhin auch in der 64-Bit-Version eine große Anzahl an DMX-Interfaces unterstützen. Des betrifft insbesondere DMX-Interfaces, wo wir auf den Quellcode der DLLs keinen Zugriff haben. Unsere Nodle-Interfaces sowie Art-Net und sACN sind dagegen nativ unter 64-Bit lauffähig. Aber es gibt eben nur vereinzelte 64-Bit-DLLs für USB-Interfaces von Dritten. Inwieweit die aktuellen Gehversuche erfolgreich sind, muss die nächste Zeit zeigen.

Dies sind natürlich nur ein paar Beispiele der Inhalte der vergangenen DevCon. Auch wenn ihr als Anwender von diesen Punkten oft nur wenig bis gar nichts tatsächlich am Ende in der Software seht, sind sie doch nicht minder wichtig, um ein effektives Arbeiten im Quellcode zu ermöglichen. Denn auch Quellcode ist am Ende nicht für die Ewigkeit gebaut und bedarf ähnlich wie ein Haus mit einer gewissen Regelmäßigkeit Pflege und Erneuerung - oftmals auch auf Grund von äußeren Einflüssen.

Euer DMXControl-Team