Ein häufiger Fehler Anfänger Software-Entwickler machen, und wie man es vermeidet

Foto von Fancycrave auf Unsplash

Ich war gerade einen Monat in meinem Job als Softwareentwickler, frisch vom College. Ich habe mich aufgewärmt, um zu meinem Team beizutragen. Irgendwie habe ich mich dabei erwischt, sehr interessante Gedanken zu haben, als ich die vorhandene Codebasis durchgesehen habe. Mein Team hatte diese Codebasis über Monate und Jahre hinweg aufgebaut.

Als meine erste Aufgabe hatte ich eine kleine Fehlerbehebung, die bei der Stabilisierung zukünftiger Versionen des Dienstes helfen würde. Mein Team erklärte mir die Architektur des Dienstes und wo passen wir in das große Schema des größeren Projekts. Ich musste herausfinden, wo der Code hinzugefügt / gelöscht oder geändert werden musste, um den Fehler zu beheben.

Ich fing an, die Codebasis zu durchsuchen, die größtenteils in den letzten zwei Jahren erstellt wurde. In keiner Weise handelte es sich um Legacy-Code. Als ich tiefer und tiefer hineinging, fand ich mich mit ziemlich profanen Gedanken wieder. Zu sagen, dass Code nicht ästhetisch ansprechend ist, wäre eine milde Formulierung. So habe ich auf die Codebasis meines Teams reagiert:

Das ist scheiße !!!

Yuck, hier gibt es zweihundert Zeilenfunktionen.

Wer hat diesen Mist geschrieben?

Oh Gott, es gibt einen If-else-Block innerhalb eines If-else-Blocks.

Dieser Code ist eine große haarige Sauerei! eff es.

Dies muss von Grund auf neu geschrieben werden.

Ich war wütend. Während ich diese Gedanken hatte, fragte sich ein Teil von mir, ob es einen Weg geben könnte, all dies zu verstehen. Gab es einige Dinge, von denen ich nicht wusste, dass diese älteren Leute in meinem Team den größten Teil dieses Codes geschrieben haben? Ich fing an es herauszufinden.

Ich griff nach dem älteren Mann in meinem Team, um mich kurz zu unterhalten, und warf ihm meine Fragen zu.

Das, was ich nach der Diskussion erfuhr, war für mich sehr aufschlussreich. Das Team war sich bewusst, dass der Code einige Wartungsprobleme hatte. Die vorhandene Codebasis hatte jedoch aus einigen Gründen die Form, die sie hat. Als er mir diese Gründe erklärte, konnte ich sehen, warum dieser Beitrag sinnvoll ist.

Lesen Sie weiter, um die Antwort zu finden, warum die Standardantwort lautet, wenn Sie einen Softwareentwickler nach der Qualität des Codes fragen, an dem er arbeitet: "Es ist ein Durcheinander". Und auch, warum es in den meisten Fällen keine Lösung ist, Dinge aus dem Boden aufzubauen.

Code wurde aus einem anderen Grund geschrieben

Die meisten Leute, die neu in der Softwareentwicklung sind, einschließlich mir, denken, dass Code für Maschinen geschrieben wurde. Falsch. Nada. Es wurde für Menschen geschrieben. Die Maschine sieht nicht einmal den JavaScript-Code, den Sie schreiben, sondern nur eine Folge von 0s und 1s. Und als der Service für mein Team aufgebaut wurde, gab es echte Fristen mit Liefergegenständen, die geliefert werden mussten. Softwareentwickler sind bereits psychisch stark belastet. Irgendwo unter dem Druck zu liefern, hat es Vorrang, den Code zum Laufen zu bringen, anstatt einen superästhetisch ansprechenden Code zu schreiben.

Ein großer Teil des Codes ist einfacher zu schreiben und einem anderen Entwickler persönlich zu erklären, als von einer Datei zur nächsten zu springen, um einen Sinn für die Dinge zu ergeben. Diese Entscheidungen können dann noch lange bestehen bleiben.

Der Produktionscode ist kampfgeprüft

Mein Team erhält viele Vorfallberichte, die manchmal zu kritischen Fehlerkorrekturen im Code führen. Ein Fehler bei der Behandlung der if-else-Klausel, ein Try-Catch, und plötzlich ist die gesamte Codebasis haarig geworden. Auf diese Weise wird die Codebasis trotz bester Absichten unordentlicher.

Genau aus diesem Grund ist das Umschreiben von Code von Grund auf eine so naive Idee. Dies würde dazu führen, dass alle Fehlerbehebungen und Verbesserungen, die vorgenommen wurden, weggeworfen werden. Diese wurden im Laufe von Monaten und Jahren angesammelt, möglicherweise von einem Benutzer, der ein echtes Problem hatte. Ein Entwickler hat möglicherweise mehrere Stunden damit verbracht, diese Fehler zu beheben, sobald sie gemeldet wurden.

Was funktioniert, ist der Weg

In der Geschäftswelt, in der es Kunden geben kann, die von Ihrem Produkt oder Ihrer Dienstleistung abhängen. Es interessiert niemanden, ob Ihr Code im bestmöglichen Umfang überarbeitet wird. Jede Codezeile wird geschrieben, um ein Geschäftsproblem zu lösen. Fragen Sie sich, welchen Wert Ihre Refactoring-Bemühungen schaffen werden? Möglicherweise keine, und sie könnten am Ende mehr Bugs verursachen. Plus, ist es die beste Verwendung Ihrer Zeit?

Das Gegenmittel

Der erste Schritt ist das Erkennen des Problems. Das Problem war, dass mein Ego dachte, es könnte bessere Arbeit leisten als diese Senior-Entwickler, die offensichtlich nicht wussten, wie man Code auf Produktionsebene schreibt. Dies ist eine sehr naive Denkweise, und ich bin in der Vergangenheit oft genug verbrannt worden, um dies jetzt zu vermeiden.

Indem Sie die Präsenz Ihres Ego anerkennen, verschaffen Sie sich einen enormen Vorteil. Plötzlich hat es keinen Platz mehr zum Verstecken. Das Problem anzuerkennen ist eine Sache, und es zu lösen ist eine andere. Unten ist meine Art, um diese Knie-Ruck-Reaktion zu umgehen. Wenn Sie einen anderen Weg haben, schreiben Sie es in den Kommentaren.

Neugierig werden

Beginnen Sie zu fragen, warum!

Warum wurde dieser Code so geschrieben? Wer schrieb es? Ist diese Person noch in der Nähe und kann ich sie darum bitten? Was wissen diese Leute, was ich nicht weiß? Welches Problem löst diese Funktion?

Meistens werden Sie von der Antwort überrascht sein.

Demut entwickeln

Dies ist keine schwierige Aufgabe. Höchstwahrscheinlich müssen Sie noch viel lernen, egal wo Sie sich auf die Leiter setzen.

Die Annahme einer Wachstumsmentalität ermöglichte es mir, mich in den richtigen Geisteszustand zu versetzen. Es hat mich befreit, Fragen zu stellen, ohne Angst zu haben, dumm auszusehen. Wenn Sie wissen, dass Sie nicht alle Antworten kennen sollen, sondern alle Antworten lernen, wird das Stellen von Fragen nur zu einer Kleinigkeit.

Fazit

Es ist sehr einfach zu glauben, dass Ihre Art, Code zu schreiben, die beste ist, und alle anderen sind zum Kotzen. Fragen Sie drei Personen, wie sie eine Zeichenfolge in eine Reihe von Zeichen aufteilen würden, und alle geben drei verschiedene Möglichkeiten an, dies zu tun. Wahrscheinlich sind alle gleich gut, und von allen kann man etwas lernen.

Es ist definitiv nicht die Lösung, den schlechten Qualitätscode wegzuwerfen. Der geschäftsfreundlichere Weg wäre, den Elefanten beißweise zu essen und sich durch den Code zu arbeiten.