Analyse typischer Fehler unerfahrener Programmierer: Teil 1

Hallo Welt! Nachdem Sie alles gelernt haben, was Sie brauchen, und endlich als Praktikant oder Junior eingestellt werden, können Sie sich wahrscheinlich entspannen, oder? Egal wie es ist! Alles fängt gerade erst an... Es gibt viele neue und unverständliche Dinge um dich herum, und wie kann man es nicht gleich zu Beginn so vermasseln? Darüber werden wir heute sprechen. In diesem Artikel möchte ich auf häufige Fehler von Anfängern eingehen und einige Tipps aus eigener Erfahrung geben, wie man diese vermeidet. Beginnen wir also ohne weitere Umschweife:

1. Angst davor, erfahrenere Kollegen um Hilfe zu bitten

Wir sind alle Menschen und haben alle Angst, dumm auszusehen, insbesondere in den Augen unserer frischgebackenen, erfahreneren Kollegen. Sobald sie ihren ersten Job bekommen, geben Entwickler dieser Angst oft nach, ziehen sich untröstlich in sich selbst zurück und versuchen, alles selbst herauszufinden. Gleichzeitig kann eine Person von erfahreneren Kollegen umgeben sein, die sie wiederum zunächst auf den richtigen Weg führen können, was dazu beiträgt, weitere Fehler und unnötige „Unebenheiten“ zu vermeiden. Denken Sie deshalb daran: Haben Sie keine Angst, Fragen zu stellen: Sie sind ein Anfänger und jeder versteht das perfekt. Wenn du fragst, wird dich niemand mit Stöcken schlagen. Vielleicht ist es sogar umgekehrt: Du freundest dich schneller mit deinen Kollegen an und beginnst, aktiver mit ihnen zu kommunizieren. Ich möchte noch mehr sagen: Je mehr Sie verschiedene technische Fragen stellen und diskutieren, desto schneller können Sie aus den Schuhen eines unerfahrenen Anfängers herauskommen und sich zu einem Experten auf Ihrem Gebiet entwickeln. Und noch ein Ratschlag. Vernachlässigen Sie StackOverFlow nicht . In diesem Zusammenhang meine ich das Stellen von Fragen zu dieser Ressource. Einerseits dauert es einige Zeit, bis Sie eine Antwort auf Ihre Frage erhalten. Andererseits lernen Sie vielleicht gleich mehrere Lösungsansätze für das aktuelle Problem kennen und betrachten es aus einer etwas anderen Perspektive. Ich möchte auch darauf hinweisen, dass das Schreiben von Kommentaren und Antworten sowie das Klären von Fragen zu StackOverFlow-Fragen anderer Entwickler neben einem Plus an Karma auch einen praktischen Vorteil haben: Sie haben die Möglichkeit, dieses Problem tiefer zu diskutieren und zu verstehen.

2. Versuchen Sie nicht, selbst nach Informationen zu suchen

Möglicherweise ist dieser Fehler die Kehrseite des vorherigen. Ich meine, wenn man anfängt, bei jedem Problem oder Problem an den Kollegen und Bekannten zu ziehen. Fragen ist gut, aber man sollte mit Fragen nicht zu weit gehen, sonst könnte es langweilig werden. Das erste, was Sie tun sollten, wenn ein unverständlicher Punkt auftaucht, ist, Ihre Suchfähigkeiten in der besten Suchmaschine anzuwenden – Google. Jemand ist bereits auf die überwiegende Mehrheit der unverständlichen Fehler und anderen Probleme gestoßen. Und Sie werden ziemlich überrascht sein, wenn Sie googeln und sehen, wie viele Menschen mit einem ähnlichen Problem vertraut sind und bereits umfassende Antworten erhalten haben, die sie für ihre Arbeit nutzen können. Auf dieser Grundlage hört man oft, wie ein Kollege die Frage „Google it“ beantwortet. Diese Antwort sollte Sie nicht beleidigen, denn schließlich ist Ihr Kollege kein persönlicher Lehrer, der Ihnen alle Feinheiten Ihres Arbeitsgebiets vermitteln soll. Die unendlichen Weiten des Internets helfen Ihnen bei einem solchen Mentoring. Manchmal wird ein Programmierer in der Google-Suche auch als Person mit schwarzem Gürtel bezeichnet . Wenn wir also nicht weiterkommen, googeln wir zuerst das Problem, und wenn keine Lösung gefunden wurde (selten, aber es kommt vor), fragen wir unsere Kollegen. Es lohnt sich, sie sofort zu fragen, nicht wenn eine Panne oder ein unverständlicher Fehler vorliegt, sondern wenn Sie einen Lösungsansatz für ein Problem wählen. Schließlich können sie über den eigenen Tellerrand hinausschauen und sofort erkennen, wie sich dieser oder jener Ansatz auf lange Sicht auswirken könnte.

3. Blindes Kopieren und Einfügen

Aber das Googeln des Problems und dementsprechend seiner Lösung hat seine Tücken. Zum Beispiel blindes Kopieren und Einfügen . Dies geschieht normalerweise, wenn Sie ein ähnliches Problem (aber möglicherweise nicht genau dasselbe) finden und darunter, beispielsweise auf StackOverFlow, eine Lösung findet. Sie nehmen diese Lösung, kopieren sie und fügen sie selbst ein, ohne zu sehr ins Detail zu gehen. Und dann entdecken Sie oder Ihre Projektkollegen seltsame Fehler oder fehlerhaftes Verhalten Ihrer Funktionalität. Und niemand hat sofort eine Ahnung, woher die Beine kommen. Dann wird natürlich ein Ort mit diesem Code gefunden, und Sie werden für diese Entscheidung definitiv nicht gelobt. Wenn Sie also auf StackOverFlow (oder anderswo) eine fertige Lösung finden, müssen Sie diese zunächst im Detail analysieren, was sie ist, wie und warum. Vielleicht googeln Sie diese Funktionalität und schauen Sie sich die Dokumentation dazu an. Und erst danach implementieren Sie es in Ihr Projekt.

4. Die falsche Lösung werfen

Beim Schreiben einer Lösung kommt es manchmal vor, dass diese immer komplexer wird und schließlich in eine Sackgasse gerät. Und Sie versuchen, es immer komplizierter zu machen, um dieses Problem mit diesem Ansatz irgendwie zu lösen, anstatt nach einer anderen, praktikableren Alternative zu suchen. Vielleicht tut es Ihnen einfach leid für die Energie und Zeit, die Sie aufgewendet haben, und so entscheiden Sie sich: Egal was passiert, geben Sie nicht auf, sondern lösen Sie das Problem auf diese Weise. Das ist nicht ganz der richtige Ansatz. Zumindest in der Programmierung. Je früher Sie einen anderen Ansatz ausprobieren, desto mehr Zeit sparen Sie. Scheuen Sie sich also nicht, zu experimentieren und andere Ansätze auszuprobieren, auch wenn Sie so viel Zeit in diesen Ansatz investiert haben. Darüber hinaus sind dies Punkte für Ihre Erfahrung, da Sie verschiedene Ansätze ausprobieren und diesen Bereich besser studieren werden.

5. Angst davor, Fragen zur aktuellen Aufgabe zu stellen

Bei der Arbeit an einem Projekt geht es in der Regel darum, einige Aufgaben (Aufgaben) zu erledigen. Zum Beispiel in Jira . Und diese Aufgaben werden nicht immer detailliert und klar beschrieben. Sie werden in der Regel von Teamleitern geschrieben, und das sind gegebenenfalls auch Menschen. Möglicherweise vergessen sie auch, etwas hinzuzufügen oder berücksichtigen nicht, dass Sie mit dieser oder jener Funktionalität nicht sehr vertraut sind. Nun, oder Sie haben keinen Zugriff auf das Projekt (z. B. Zugriff auf die Datenbank, auf den Protokollserver usw.). Und jetzt, nachdem Sie die Aufgabe erhalten und mehr als ein paar Stunden damit verbracht haben, sitzen Sie immer noch da und schauen verwirrt auf den Bildschirm. Und anstatt dies weiterhin vergeblich herauszufinden, sollten Sie damit beginnen, dem Ersteller dieser Aufgabe Leit-/Klärungsfragen zu stellen. Sagen wir, in einer Anwendung, die Sie zur Kommunikation im Team nutzen (zum Beispiel Microsoft Teams) oder direkt als Kommentar unter dieser Aufgabe. Wenn Sie einerseits eine Frage in einer persönlichen Nachricht schreiben, erfolgt die Antwort höchstwahrscheinlich schneller, da die Person die Frage sofort sieht. Andererseits haben Sie durch das Stellen einer Frage in Jira einen Beweis dafür, dass Sie etwas tun, nämlich das Problem analysieren. Es gibt eine Möglichkeit, diesen Prozess zu beschleunigen: Stellen Sie eine Frage als Kommentar in Jira und senden Sie einen Link zu diesem Kommentar in einer privaten Nachricht mit der Bitte, ihn anzusehen.

6. Zu viel vom Teamleiter erwarten

Auch dies ist die Kehrseite des vorherigen Punktes. Ein Teamleiter ist eine Person, die ein Entwicklungsteam leitet. In der Regel verbringt ein solches Teammitglied die meiste Zeit mit verschiedenen Arten der Kommunikation. Und gleichzeitig schreibt er auch Code, um nicht zu vergessen, worum es geht. Nun, wie Sie verstehen, ist dies ein sehr beschäftigter Charakter. Und übermäßiges Zucken bei jedem Niesen wird ihn offensichtlich nicht glücklich machen. Stellen Sie sich vor, jedes Teammitglied würde ihn mit einer Menge Fragen bombardieren. Man kann also verrückt werden, oder? Und es wird nicht überraschen, dass er Ihnen auf viele Fragen Ihrerseits lange antworten wird. Was können Sie tun, um die Anzahl der Fragen an den Teamleiter zu reduzieren:

• Studieren Sie die Dokumentation dieses Projekts genauer, um die Anzahl blinder Flecken zu reduzieren.
• Stellen Sie Fragen an andere Teammitglieder. Es ist durchaus möglich, dass sie mit dieser Funktionalität genauso vertraut sind wie der Hauptdarsteller, oder sogar noch besser, da höchstwahrscheinlich einer von ihnen diese Funktionalität geschrieben hat.

Alternativ können Sie sich in der IDE Anmerkungen ansehen: Wer und wann hat den Code in einer bestimmten Zeile zuletzt geändert? Auf diese Weise werden wir herausfinden, wer diese Frage am besten stellen würde. Wie Sie wahrscheinlich bereits verstanden haben, müssen Sie beim Stellen von Fragen an den Teamleiter sowie beim Stellen von Fragen an Kollegen versuchen, die goldene Mitte beizubehalten – keine Angst davor zu haben, Fragen zu stellen, sie aber auch nicht mit einer übermäßigen Anzahl zu belästigen.

7. Angst vor Codeüberprüfungen

Codeüberprüfung oder Codeüberprüfung ist eine Phase vor dem Hochladen von Code in eine gemeinsame Anwendung (in einen gemeinsamen Zweig, z. B. Master oder Dev). Diese Prüfung wird von einem Entwickler durchgeführt, der mit dieser Aufgabe nichts zu tun hat und der mit neuem Blick Fehler, Ungenauigkeiten oder Mängel im Codestil entdecken kann, die in der Anfangsphase der Entwicklung unbemerkt geblieben sind. Wenn Kommentare vorhanden sind, werden diese als Kommentare zu bestimmten Abschnitten des Codes hinterlassen. In diesem Fall muss der Entwickler, der diese Aufgabe durchgeführt hat, die Fehler gemäß der Überprüfung korrigieren (oder seine Entscheidungen mit dem Prüfer besprechen und ihn möglicherweise von der Richtigkeit seiner Entscheidung überzeugen). Anschließend senden Sie es zur Überprüfung zurück usw., bis der Prüfer keine Kommentare mehr hat. Der Prüfer dient vor dem Hochladen des Codes als „Filter“. Daher empfinden viele unerfahrene Programmierer die Codeüberprüfung als Kritik und Verurteilung. Sie schätzen sie nicht und haben Angst vor ihr, und das ist falsch. Es ist die Codeüberprüfung, die es uns ermöglicht, unseren Code zu verbessern. Schließlich erhalten wir wichtige Informationen darüber, was wir falsch machen und worauf wir achten sollten. Es ist notwendig, jede Codeüberprüfung als Teil des Lernens zu betrachten, der Ihnen bei der Verbesserung helfen kann. Wenn jemand Kommentare zu Ihrem Code hinterlässt, teilt er Ihnen seine Erfahrungen und Best Practices mit. Was mich betrifft, kann man ohne eine Codeüberprüfung kein guter Programmierer werden. Denn aus der Sicht eines erfahrenen Außenstehenden wissen Sie nicht, wie gut Ihr Code ist und ob dort Fehler vorliegen.

8. Tendenz zu abstrusen Lösungen

Oftmals können unterschiedliche Aufgaben/Probleme mehrere unterschiedliche Lösungen haben. Und von allen verfügbaren Lösungen nutzen Anfänger meist die komplexesten und „abstrusesten“. Und es stimmt: Wenn ein unerfahrener Programmierer erst gestern viele verschiedene Algorithmen, Muster und Datenstrukturen studiert hat, dann juckt es ihn in den Händen, einen davon zu implementieren. Ja, und ich möchte mich sozusagen erklären. Glauben Sie mir, ich war selbst so und weiß, wovon ich rede :) Ich hatte eine Situation, in der ich lange Zeit damit verbracht habe, eine Funktionalität zu schreiben, die sich als sehr, sehr komplex herausstellte. Dann wurde es von einem Senior+-Entwickler neu geschrieben. Natürlich war ich gespannt, was und wie er es verändert hat. Ich habe mir seine Umsetzung angeschaut und war erstaunt, wie viel einfacher es geworden ist. Und der Code ist dreimal weniger geworden. Und gleichzeitig haben sich die Tests für diese Funktionalität nicht verändert und sind nicht fehlgeschlagen! Das heißt, die allgemeine Logik bleibt dieselbe. Daraus kam ich zu dem Schluss: Die genialsten Lösungen sind immer einfach . Nach dieser Erkenntnis wurde das Schreiben von Code viel einfacher und deutlich anspruchsvoller. Wann lohnt es sich also, Muster und Algorithmen zu nutzen? Dann ist ihre Verwendung die einfachste und kompakteste Möglichkeit.

9. Die Erfindung des Fahrrads

Dieses Konzept wird auch als Erfindung des Rades bezeichnet. Sein Kern liegt darin, dass der Entwickler seine eigene Lösung für ein Problem implementiert, für das es bereits Lösungen gibt, und zwar um ein Vielfaches besser als die vom Programmierer erfundenen. In der Regel führt die Erfindung eines eigenen Fahrrads zu Zeitverlust und einer Verringerung der Effizienz der Entwicklerarbeit, da möglicherweise keine oder gar keine Lösung gefunden wird, die bei weitem nicht die beste ist. Gleichzeitig können wir die Möglichkeit einer unabhängigen Entscheidung nicht ausschließen. Der Programmierer muss die vor ihm auftretenden Aufgaben richtig steuern, um sie kompetent und zeitnah zu lösen, indem er vorgefertigte Lösungen verwendet oder eigene Lösungen erfindet. Einerseits werden wir an Universitäten und in Kursen mit Aufgaben aller Art bombardiert, die uns dabei helfen sollen, die Herstellung von Fahrrädern in die Hand zu nehmen. Aber das ist nur auf den ersten Blick. Tatsächlich besteht der Zweck darin, algorithmisches Denken und eine tiefere Beherrschung der Syntax der Sprache zu entwickeln. Und solche Aufgaben tragen auch dazu bei, Algorithmen/Strukturen besser zu verstehen und ihnen bei Bedarf die Fähigkeit zu verleihen, ihre fortgeschrittenen Analoga zu implementieren (dies ist jedoch sehr selten erforderlich). Im wirklichen Leben besteht in den allermeisten Fällen keine Notwendigkeit, das eigene Rad zu erfinden, da es längst Analoga gibt, die unsere Bedürfnisse befriedigen. Möglicherweise wissen Sie aufgrund Ihrer Erfahrung nicht, dass es Implementierungen dieser oder jener Funktionalität gibt, die Sie benötigen. Hier müssen Sie den ersten Punkt dieses Artikels nutzen, nämlich erfahrenere Kollegen um Hilfe zu bitten. Sie können Sie weiterleiten (z. B. mitteilen, in welche Richtung Google gehen soll) oder eine konkrete Implementierung vorschlagen (bestimmte Bibliothek).

10. Schreiben Sie keine Tests

Nicht alle Anfänger mögen es, Tests zu schreiben. Was ist mit Neulingen: Auch Nicht-Neulinge schreiben nicht gerne Tests, aber sie verstehen besser, warum es nötig ist. Wenn du völlig grün bist, denkst du: Warum schreibst du sie? Es funktioniert alles und es können keine Fehler auftreten. Aber wie können Sie sicher sein, dass Ihre Änderungen nicht etwas in einem anderen Teil des Systems beschädigen? Ihre Kollegen werden es nicht zu schätzen wissen, wenn Sie Veränderungen durchsetzen, die sie mehr stören als nützen. Hier helfen Tests. Je besser eine Anwendung durch Tests abgedeckt ist, desto besser (auch Abdeckungsprozentsatz genannt). Wenn die Anwendung gut durch Tests abgedeckt ist, können Sie beim Ausführen aller Tests Stellen finden, die durch Ihre Änderungen beschädigt werden können. Und wie ich im obigen Beispiel sagte, sind die Tests bei der Umgestaltung der Funktionalität nicht fehlgeschlagen, und das alles, weil sich die allgemeine Logik nicht geändert hat. Das bedeutet, dass Tests auch zeigen können, ob sich die Logik einer bestimmten Funktionalität geändert hat oder nicht. Auch wenn Sie nicht gerne Tests schreiben, haben sie zweifellos Vorteile und sind die dafür aufgewendete Zeit wert.

11. Übermäßiges Kommentieren

Viele Entwickler leiden unter Perfektionismus, und Anfänger bilden da keine Ausnahme. Aber manchmal ist ein Nebeneffekt dieses Wunsches, dass sie anfangen, alles und jeden zu kommentieren. Sogar das, was nicht nötig ist, weil es so offensichtlich ist:

Cat cat = new Cat(); // cat Object

Nicht alle unerfahrenen Programmierer erkennen sofort, dass das Kommentieren von Code nicht immer eine gute Sache ist, da der Code dann viel unübersichtlicher und schwerer lesbar wird. Was passiert, wenn der Code geändert wurde, es aber keinen Kommentar dazu gab? Es stellt sich heraus, dass er uns täuschen und nur verwirren wird. Warum dann so ein Kommentar? Normalerweise muss gut geschriebener Code nicht kommentiert werden , da alles darin bereits offensichtlich und lesbar ist. Wenn Sie einen Kommentar schreiben, bedeutet dies, dass Sie die Lesbarkeit des Codes bereits beeinträchtigt haben und versuchen, die Situation irgendwie zu glätten. Der beste Ansatz wäre, zunächst lesbaren Code zu schreiben, der nicht mit Kommentaren ergänzt werden muss. Ich konnte auch nicht umhin, die korrekte Benennung von Methoden, Variablen und Klassen zu erwähnen, nämlich eine Regel, an die ich mich selbst halte: Der beste Kommentar ist das Fehlen eines Kommentars, und stattdessen – die richtige Benennung , die dieses oder jenes klar beschreibt Funktionalität in Ihrer Anwendung.

12. Schlechte Namensgebung

Anfänger fälschen häufig die Namen von Klassen, Variablen, Methoden usw., wenn sie beispielsweise eine Klasse erstellen, deren Name ihren Zweck überhaupt nicht beschreibt. Oder es wird eine Variable mit einem Kurznamen erstellt, etwa x , und wenn zwei weitere Variablen mit den Namen n und y erstellt werden , wird es sehr schwierig, sich daran zu erinnern, was x tut . In solchen Fällen muss man sich den Code genau überlegen und diese Funktionalität unter der Lupe studieren (vielleicht mit einem Debugger), um einfach zu verstehen, was dort passiert. Hier hilft uns die oben erwähnte korrekte Benennung im Code. Richtige Namen verbessern die Lesbarkeit des Codes und sparen dementsprechend Zeit bei der Einarbeitung, da es viel einfacher ist, eine Methode zu verwenden, bei der der Name seine Funktionalität annähernd beschreibt. Im Code besteht alles aus Namen (Variablen, Methoden, Klassen, Dateiobjekte usw.). Dieser Punkt wird sehr wichtig, wenn es darum geht, korrekten, sauberen Code zu erstellen. Denken Sie daran, dass der Name die Bedeutung vermitteln sollte: warum beispielsweise die Variable existiert, was sie tut und wie sie verwendet wird. Und ich werde immer wieder feststellen, dass der beste Kommentar zur Beschreibung einer Variablen ihr korrekter Name ist. Für eine tiefergehende Auseinandersetzung mit Kommentaren und korrekter Benennung empfehle ich Ihnen die Lektüre des zeitlosen Klassikers: „Clean Code. Kreation, Analyse und Refactoring“, Robert Martin . In diesem Sinne ist der erste Teil dieses Artikels (Reflexionen) zu Ende. Fortsetzung folgt…