Code und die Kunst der Motorradwartung: Typische Anfängerfehler

Programmieren ist einfach, heißt es, es ist wie Fahrradfahren. Nun, Programmieren ist eigentlich ein Motorrad, ein sehr leistungsstarkes und schnelles. Beim Programmieren muss man, genau wie beim Motorradfahren, verantwortungsbewusst und aufmerksam sein, um im Sattel zu bleiben und das zu verdoppeln, um ein Gewinner zu sein. Tatsächlich machen Motorradfahrer und Programmierer dieselben Anfängerfehler: Neulinge konzentrieren sich oft auf schnelle, leistungsstarke Tools und innovative Tricks und glauben, dass dies allein einen wahren Meister ausmacht. Diese Denkweise ist teilweise auf den „Dunning-Kruger-Effekt“ zurückzuführen, bei dem Neulinge die Komplexität und Bedeutung ihres Berufs nicht begreifen. Glücklicherweise erkennt selbst der eifrigste Anfänger mit der Erfahrung, dass die Kunst des Programmierens viel mehr umfasst als nur die Auswahl des optimalen Algorithmus. In diesem Artikel möchte ich meine Gedanken darüber teilen, was für einen Programmierer wirklich wichtig ist und was sowohl neue als auch erfahrene Entwickler beim Erstellen von Software und Schreiben von Code beachten sollten.

Lesbarkeit vor Leistung, aber nicht immer

Womit beginnen typische Motorradanfänger? Mit Zahlen und Gadgets. Leistung, Drehmoment, Performance-Teile, um auf einer Viertelmeile theoretisch Millisekunden herauszuholen … als würden sie gleich in die Startaufstellung der MotoGP einsteigen. Dabei besteht ihre Hauptaufgabe darin, zu lernen, wie man sicher fährt. In ähnlicher Weise fixieren sich Anfänger oft auf die Code-Leistung, wo dies unnötig ist. Artikel, in denen diskutiert wird, ob `dict()` oder `{}` in Python effizienter ist, oder die Vor- und Nachteile der Verwendung von Frameworks trotz ihres Potenzials, die Leistung zu verringern, schüren diese Besessenheit. Während das Verständnis der Feinheiten Ihrer Programmiersprache nützlich und manchmal entscheidend ist – wie etwa bei Software für Flugzeuge, Aktienhandelsroboter oder medizinische Geräte – ist es für die Mehrheit der Programme, die wir täglich erstellen, nicht immer entscheidend. Selbst wenn Sie an leistungskritischer Software arbeiten, ist es wichtig zu wissen, welche Teile des Codes eine hohe Leistung erfordern und welche nicht.

Was jedoch immer zählt, ist die Lesbarkeit des Codes. Zahlreiche Studien und Umfragen bestätigen, dass Entwickler mehr Zeit damit verbringen, Code zu lesen und zu verstehen, als ihn zu schreiben. So zeigt die Studie „Ich weiß, was Du letzten Sommer getan hast – Eine Untersuchung darüber, wie Entwickler ihre Zeit verbringen“ stellte fest, dass nur 4 % der in einer IDE verbrachten Zeit für die Bearbeitung von Code verwendet wird. Globaler Code-Zeitbericht , basierend auf einer Umfrage unter über 250.000 Entwicklern, ergab, dass die Befragten nur etwa 52 Minuten pro Tag aktiv mit dem Schreiben von Code verbringen. Die restliche Zeit wird mit der Diskussion und Planung des Projekts verbracht, wobei etwa 41 Minuten dem Lesen von Code in der IDE und der Projektdokumentation gewidmet sind.

In den meisten Fällen ist es unser Ziel, ein wartbares Produkt zu schaffen, das keinen komplexen Support erfordert und in einem Wettbewerbsumfeld erfolgreich ist. Das bedeutet nicht, dass wir die Leistung völlig ignorieren können; wir müssen ein Gleichgewicht finden, bei dem Wartbarkeit und Leistung koexistieren. Wenn hochleistungsfähiger Code benötigt wird, können wir langsame Abschnitte nach dem Start des Projekts optimieren.

Bedenken Sie auch, dass sich Compiler und Interpreter weiterentwickeln, Ihr Code jedoch derselbe bleibt. Ein super-hyperoptimierter magischer Codeschnipsel, der für eine Compilerversion geschrieben wurde, kann für eine andere zu einem irrelevanten Reinfall werden. Außerdem müssen zukünftige Entwickler – oder sogar Sie – mit diesem Code arbeiten. Wann sollten wir also die Lesbarkeit zugunsten der Leistung opfern?

Um zu erkennen, wann die Leistung Vorrang vor der Lesbarkeit haben sollte, müssen Sie Engpässe in Ihrer Anwendung lokalisieren:

• Profilerstellung der Anwendung : Wenn die Profilerstellung ergibt, dass bestimmte kritische Codeabschnitte die Leistung erheblich beeinträchtigen, kann die Optimierung dieser Fragmente eine verringerte Lesbarkeit rechtfertigen.

• Belastungstests : Durch die Simulation hoher Belastungen können Leistungsengpässe identifiziert werden, bevor sie zu tatsächlichen Problemen werden.

• Analyse des Benutzerfeedbacks : Durch das Sammeln von Benutzerfeedback können Bereiche mit schlechter Leistung aufgezeigt werden.

• Protokollierung und Überwachung : Durch die Analyse von Ausführungsprotokollen und Metriken können problematische Bereiche während des tatsächlichen Betriebs der Anwendung identifiziert werden. In dieser Phase können unerwartete Probleme aufgedeckt werden, z. B. eine unsachgemäße API-Nutzung, die Leistungsprobleme verursacht.

• Tools zur statischen Codeanalyse : Einige Tools können bei Codeüberprüfungen Leistungsverbesserungen vorschlagen. Es empfiehlt sich, diese Tools bei Aufgabenüberprüfungen automatisch auszuführen.

  
  

Diese Tipps können Ihnen dabei helfen, die Schwachstellen Ihrer Anwendung zu identifizieren, sodass Sie sich auf die notwendigen Optimierungen konzentrieren können. Meiner persönlichen Erfahrung nach betreffen diese Optimierungen weniger exotische Sprachkonstrukte als vielmehr die Optimierung von Datenbankinteraktionen oder die Verwendung externer APIs.

Dokumentation hilft, die geleistete Arbeit zu verstehen

Eine der entscheidenden Sicherheitsfähigkeiten auf der Straße ist es, vorhersehbar zu sein und die Absichten anderer zu erkennen. Beim Programmieren kann man, genau wie beim Radfahren, die Gedanken anderer nicht direkt lesen. Auf zwei Rädern muss man subtile Bewegungen bemerken und vorhersagen, was andere in der nächsten Sekunde tun werden. Programmierer verfügen über ein mächtiges Werkzeug (das sie jedoch nicht immer einsetzen), um Telepathie zu ersetzen: Papierkram. Die meisten Entwickler sind sich einig, dass Dokumentation für ein Projekt entscheidend ist, wie Umfragen wie die folgende belegen: Stack Overflow-Entwicklerumfrage 2023 , wo 90,36 % der Befragten regelmäßig technische Dokumentationen verwenden. Allerdings finden sie dort oft nicht alle Antworten und wenden sich stattdessen an Stack Overflow (82,56 %) und verschiedene Blogs (76,69 %). Eine weitere Studie, Microsoft Research: Der Alltag von Softwareentwicklern zeigt, dass Entwickler 1–2 % ihres Tages mit Dokumentation verbringen, wobei 10,3 % der Befragten viel Zeit aufgrund schlechter oder veralteter Unterlagen verlieren.

Dokumentation kann viele Formen annehmen, von detaillierten Projektbeschreibungen in Systemen wie Confluence bis hin zu Codekommentaren und automatisch oder halbautomatisch generierten Projektbeschreibungswebsites. Sie kann sogar so einfach sein wie eine README-Datei im Stammverzeichnis des Projekts. Unabhängig vom Format geht der Prozess der Dokumentationserstellung weit über die bloße Übermittlung von Informationen zur Funktionsweise des Produkts hinaus. Dieser Prozess lässt uns überdenken, was wir getan haben , was oft zu Verbesserungen der API und der Gesamtarchitektur führen kann. Beim Dokumentieren der von mir erstellten Funktionen habe ich oft festgestellt, dass die Arbeit damit schwierig sein könnte, und ich habe Wege gefunden, das zu beheben.

Es ist wichtig, sich daran zu erinnern, dass die Pflege der Dokumentation immer einen erheblichen Aufwand erfordert, insbesondere wenn sich das Projekt in einer Phase befindet, in der es häufig geändert wird. In solchen Fällen sollten Sie alle Risiken abwägen und sorgfältig überlegen, welche Logik dokumentiert werden soll. Wenn Ihr Projekt einen ausgereiften Zustand erreicht hat, bringt eine gute Dokumentation mehr Vorteile als Herausforderungen: Neue Entwickler können schneller eingearbeitet und in Schwung kommen, während langjährige Mitarbeiter schnell herausfinden können, wie bestimmte Funktionen funktionieren. Darüber hinaus kann eine Dokumentation mit einer guten Suchfunktion in einem großen Projekt mit vielen Teams die Duplizierung von Funktionen verhindern.

Es ist keine Schande, anderen zu erzählen, was man vorhat

Die Verwendung von Blinkern ist die einfachste Form eines berechenbaren Fahrers. Ebenso ist das Kommentieren von Code wahrscheinlich die einfachste und direkteste Möglichkeit, anderen mitzuteilen, was Sie tun. Und genau wie das Verwenden von Blinkern macht es Sie nicht weniger cool. Ich weiß, es gibt eine allgemeine Meinung, dass Kommentare unnötig sind, weil der Code selbsterklärend sein sollte. Aber nein, dem stimme ich nicht ganz zu. Qualitativ hochwertiger Code kann dank guter Variablen- und Funktionsbenennung, klarer Struktur und Einhaltung der Prinzipien des sauberen Codes oft intuitiv verstanden werden. Aber selbst in solchen Fällen können gut durchdachte Kommentare wertvolle Informationen liefern.

Kommentare spielen eine entscheidende Rolle bei komplexen Algorithmen oder Lösungen, die zusätzlichen Kontext erfordern, um sie zu verstehen. Sie können das „Warum“ hinter einem Ansatz erklären, das aus dem Code selbst nicht immer ersichtlich ist. Dies ist insbesondere dann wichtig, wenn der Code auf Leistung optimiert ist, seine Absichten und Logik jedoch nicht sofort klar sind. Kommentare können auch dabei helfen, zu überdenken, ob der gewählte Algorithmus in die richtige Richtung geht.

Kommentare sind Lebensretter bei komplexer Geschäftslogik oder projektspezifischen Anforderungen, die für neue Teammitglieder oder bei langfristiger Projektunterstützung möglicherweise nicht offensichtlich sind. Sie helfen dabei, Wissen im Team zu behalten und erleichtern die Übertragung von Projekten zwischen Entwicklern.

Natürlich ist es wichtig, übermäßige Kommentare zu vermeiden, wenn diese das Offensichtliche aussagen oder veraltet und irreführend werden. Ihr Zweck besteht darin, Klarheit zu gewährleisten und das Verständnis des Codes zu unterstützen, und nicht darin, ihn mit unnötigen Informationen zu überladen.

Testen: Ein Tool zum Code-Verständnis und zur Code-Verifizierung

Ok, stellen Sie sich nun vor, wir haben endlich das Radfahren gelernt und wollen nun unser Glück auf einer echten Rennstrecke versuchen. Nun, wir werden bald feststellen, dass es beim echten Rennen nicht nur darum geht, „Vollgas“ zu geben. Es geht um Training, Tests und Feinabstimmung Ihrer Maschine, um sie Ihren Gewohnheiten und Rennbedingungen anzupassen. Dasselbe gilt für Code: Er sollte gründlich ausprobiert, getestet und bei Bedarf korrigiert werden, bevor er für eine echte Spritztour freigegeben werden kann. Daher ist es entscheidend, Codetests mit maximaler Verantwortung anzugehen. Tests werden oft nur als Tool zum Auffinden von Fehlern angesehen, aber ihre Rolle ist umfassender:

• Fehler- und Defekterkennung : Durch Tests werden Fehler und unvorhergesehenes Verhalten identifiziert, bevor das Produkt den Benutzer erreicht. Dies verbessert die Qualität und reduziert Benutzerprobleme.
• Code-Verständnis : Das Erstellen von Testszenarien erfordert ein tiefes Verständnis der Struktur und Funktionalität des Codes und fördert ein besseres Verständnis der Logik und Interaktion des Programms.
• Ergänzung zur Dokumentation : Tests können als Anwendungsbeispiele für Funktionen und Methoden dienen, beim Auffinden von Informationen zur Funktionalität des Projekts helfen und neue Spezialisten durch die Bereitstellung realer Anwendungsfälle unterstützen.

Effektives Testen ist für die Erstellung von qualitativ hochwertigem, zuverlässigem und verständlichem Code unerlässlich. Allerdings kann das Testen, genau wie die Dokumentation, ressourcenintensiv sein, insbesondere in den frühen Phasen des Projekts. Es ist wichtig, die Notwendigkeit des Testens mit Zeit- und Ressourcenbeschränkungen abzuwägen.

Es ist auch offensichtlich, dass eine absolute Testabdeckung für komplexen Code einfach nicht erreichbar ist. Daher müssen Entwickler das Testen von Schlüsselfunktionen und kritischen Codeabschnitten priorisieren und wissen, wann sie aufhören müssen, um einen endlosen Testzyklus zu vermeiden.

Liebe deinen Code wie deinen Freund und kümmere dich darum

Und schließlich kann kein Motorrad ohne ordnungsgemäße Wartung zuverlässig sein. Es gibt ziemlich viele Leute, die diesen Aspekt des Fahrens vernachlässigen, aber sie schreiben Geschichten (von lustig über gruselig bis traurig), an denen wir auf keinen Fall teilhaben wollen. In der Programmierwelt ist die Codewartung, genau wie beim Motorradfahren, nicht nur eine Empfehlung, sondern eine Notwendigkeit, insbesondere bei langfristigen Projekten. Mangelnde Wartung und Updates führen zu Produktveralterung und Sicherheitslücken.

Wenn Code nicht aktualisiert wird, um mit den neuesten Compilern und Interpretern kompatibel zu sein, kann (und wird) die Aktualisierung zunehmend schwieriger werden. Wenn Sie eine Desktop- oder Mobilanwendung entwickeln, funktioniert Ihr Produkt möglicherweise nicht mehr mit neuen Betriebssystemversionen. Eine Website funktioniert möglicherweise nicht mehr, weil Tools und Technologien veraltet sind. Das einfachste Problem könnte ein abgelaufenes Sicherheitszertifikat oder eine veraltete Software für dessen Erneuerung sein.

Regelmäßige Updates und Refactorings sind auch wichtig, um die Lesbarkeit des Codes aufrechtzuerhalten. Dadurch bleibt das Projekt überschaubar und zukünftige Änderungen und Funktionserweiterungen werden vereinfacht.

Kurz gesagt: Lieben Sie Ihren Code und widmen Sie ihm Zeit – aber nicht zu viel, sonst enden Sie wie der Protagonist des „Null-Theorems“. Viel Glück!