Warum es nützlich ist, Räder neu zu erfinden

Kürzlich habe ich ein Vorstellungsgespräch mit einem JavaScript-Entwickler geführt, der sich für eine Senior-Position beworben hat. Ein Kollege, der ebenfalls anwesend war, bat den Kandidaten, eine Funktion zu schreiben, die einen HTTP-Request durchführt und im Falle eines Fehlers mehrere Versuche unternimmt.

Er schrieb den Code direkt an die Tafel, daher hätte es gereicht, etwas Annäherndes darzustellen. Wenn er einfach gezeigt hätte, dass er das Wesentliche gut versteht, wären wir durchaus zufrieden gewesen. Doch leider gelang es ihm nicht, eine brauchbare Lösung zu finden. Daraufhin beschlossen wir, das Ganze aufgrund der Nervosität etwas zu erleichtern und baten ihn, die Rückruffunktion in eine auf Promises basierende Funktion umzuwandeln.

Leider war es offensichtlich, dass dieser Code dem Kandidaten nicht unbekannt war. Er hatte eine allgemeine Vorstellung davon, wie alles funktionierte. Ein grober Entwurf einer Lösung, der das Verständnis des Konzepts demonstrierte, hätte gereicht. Der Code, den der Kandidat an die Tafel schrieb, war jedoch völlig sinnlos. Er hatte ein sehr vages Verständnis davon, was Promises in JavaScript sind und konnte nicht wirklich erklären, wofür sie gut sind. Für einen Junior wäre das vielleicht noch entschuldbar gewesen, für eine Senior-Position jedoch nicht akzeptabel. Wie sollte dieser Entwickler in der Lage sein, Bugs in einer komplexen Promise-Kette zu beheben und den anderen zu erklären, was genau er gemacht hat?

Entwickler betrachten fertigen Code als selbstverständlich.

Im Entwicklungsprozess stoßen wir ständig auf wiederverwendbare Komponenten. Wir übertragen Code-Schnipsel, um nicht jedes Mal alles neu schreiben zu müssen. Daher betrachten wir den fertigen Code, mit dem wir arbeiten, als etwas Selbstverständliches – wir gehen einfach davon aus, dass alles wie gewünscht funktioniert.

Und im Allgemeinen funktioniert er wirklich gut, aber wenn Schwierigkeiten auftreten, ist das Verständnis seiner Mechanik mehr als lohnenswert.

Unser Kandidat für die Stelle als Senior-Entwickler hielt Promises für trivial. Er konnte sich wahrscheinlich vorstellen, wie man damit umgeht, wenn sie irgendwo im Code eines anderen auftauchen, verstand aber das zugrunde liegende Prinzip nicht und konnte es in dem Vorstellungsgespräch nicht selbst reproduzieren. Möglicherweise hatte er einen Ausschnitt auswendig gelernt – das ist nicht besonders schwer:

return new Promise((resolve, reject) => {
  functionWithCallback((err, result) => {
   return err ? reject(err) : resolve(result);
  });
});

Ich habe das auch so gemacht – das haben wir wahrscheinlich alle irgendwann getan. Wir haben einfach einen Codeabschnitt auswendig gelernt, um ihn später in der Arbeit zu verwenden, während wir nur grob verstanden, wie alles funktionierte. Aber wenn der Entwickler das Konzept wirklich verstanden hätte, müsste er nichts auswendig lernen – er wüsste einfach, wie es funktioniert, und könnte alles Notwendige mühelos im Code reproduzieren.

Gehen Sie zu den Wurzeln

Im Jahr 2012, als die Vorherrschaft von Frontend-Frameworks noch nicht etabliert war, regierte jQuery die Welt, und ich las das Buch Secrets of the JavaScript Ninja, dessen Autor John Resig, der Schöpfer von jQuery, war.

Das Buch lehrt den Leser, wie man jQuery von Grund auf selbst erstellt und bietet die einzigartige Gelegenheit, den Denkprozess nachzuvollziehen, der zur Schaffung der Bibliothek geführt hat. In den letzten Jahren hat jQuery an Popularität verloren, aber ich kann das Buch dennoch sehr empfehlen. Was mich am meisten beeindruckt hat, war das forte Gefühl, dass ich das alles auch selbst hätte erdenken können. Die Schritte, die der Autor darstellt, erschienen mir so logisch und verständlich, dass ich ernsthaft den Eindruck hatte, ich könnte jQuery problemlos erstellen, wenn ich nur den Mut hätte, es zu versuchen.

Natürlich hätte ich in der Realität nichts Derartiges geschafft – ich wäre zu dem Schluss gekommen, dass es unüberwindbar schwierig ist. Meine eigenen Lösungen wären mir zu einfach und naiv erschienen, um zu funktionieren, und ich hätte die Hände in den Schoß gelegt. Ich hätte jQuery für selbstverständlich gehalten, auf dessen korrekte Funktionsweise man einfach blind vertrauen muss. Später hätte ich wahrscheinlich keine Zeit damit verbracht, die Mechanik dieser Bibliothek zu verstehen, sondern sie einfach als eine Art Black Box genutzt.

Aber die Auseinandersetzung mit diesem Buch hat mich zu einem anderen Menschen gemacht. Ich begann, den Quellcode zu studieren und stellte fest, dass die Implementierung vieler Lösungen in Wirklichkeit sehr transparent, ja sogar offensichtlich ist. Natürlich ist es etwas anderes, selbst auf einen solchen Gedanken zu kommen. Doch genau das Studium des Codes anderer und das Reproduzieren bereits existierender Lösungen hilft uns, eigene Ideen zu entwickeln.

Die Inspiration, die Sie schöpfen, und die Muster, die Sie zu erkennen beginnen, werden Sie als Entwickler verändern. Sie werden feststellen, dass die wunderbare Bibliothek, die Sie ständig nutzen und über die Sie denken, sie sei ein magisches Artefakt, in Wirklichkeit nicht auf Magie basiert, sondern einfach ein Problem auf elegante und einfallsreiche Weise löst.

Manchmal muss man am Code tüfteln, ihn Schritt für Schritt zerlegen, aber genau so, durch kleine, aufeinanderfolgende Schritte voranzuschreiten, kann man den Weg des Autors zur Lösung nachvollziehen. Dies ermöglicht Ihnen, tiefer in den Prozess des Codierens einzutauchen und gibt Ihnen mehr Selbstvertrauen bei der Suche nach eigenen Lösungen.

Als ich anfing, mit Promises zu arbeiten, schien es mir wie pure Magie. Später erfuhr ich, dass sie auf den gleichen Callback-Mechanismen basieren, und meine Sicht auf Programmierung hat sich verändert. Das bedeutet, dass das Muster, das uns von Callbacks befreien soll, selbst mit Callbacks realisiert wird?!

Das half mir, die Dinge aus einer neuen Perspektive zu betrachten und zu erkennen, dass ich es hier nicht mit abstrakten Codefragmenten zu tun habe, deren Komplexität ich niemals begreifen könnte. Es sind lediglich Muster, die man mit Neugier und einem tiefen Verständnis problemlos meistern kann. So lernen Menschen das Programmieren und wachsen als Entwickler.

Erfinden Sie das Rad neu

Also scheuen Sie sich nicht, das Rad neu zu erfinden: Schreiben Sie den Code zur Datenbindung selbst, erstellen Sie ein selbstgemachtes Promise oder entwickeln Sie sogar Ihre eigene Lösung zur Zustandsverwaltung.
Es spielt keine Rolle, dass niemand jemals Gebrauch davon machen wird – aber jetzt haben Sie diese Fähigkeit. Wenn Sie später die Möglichkeit haben, diese Kenntnisse in Ihren eigenen Projekten anzuwenden, ist das großartig. Sie können sie weiterentwickeln und noch mehr lernen.

Es geht hier nicht darum, Ihren Code in die Produktion zu schicken, sondern darum, etwas Neues zu lernen. Die eigenständige Implementierung einer bereits bestehenden Lösung ist eine hervorragende Möglichkeit, von den besten Programmierern zu lernen und Ihr Handwerk zu verfeinern.

Quelle: habr.com