3 Dinge, die Senior Developer auszeichnen

27.06.2024
Von 


Nick Hodges ist Developer Advocate beim Authentifizierungsspezialisten Passage und hat in den letzten Jahren zahlreiche praktische Erfahrungen als Delphi-, TypeScript- und Angular-Entwickler gesammelt. Er schreibt für unsere US-Schwesterpublikation Infoworld.
Lesen Sie, was Junior Developer können sollten, die zum Senior aufsteigen wollen.
Junior Developer mit Karriereambitionen sollten auf diese vier Hard Skills hinarbeiten.
Junior Developer mit Karriereambitionen sollten auf diese vier Hard Skills hinarbeiten.
Foto: DC Studio | shutterstock.com

Diverse Onlinebeiträge geben darüber Auskunft, welche Voraussetzungen für eine Rolle als Senior Developer erfüllt sein müssen. Dabei drehen sich die meisten allerdings um das Thema Soft Skills.

Die sind ohne Frage ebenfalls wichtig - der wesentliche Unterschied zwischen Junior- und Senior-Entwicklern liegt allerdings in der Berufserfahrung - und den in diesem Rahmen gelernten Lektionen. Vor diesem Hintergrund haben wir drei Hard Skills identifiziert, die für Senior-Entwickler - und damit auch für Junior Developer mit Aufstiegsambitionen - zum A und O gehören (sollten).

1. Klaren Code schreiben

Es mag sich ziemlich offensichtlich lesen, aber lesbaren Code schreiben zu können, gehört zu den wichtigsten Skills von erfahrenen Entwicklern - oder sollte es zumindest. Leider existiert und entsteht jedoch immer noch jede Menge Code, bei dem dieser Grundsatz mit Füßen getreten und kein Gedanke daran verschwendet wird, dass irgendein armer Tropf das Ganze am Ende auch lesen (können) muss.

Und klarer Code ist nicht nur mit Blick auf die Lesbarkeit zu empfehlen, sondern auch wenn es um Debugging geht. Dieser Prozess beschreibt im Wesentlichen, den Zustand einer laufenden Applikation zu einem definierten Zeitpunkt zu verstehen. Sind Funktionen, Klassen und so weiter klar deklariert (während der Code läuft), tut sich der Debugger leichter - und der Code wird gleichzeitig besser lesbar.

Davon abgesehen, gewinnt Programmcode auch an Klarheit, wenn er keine Kommentare enthält, beziehungsweise benötigt. Ein Entwickler, der das Bedürfnis verspürt, seinen Code zu kommentieren, sollte diesen stattdessen lieber umschreiben. Oder ihn idealerweise direkt so erstellen, dass Kommentare überflüssig sind. Dieser Punkt ist allerdings umstritten - es gibt auch Organisationen, die explizit Wert darauf legen, dass jede ihrer Codezeilen einen Kommentar enthält.

2. Komplexität vermeiden

Komplexität zu vermeiden, ist entscheidend für guten Code - und lässt sich auch ganz einfach bewerkstelligen: Hören Sie einfach auf damit, mehrere Fliegen mit einer Klappe schlagen zu wollen. Wenn jede Entität in Ihrer Codebasis nur eine einzige Aufgabe erfüllt, ist sie im Fall von Problemen auch einfacher zu warten, beziehungsweise zu fixen.

Deswegen sollte nichts - weder Klassen, noch Methoden oder Funktionen - jemals mehr als einen Task erfüllen. Dabei ist es wichtig zu verstehen, dass sich nicht komplexer Code und komplexe Systeme nicht ausschließen. Stellen Sie sich die Softwareentwicklungsarbeit einfach wie eine hochwertige mechanische Uhr vor: Das Gesamtwerk ist ein hochkomplexes Gerät, das aus relativ simplen Komponenten - im Wesentlichen Zahnräder und Federn - besteht. Diese Komponenten arbeiten zusammen und erzeugen somit die Komplexität.

3. Nichts überstürzen

"In der Ruhe liegt die Kraft" ist ein Sprichwort, das viele weniger erfahrene Developer im ersten Moment möglicherweise als kontraintuitiv empfinden. Allerdings macht dieses Mantra durchaus auch im Dev-Umfeld Sinn, wie erfahrene Softwareentwickler wissen.

Schließlich sorgt Zeitdruck in aller Regel für erhöhte Fehlerquoten. Diese Bugs anschließend zu beheben, kostet wiederum enorm viel Zeit. Ein gewissenhaftes, langsameres Vorgehen kann hingegen Fehler reduzieren und am Ende dafür sorgen, dass der Gesamtprozess deutlich schneller abläuft. Code, der von Anfang an gewissenhaft und vorausschauend aufgesetzt wird, bringt also nicht nur bessere Ergebnisse, sondern ist auch einfacher zu pflegen. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.