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

Vor kurzem hatte ich ein Vorstellungsgespräch mit einem JavaScript-Entwickler, der sich um eine Senior-Position beworben hat. Ein Kollege, der ebenfalls an dem Gespräch teilnahm, bat den Kandidaten, eine Funktion zu schreiben, die eine HTTP-Anfrage ausführt und im Falle eines Fehlers mehrere Versuche unternimmt.

Er schrieb den Code direkt an die Tafel, daher hätte es ausgereicht, etwas Annäherndes darzustellen. Wenn er lediglich gezeigt hätte, dass er gut versteht, worum es geht, wären wir durchaus zufrieden gewesen. Aber leider gelang es ihm nicht, eine gute Lösung zu finden. Daher haben wir, nachdem wir es auf seine Nervosität geschoben hatten, beschlossen, die Aufgabe ein wenig zu erleichtern und ihn zu bitten, die Rückruf-Funktion in eine auf Promises basierende Funktion umzuwandeln.

Aber leider. Ja, es war offensichtlich, dass er mit solchem Code schon früher in Berührung gekommen war. Er wusste ganz grob, wie das alles funktioniert. Ein Entwurf der Lösung, der das Verständnis des Konzepts demonstriert hätte, hätte uns genügt. Doch der Code, den der Kandidat an die Tafel schrieb, war völlig sinnlos. Er hatte ein äußerst vages Verständnis davon, was Promises in JavaScript sind, und konnte nicht richtig erklären, wozu sie gut sind. Für einen Junior wäre das vielleicht noch entschuldbar gewesen, aber für eine Senior-Position reichte es nicht aus. Wie sollte dieser Entwickler in der Lage sein, Bugs in komplexen Promise-Ketten zu beheben und den anderen zu erklären, was genau er getan hat?

Entwickler betrachten den bereitgestellten Code als selbstverständlich.

Im Verlauf der Entwicklung stoßen wir ständig auf reproduzierbare Materialien. Wir übertragen Codeausschnitte, damit wir sie nicht jedes Mal neu schreiben müssen. Daher konzentrieren wir unser ganzes Augenmerk auf die Schlüsselteile und sehen den fertigen Code, mit dem wir arbeiten, als etwas Selbstverständliches – wir gehen einfach davon aus, dass darin alles funktioniert wie es sollte.

Und normalerweise funktioniert er tatsächlich, aber wenn Schwierigkeiten auftreten, lohnt es sich mehr als genug, seine Mechanik zu verstehen.

So hielt unser Kandidat für die Senior-Entwicklerposition Objekte vom Typ Promise für selbstverständlich. Er stellte sich vermutlich vor, wie man mit ihnen umgeht, wenn sie irgendwo in fremdem Code auftauchen, aber das Gesamtkonzept verstand er nicht und konnte es im Vorstellungsgespräch selbst nicht wiederholen. Vielleicht hatte er einen Codeausschnitt auswendig gelernt – das ist nicht so schwer:

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

Ich habe das auch gemacht – wahrscheinlich haben wir alle irgendwann so gehandelt. Wir haben einfach einen Teil des Codes auswendig gelernt, um ihn später in der Arbeit zu verwenden, wobei wir nur grob verstanden haben, wie alles funktioniert. Wenn der Entwickler das Konzept wirklich verstanden hätte, müsste er sich nichts merken – er wüsste einfach, wie es geht, und würde alles Notwendige mühelos im Code reproduzieren.

Gehe an die Wurzeln

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

Das Buch lehrt den Leser, wie man seine eigene jQuery von Grund auf erstellt, und bietet eine einzigartige Möglichkeit, den Denkprozess nachzuvollziehen, der zur Schaffung der Bibliothek führte. In den letzten Jahren hat jQuery an Beliebtheit verloren, aber ich empfehle das Buch trotzdem sehr. Was mich am meisten beeindruckt hat, war das hartnäckige Gefühl, dass ich mir all das selbst hätte ausdenken können. Die Schritte, die der Autor erklärte, erschienen so logisch und so verständlich, dass ich ernsthaft dachte, ich könnte problemlos jQuery erschaffen, wenn ich nur anfangen würde.

Natürlich hätte ich in Wirklichkeit nichts dergleichen geschafft – ich hätte gedacht, das sei unüberwindbar schwer. Eigene Lösungen wären mir zu einfach und naiv erschienen, um zu funktionieren, und ich hätte aufgegeben. Ich hätte jQuery als eine Selbstverständlichkeit angesehen, deren korrekte Funktionsweise man einfach blind glauben muss. Später hätte ich wahrscheinlich keine Zeit damit verbracht, die Mechanik dieser Bibliothek zu verstehen, sondern hätte sie einfach als eine Art Blackbox genutzt.

Aber die Bekanntschaft mit diesem Buch hat mich zu einem anderen Menschen gemacht. Ich begann, den Quellcode zu studieren, und stellte fest, dass die Umsetzung vieler Lösungen in der Tat sehr transparent, sogar offensichtlich ist. Nein, natürlich ist es eine andere Sache, sich selbst etwas Derartiges auszudenken. Aber gerade das Studium fremden Codes und die Reproduktion existierender Lösungen helfen uns, etwas Eigenes zu entwickeln.

Die Inspiration, die Sie schöpfen werden, und die Muster, die Sie beginnen zu bemerken, werden Sie als Entwickler verändern. Sie werden feststellen, dass die wunderbare Bibliothek, die Sie ständig verwenden und von der Sie gewohnt sind, als magisches Artefakt zu denken, ganz und gar nicht auf Magie basiert, sondern einfach das Problem klar und einfallsreich löst.

Manchmal müssen Sie an dem Code tüfteln und ihn Schritt für Schritt zerlegen, aber genau so, in kleinen, aufeinander folgenden Schritten voranzukommen, können Sie den Weg des Autors zur Lösung nachverfolgen. Das wird Ihnen helfen, tiefer in den Programmierprozess einzutauchen und mehr Selbstvertrauen bei der Suche nach eigenen Lösungen zu gewinnen.

Als ich anfing, mit Promises zu arbeiten, kam es mir vor wie reine Magie. Dann erfuhr ich, dass sie auf denselben Rückruf-Mechanismen basieren, und meine Programmierwelt hat sich gewandelt. Das bedeutet, dass das Muster, dessen Ziel es ist, uns von Rückrufen zu befreien, selbst durch Rückrufe realisiert wird?!

Das hat mir geholfen, die Dinge aus einer anderen Perspektive zu betrachten und zu erkennen, dass die Code-Schnipsel vor mir keine abgehobene Komplexität darstellen, die ich nie begreifen werde. Es sind einfach Muster, die man mit der nötigen Neugier und tiefem Eintauchen problemlos verstehen kann. So lernen Menschen programmieren und wachsen als Entwickler.

Erfinden Sie das Rad neu

Also, zögern Sie nicht, Räder neu zu erfinden: Schreiben Sie den Code zur Datenbindung selbst, erstellen Sie ein hausgemachtes Promise oder entwickeln Sie sogar Ihre eigene Lösung zur Zustandsverwaltung.
Es spielt keine Rolle, dass damit am Ende niemand jemals etwas anfangen wird – Sie wissen es jetzt. Und wenn Sie die Möglichkeit haben, solche Entwicklungen später in eigenen Projekten zu verwenden, ist das umso besser. 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 eigene Implementierung einer bereits bestehenden Lösung zu schreiben, ist eine hervorragende Möglichkeit, von den besten Programmierern zu lernen und so sein Handwerk zu verfeinern.

Quelle: habr.com