Warum ist es sinnvoll, das Rad neu zu erfinden?

Neulich habe ich einen JavaScript-Entwickler interviewt, der sich für eine leitende Position beworben hat. Ein Kollege, der ebenfalls beim Vorstellungsgespräch anwesend war, bat den Kandidaten, eine Funktion zu schreiben, die eine HTTP-Anfrage stellt und, wenn sie nicht erfolgreich ist, mehrmals versucht.

Er hat den Code direkt an die Tafel geschrieben, es würde also ausreichen, etwas Ungefähres zu zeichnen. Wenn er einfach gezeigt hätte, dass er die Sache gut versteht, wären wir durchaus zufrieden gewesen. Aber leider konnte er keine erfolgreiche Lösung finden. Dann beschlossen wir, die Sache als Aufregung zu bezeichnen, die Aufgabe etwas einfacher zu machen und baten ihn, eine Funktion mit Rückrufen in eine auf Versprechen basierende Funktion umzuwandeln.

Aber leider. Ja, es war offensichtlich, dass er schon einmal auf solchen Code gestoßen war. Er wusste im Großen und Ganzen, wie dort alles funktionierte. Alles, was wir brauchen, ist eine Skizze einer Lösung, die das Verständnis des Konzepts zeigt. Der Code, den der Kandidat an die Tafel schrieb, war jedoch völliger Unsinn. Er hatte eine sehr vage Vorstellung davon, was Versprechen in JavaScript sind, und konnte nicht wirklich erklären, warum sie benötigt wurden. Für einen Junior wäre das verzeihlich gewesen, aber für die Position eines Seniors war er nicht mehr geeignet. Wie könnte dieser Entwickler Fehler in einer komplexen Kette von Versprechungen beheben und anderen erklären, was er genau getan hat?

Entwickler betrachten vorgefertigten Code als selbstverständlich

Im Entwicklungsprozess stoßen wir immer wieder auf reproduzierbare Materialien. Wir übertragen Codefragmente, damit wir sie nicht jedes Mal neu schreiben müssen. Indem wir unsere gesamte Aufmerksamkeit auf die wesentlichen Teile richten, betrachten wir den fertigen Code, mit dem wir arbeiten, als etwas Selbstverständliches – wir gehen einfach davon aus, dass alles so funktionieren wird, wie es sollte.

Und normalerweise funktioniert es, aber wenn es knifflig wird, zahlt es sich mehr als aus, die Mechanik zu verstehen.

Daher hielt unser Kandidat für die Position des Senior Developer Versprechensobjekte für selbstverständlich. Er hatte wahrscheinlich eine Idee, wie man damit umgehen sollte, wenn sie irgendwo im Code eines anderen auftauchen, aber er verstand das allgemeine Prinzip nicht und konnte es im Interview nicht selbst wiederholen. Vielleicht erinnerte er sich auswendig an das Fragment – ​​es ist gar nicht so schwer:

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

Ich habe es auch gemacht – und wir haben es wahrscheinlich alle schon einmal gemacht. Sie haben sich einfach einen Code gemerkt, um ihn später in ihrer Arbeit verwenden zu können, während sie nur eine allgemeine Vorstellung davon hatten, wie dort alles funktionierte. Aber wenn der Entwickler das Konzept wirklich versteht, müsste er sich an nichts erinnern – er würde einfach wissen, wie es geht, und könnte alles, was er braucht, problemlos im Code reproduzieren.

Gehen Sie zurück zu den Wurzeln

Im Jahr 2012, als die Dominanz von Front-End-Frameworks noch nicht etabliert war, regierte jQuery die Welt und ich las das Buch Geheimnisse des JavaScript-Ninjas, verfasst von John Resig, dem Erfinder von jQuery.

Das Buch zeigt dem Leser, wie er seine eigene jQuery von Grund auf erstellen kann, und bietet einen einzigartigen Einblick in den Denkprozess, der zur Erstellung der Bibliothek führte. In den letzten Jahren hat jQuery seine frühere Beliebtheit verloren, aber ich kann das Buch immer noch wärmstens empfehlen. Was mich an ihr am meisten beeindruckte, war das anhaltende Gefühl, dass ich an all das selbst hätte denken können. Die Schritte, die der Autor beschrieb, schienen so logisch und klar, dass ich ernsthaft zu glauben begann, dass ich jQuery leicht erstellen könnte, wenn ich mich nur an die Arbeit mache.

Natürlich wäre mir so etwas in der Realität nicht gelungen – ich hätte entschieden, dass es unerträglich schwierig ist. Meine eigenen Lösungen schienen zu einfach und naiv, um zu funktionieren, und ich würde aufgeben. Ich würde jQuery als selbstverständliche Dinge einstufen, an deren korrekte Funktionsweise man einfach blind glauben muss. Anschließend würde ich kaum Zeit damit verschwenden, mich mit der Mechanik dieser Bibliothek zu befassen, sondern sie einfach als eine Art Blackbox nutzen.

Aber die Lektüre dieses Buches hat mich zu einem anderen Menschen gemacht. Ich begann, den Quellcode zu lesen und stellte fest, dass die Implementierung vieler Lösungen tatsächlich sehr transparent, ja sogar offensichtlich war. Nein, natürlich ist es eine andere Geschichte, sich so etwas selbst auszudenken. Aber erst das Studium des Codes anderer Leute und das Reproduzieren vorhandener Lösungen hilft uns, etwas Eigenes zu entwickeln.

Die Inspiration, die Sie gewinnen, und die Muster, die Sie bemerken, werden Sie als Entwickler verändern. Sie werden feststellen, dass diese wunderbare Bibliothek, die Sie ständig nutzen und die Sie gewohnt sind, als magisches Artefakt zu betrachten, überhaupt nicht mit Magie funktioniert, sondern einfach ein Problem lakonisch und einfallsreich löst.

Manchmal müssen Sie über den Code nachdenken und ihn Schritt für Schritt analysieren, aber so können Sie in kleinen, konsistenten Schritten den Weg des Autors zur Lösung wiederholen. Dadurch können Sie tiefer in den Codierungsprozess eintauchen und erhalten mehr Sicherheit bei der Entwicklung Ihrer eigenen Lösungen.

Als ich anfing, mit Versprechungen zu arbeiten, kam es mir wie pure Magie vor. Dann fand ich heraus, dass sie auf denselben Rückrufen basierten, und meine Programmierwelt stellte sich auf den Kopf. Das Muster, dessen Zweck darin besteht, uns vor Rückrufen zu bewahren, wird also selbst mithilfe von Rückrufen implementiert?!

Dies hat mir geholfen, die Sache mit anderen Augen zu betrachten und zu erkennen, dass es sich hier nicht um einen abstrusen Code handelt, dessen unerschwingliche Komplexität ich in meinem Leben nie begreifen werde. Dabei handelt es sich lediglich um Muster, die bei entsprechender Neugier und tiefem Eintauchen problemlos verstanden werden können. Auf diese Weise lernen Menschen das Programmieren und entwickeln sich als Entwickler weiter.

Erfinden Sie dieses Rad neu

Also legen Sie los und erfinden Sie das Rad neu: Schreiben Sie Ihren eigenen Datenbindungscode, erstellen Sie ein selbst entwickeltes Versprechen oder entwickeln Sie sogar Ihre eigene Lösung für die Zustandsverwaltung.
Es spielt keine Rolle, dass niemand das alles jemals nutzen wird – aber jetzt wissen Sie, wie es geht. Und wenn man die Möglichkeit hat, solche Entwicklungen anschließend in eigenen Projekten zu nutzen, dann ist das grundsätzlich großartig. Sie werden in der Lage sein, sie weiterzuentwickeln und etwas anderes zu lernen.

Hier geht es nicht darum, Ihren Code in die Produktion zu schicken, sondern darum, etwas Neues zu lernen. Das Schreiben Ihrer eigenen Implementierung einer vorhandenen Lösung ist eine großartige Möglichkeit, von den besten Programmierern zu lernen und so Ihre Fähigkeiten zu verbessern.

Source: habr.com