Boehrsi.de - IT und Gaming Blog

Softwareentwicklung bedeutet neben neuen Features natürlich auch das auffinden und beheben von Bugs und Problemen. Nun sind Projekte groß, teils mit anderen zusammen entwickelt und entsprechend hat man einen mehr oder weniger tiefen Einblick in die verschiedenen Teilbereiche einer Software.
Umso befriedigender ist es eine grobe Beschreibung von einem Problem zu hören und direkt eine Idee zu haben, wo das Problem liegen könnte. Liegt man dann auch noch komplett richtig, ist dies meiner Meinung nach eines der besten Gefühle für Entwickler. Denn es zeigt das man den Code nicht nur kennt, sondern auch das man ihn verstanden und durchdrungen hat. Soll heißen man weiß nicht nur was passiert und wo es passiert, sondern auch warum und welche generellen Abläufe dahinter stecken.
Ebenfalls sehr angenehm empfinde ich es, wenn man vorhandene Konzepte und Strukturen in neuen Bereichen problemlos einsetzen kann. Da man sie flexibel genug aufgebaut hat, sodass auch andere Einsatzzwecke als der initial geplante umgesetzt werden können. Dabei kann es je nach Situation natürlich möglich sein das minimale Erweiterungen nötig sind, doch wenn die Grundideen und Abläufe weiterhin funktionieren fühlt man sich durchaus bestätigt.
Da man bei der Softwareentwicklung am Ende nicht zwangsweise etwas in der Hand hält und auch das Feedback der Nutzer oft sehr indirekt ist, finde ich es wichtig aus derartigen Dingen Freude zu ziehen. Denn am Ende sollte man ja auch Gefallen an dem finden was man tut, egal ob professionell oder im privaten Kontext. Insofern genießt den nächsten Bugfix oder das nächste Refactoring vielleicht einfach und freut euch darüber das ihr wisst was zu tun war, statt euch über eventuell blöde Fehler zu ärgern. Ein bisschen Fluchen zum abreagieren schadet hin und wieder aber natürlich trotzdem nicht.

Software benötigt oft viele Komponenten, welche aus verschiedenen Systemen bestehen, welche wiederum jeweils Logik beinhalten. Diese Kette von potentieller Komplexität und damit verbundenen Entwicklungsaufgaben kann je nach Projekt unterschiedlich ausgeprägt auftauchen. Doch vor allem bei der Entwicklung von neuen Projekten, vielleicht sogar mit neuen Konzepten oder Frameworks, kann es schnell zu einem unangenehmen Durcheinander an Aufgaben kommen.
Ich selbst bemerke dies aktuell in Kontext meiner Gehversuche in der Welt der Spieleentwicklung. Denn während ich Apps, Backends, Webseiten und generell Programme schon oft entwickelt habe, so sind Spiele und die damit verbundenen Aufgaben durchaus neu für mich. Am Ende ist es alles Code, aber die benötigte Logik und welche Komponenten zu welchem Zeitpunkt implementiert werden sollten ist trotzdem etwas neues. Diese neuen Abläufe sind für mich kein generelles Problem, aber ich erwische mich immer wieder dabei wie ich im Kopf über ein Probleme nachdenke und dabei in gefühlte fünf andere Teilbereiche abdrifte. Somit vermische ich dann diverse Dinge miteinander, was ein Problem ist. Denn bei fehlendem Fokus verliere ich Geschwindigkeit.

Ich nutze Git sehr gerne und mittlerweile liegen quasi alle meine Projekte in einem Repository (Remote). Dies betrifft sowohl Code, wie auch textuellen Content und Bilder. Lediglich Daten die im Kontext der Videobearbeitung entstehen sind ausgenommen, da ich sehr große Binaries ungern im Git habe.
Das Ganze läuft so gut, dass ich fast über meine eigenen Flows gestolpert wäre. Damit gemeint ist, dass ich alle Daten im Git ablege und wenn ich etwas lokal lösche oder fälschlicherweise bearbeite stellt dies ja kein Problem dar, denn die Daten sind ja noch im Git und somit habe ich quasi ein implizites Backup.
Genau dieses “alle Daten” ist aber nicht korrekt und hier möchte ich noch einmal etwas die Wahrnehmung schärfen, sowohl von mir selbst, wie auch von euch. Es geht z.B. um Keys, lokale Konfigurationsdateien und jegliche Secrets, welche einfach nicht in einem Git liegen sollten, egal ob privat oder öffentlich. In meinem Fall ging es um Konfigurationsdateien für das Bauen und Signieren meiner Android Apps. Denn zur Zeit bereite ich einen App Release vor, merkte aber gestern ein Release Build ist derzeit nicht möglich. Grund dafür war das Fehlen besagter Dateien. Diese gingen im Rahmen der Neuinstallation meines Systems vor einigen Monaten verloren und wurden beim folgenden Setup nicht wieder hergestellt, denn dort richtete ich lediglich das Git wieder ein.
Es gilt also mal wieder, egal ob man ein Git Repository oder eine andere Versionsverwaltungssoftware nutzt, egal wie man seine Daten verwaltet und egal wie sehr man davon ausgeht das man auf der sicheren Seite ist, Backups bleiben ein muss. Mir haben selbige einiges an Arbeit erspart, denn irgendwelche Passwörter und Keys zurückzusetzen ist etwas worauf ich so gar keine Lust habe, geschweige denn die Zeit. Insofern beleibt mir als Lesson learned nur zu sagen, dass das nutzen eines Git Repositories für mich die Entwicklung und Datenhaltung massiv verbessert, aber eben nicht den Bedarf reduziert regelmäßige Backups zu erstellen.

Ich bin Softwareentwickler und ich nutze Java. Laut Twitter müsste ich mich nun schlecht fühlen, doch überraschenderweise ist dies gar nicht der Fall. Doch warum schreibe ich so etwas überhaupt? Im Rahmen der als Log4shell open_in_new bekannten Sicherheitslücke, in der weit verbreiteten Java Library Apache Log4j 2 open_in_new, gab es natürlich auch diverse verallgemeinerte undifferenzierte Aufrufe Java zu verteufeln. Dabei will ich vorab klarstellen das Java bei weitem nicht das Allheilmittel für die Probleme der Softwarewelt ist, aber eben auch nicht die grundlegende Quelle all dieser.

In der Softwareentwicklung und auch als Serverbetreiber ist das Thema Sicherheit natürlich allgegenwärtig. Sicherheitsmaßnahmen wollen eingerichtet und getestet werden. Dafür hat man verschiedene Wege und nachdem die initialen Tests bestanden sind, läuft dann meist alles im alltäglichen Flow weiter.
Zusätzlich zu diesen Abläufen testete ich gestern eher unfreiwillig eine der Sicherheitsmaßnahmen meines Servers. Es geht um Fail2Ban open_in_new, ein Tool welches gegen Brute-Force Angriffe auf Logins und ähnliches schützen soll. Ein kleines feines und unkompliziertes Tool, welches ich gerne als zusätzlichen Sicherheits-Layer betreibe.
Nun hatte ich gestern zwar nicht vor zu prüfen ob Fail2Ban ordentlich läuft, tat es aber trotzdem. In diesem Rahmen war Abends mein Server plötzlich nicht mehr zu erreichen und ich fragte mich wo das Problem liegen könnte. Jegliche Verbindungen meinerseits endeten in Fehlern. Nach ein paar kurzen Nachfragen stellte sich aber heraus, dass nur ich direkt betroffen war, es also gar keinen Ausfall gab. Ein paar weitere Nachforschungen offenbarten dann das Problem. Ein altes Smartphone, welches ich zum Debugging während der Entwicklung genutzt hatte.

Es ist schon etwas länger her das in dieser Sammlung etwas geschrieben wurde, aber nun wird es mal wieder Zeit. Denn nach einem durchaus ausführlichen Gespräch mit einem guten Freund und Entwicklerkollegen, hab ich mal wieder neues Lesematerial für euch.
Heute geht es um das Thema Over-Engineering und das in verschiedenen Formen. Den Anfang macht dabei die oft angepriesene nutzerzentrierte Entwicklung von Anwendungen. Ein schönes Buzzword, welches quasi immer im Raum steht bei Anwendungen die für Endanwender gedacht sind, aber sehr oft und sehr schnell vergessen wird. Egal ob die kleine private Anwendung, ein internes Firmentool oder aber eine große App für einen Kunden, das Problem mit dem Over-Engineering ist allgegenwärtig.
Dies äußert sich quasi immer darin, dass man im stillen Kämmerlein entwickelt und entwickelt. Man baut Features, implementiert Abläufe und davon immer mehr und mehr. Manchmal hat man konkrete User Stories, manchmal hat man sich selber etwas überlegt, aber am Ende basiert alles meist auf Annahmen. Denn selbst die beste Marktanalyse kann nicht garantieren, dass die entwickelten Funktionen der Art und Weise wie der Endanwender mit der Anwendung umgehen wollen entspricht. Dies bekommt man im eingeschränkten Rahmen durch Tests raus, aber am besten einfach durch echte Nutzer, die die Anwendung wirklich im Alltag verwenden. Entsprechend gilt hier Release Early Release Often mehr denn je.

Eigentlich möchte man defensiv programmieren und entsprechend dem Nutzer möglichst viele Fehler vom Leib halten, das macht auch Sinn. Doch Workarounds und Fallbacks über und über einzusetzen, sodass man irgendwann eher Probleme einbaut als sie zu verhindern, ist meiner Meinung nach schlimmer als ein ordentlich kommunizierter Fehler. Als Beispiel würde ich hier ein Auto nehmen. Es hat Benzin im Tank und falls selbiger bald leer ist fährt man zur Tankstelle. Sollte diese geschlossen sein, macht es Sinn zur Sicherheit einen Kanister mit Benzin auf Reserve zu haben. Was aber eher wenig Sinn macht, ist alle zufällig herumstehenden Kanister des Nachbarn in den Tank zu schütten und zu hoffen es war Benzin dabei. Mit diesem Vorgehen hat man vielleicht in wenigen Fällen Glück, meist ist es aber eher eine wenig zielführende Idee.

Ich hatte schon häufiger das Thema der Codequalität hier im Blog und habe dafür geworben selbige hochzuhalten. Soll heißen bestehenden Code auch mal zu modernisieren, während der Entwicklung Dinge zu optimieren, statt zu duplizieren und Fehler die man zwischendurch entdeckt direkt zu beheben. Es gibt noch viele, viele weitere Möglichkeiten die Codequalität zu steigern, doch darum soll es heute gar nicht gehen.
Ich wollte mal konkret mitteilen warum ich es für wichtig halte nicht nur links und rechts Dinge anzubauen, sondern eben auch das große Ganze im Blick zu behalten. Ich habe vor kurzem die Ehre gehabt in ein halbwegs umfangreiches Projekt eine neue Funktion einzubauen, welche auf bestehender Logik aufsetzt und diese erweitert. An sich war der Ansatz recht simple, denn es sollte einfach ein bestehender Flow erweitert und mit verschiedenen Kontexten erneut ausgeführt werden. Alle anderen Abläufe, die auf diesem bestehenden Flow aufsetzen, mussten entsprechend angepasst werden, sodass sie den neuen Kontextbezug auch erfassen. Generell wäre das ein Aufgabe für einige Tage gewesen, allerdings wurde alles wesentlich umfangreicher.

Was macht eigentlich einen guten Entwickler aus? Über viele Punkte kann man hier sicherlich streiten, aber nach diversen Gesprächen mit Kollegen und befreundeten Softwareentwicklern, habe ich den einen oder anderen Punkt zusammengetragen, bei dem wir uns einig waren. Hierbei sollte vorab erwähnt werden, dass diese Liste natürlich nicht vollständig ist.
Beginnen möchte mit der guten alten Annahme, dass weniger Code immer besser ist, was definitiv nicht der Fall ist. Natürlich sollte man unnötigen Code vermeiden, aber manchmal ist es besser ein paar Zeilen extra zu schreiben, die klar machen warum eine Abfrage geschieht, statt unklare Konstrukte einfach so stehen zu lassen. In solchen Fälle erstelle ich lieber eine gut benannte Methode, spare mir Kommentare, halte den Code in einem wartbaren Zustand und füge entsprechend einige Zeilen extra hinzu. So wenig wie möglich, aber so viel wie nötig, um alles verständlich und wartbar zu halten.
Neu ist immer besser und Never change a running system, zwei Sprüche die bestimmt schon jeder Entwickler mal gehört hat. Beide entsprechen zum Teil der Wahrheit, sollten aber immer hinterfragt werden.
Ersterer ist meist der Einstieg, um ein neues Framework oder eine neue Library zu nutzen, was oft spannend ist, aber nicht immer sinnvoll. Hier sollte man wohlüberlegt handeln und sich nicht von coolen Buzzwords blenden lassen. Auch neue Techniken sollten grundlegend zu bestehenden Ansätzen und Konzepten passen und vom gesamten Team getragen werden.
Auf der andere Seite steht das Gegenteil, denn Never change a running system ist gerne die maskierte Aussage “das haben wir schon immer so gemacht, das ändern wir doch jetzt nicht mehr”. Vor allem als Entwickler der lange in einem Bereich mit bestimmten Techniken gearbeitet hat, sollte man trotzdem immer ein offenes Ohr für neue Ideen haben. Denn nur weil man Senior Developer o.ä. ist, heißt dies nicht das ein neuer Junior nicht vielleicht gute Ideen hat. Auch hier gilt abwägen ist wichtig, aber zuhören und offen sein sollte man immer.

Man lernt nicht aus. Ein Satz den man oft hört und der tatsächlich auch meistens der Wahrheit entspricht. An dieser Stelle möchte ich ein paar Punkte, die ich aus dem letzten Jahr mitgenommen habe, mit euch teilen. Diese betreffen mich dabei meist persönlich und könnten entsprechend nicht auf euch zutreffen, aber ich glaub das eine oder andere ist vielleicht auch allgemein ein häufigeres Problem.
Eine Sache ist für mich das Nein sagen, welches ich gerne zu oft und zu schnell tue. Vor allem wenn von extern Anfragen oder Ideen kommen, egal ob zu konkreten Implementierungen oder aber zu neuen Frameworks, bin ich schnell in einer Abwehrhaltung. Generell bin ich zwar weiterhin der Meinung, dass es besser ist erst Nein zu sagen und später doch noch eine Lösung für ein Problem zu finden, als andersherum, aber hin und wieder sollte man ein paar mehr Gedanken investieren, bevor man vorschnell antwortet. An dieser Schwäche meinerseits versuche ich in 2021 weiter zu arbeiten.