Boehrsi.de - Blog

Software kann in sehr unterschiedlichen qualitativen Zuständen sein. Manchmal startet man bei Null und kann alles frisch und gut entwickeln, mal übernimmt man eine betagte Legacy Software und manchmal findet man eine gut dokumentierte und gepflegte Software zum weiterentwickeln vor.
Sowohl in privaten, wie auch in professionellen oder Open Source Projekten findet man diese verschiedenen Typen und diverse Abstufungen von selbigen, zum guten und zum schlechten. Ich war bis dato meist an frischen Projekten beteiligt, wo ich die Architektur mit definierte und die Konzepte tiefgehend Verstand. Bereits laufende Projekte betreute ich ebenfalls, meist aber nicht extrem tiefgehend oder aber die Projekte waren durchaus gut strukturiert und verständlich.
Mit diesen Ansätzen und den entsprechenden Aufgaben konnte ich gut umgehen, doch aktuell stehe vor einer neuen Herausforderung, die meiner Meinung nach eine Erwähnung wert ist. Denn als Entwickler wird man über selbige früher oder später stolpern und man sollte auch mit dieser umgehen können.
Es geht um Software die gewachsen ist, über lange Zeit und vielleicht nicht die Liebe und Zuneigung erfahren hat die sie sollte. Software die einen manchmal mit der Stirn runzeln lässt und manchmal möchte man das Keyboard liebevoll in viele kleine Teile zerschmettern.

In solchen Projekten muss man zwar ebenfalls Features implementieren, Bugs fixen und vielleicht auch an der Architektur arbeiten, aber das “Wie” ist ein anderes. Ich habe für mich gelernt den Fokus extrem auf die aktuelle gekapselte Aufgabe zu lenken und keine Nebenaufgaben zu erfüllen. Ebenfalls versuche ich mich nicht zu tief in Seitenbereiche meiner Aufgabe zu verstricken. Beides fällt mir durchaus schwer, denn wenn ich Probleme oder Fehler sehe, möchte ich selbige angehen. Doch in solchen Projekten artet dies gerne komplett aus und wenn man nicht selber den Überblick über die eigenen Changes verliert, der Reviewer wird auf jeden Fall gar nichts mehr verstehen.
Es ist also wichtig ignorieren zu können, den Fokus zu setzen und auf dem Weg zur Beendigung der eigenen Aufgabe viele Notizen oder direkt Tickets zu erstellen. Denn auch wenn man vielleicht nicht alles direkt angehen kann, die Dinge sollten nicht unter den Tisch fallen. Ich selber tue mich mit dem Ganzen tatsächlich etwas schwerer als eine Architektur aus dem Nichts aufzubauen. Denn ich muss zum Teil gegen meine Gewohnheit Dinge On-The-Fly zu optimieren arbeiten. Doch diese Überwindung ist wichtig, da man ansonsten eher gegen, als für das Projekt arbeitet. Außerdem versteht man vielleicht auch gar nicht alles korrekt und spontane Änderungen würde mehr schaden als sie nutzen. Entsprechend gilt hier eher Ruhe walten zu lassen und fokussiert Ticket nach Ticket zu erledigen, bis langsam ein Licht am Ende des Tunnels zu sehen ist. Bei selbigem muss man dann nur noch hoffen das es nicht der Regression LKW ist, der einem aufgrund von etwaiger Chaos-Architektur direkt ins Gesicht fährt.
Wie sieht es bei euch aus, an was für Projekten habt ihr bis dato so gearbeitet und wie sind eure Erfahrungen zum Thema Code-Qualität.