Neulich habe ich einen JavaScript-Entwickler interviewt, der behauptete, ein Senior zu sein. Ein Kollege, der auch beim Interview anwesend war, bat den Kandidaten, eine Funktion zu schreiben, die eine HTTP-Anfrage erzeugt, und es im Fehlerfall mehrmals zu versuchen.
Er schrieb den Code sofort an die Tafel, sodass es ausreichen würde, etwas ungefähres darzustellen. Wenn er einfach zeigen würde, dass er gut versteht, was das Wesentliche ist, wären wir vollkommen zufrieden. Leider konnte er keine erfolgreiche Lösung finden. Als wir dies als Aufregung abschrieben, beschlossen wir, die Aufgabe ein wenig zu vereinfachen, und baten ihn, eine Funktion zu erstellen, die auf Versprechungen einer Funktion mit Rückrufen basiert.
Aber leider. Ja, es war offensichtlich, dass er zuvor auf einen ähnlichen Code gestoßen war. Im Allgemeinen wusste er, wie dort alles funktionierte. Eine Skizze einer Lösung, die ein Verständnis des Konzepts demonstrieren würde, würde ausreichen. Der Code, den der Kandidat an die Tafel schrieb, war jedoch völlig Unsinn. Er hatte eine äußerst vage Vorstellung davon, was JavaScript-Versprechen waren, und er konnte nicht wirklich erklären, warum sie gebraucht wurden. Für den Junior wäre dies entschuldbar gewesen, aber die Position des Senioren wurde nicht mehr gezogen. Wie würde dieser Entwickler es schaffen, Fehler in einer komplexen Kette mit Versprechungen zu beseitigen und den anderen zu erklären, was genau er getan hat?
Entwickler halten vorgefertigten Code für selbstverständlich
Im Entwicklungsprozess begegnen wir ständig reproduzierbaren Materialien. Wir übertragen Codefragmente, damit wir sie nicht jedes Mal registrieren müssen. Wenn wir unsere ganze Aufmerksamkeit auf wichtige Teile richten, betrachten wir den fertigen Code, mit dem wir arbeiten, als etwas Selbstverständliches - wir gehen einfach davon aus, dass alles so funktioniert, wie es sollte.
Und normalerweise funktioniert es wirklich, aber wenn Schwierigkeiten auftreten, zahlt sich ein Verständnis der Mechanik mehr als aus.
Unser Kandidat für die Position eines leitenden Entwicklers hielt Versprechen als selbstverständlich. Er stellte sich wahrscheinlich vor, wie er mit ihnen umgehen sollte, wenn sie sich irgendwo im Code eines anderen treffen, aber er verstand das allgemeine Prinzip nicht und konnte es beim Interview nicht selbst wiederholen. Vielleicht erinnerte er sich auswendig an das Fragment - es ist nicht so schwierig:
return new Promise((resolve, reject) => { functionWithCallback((err, result) => { return err ? reject(err) : resolve(result); }); });
Ich habe es auch getan - ja, wir alle haben es wahrscheinlich eines Tages getan. Sie haben einfach einen Code auswendig gelernt, damit sie ihn später in ihrer Arbeit verwenden können, während sie sich nur allgemein vorstellen, wie dort alles funktioniert. Aber wenn der Entwickler das Konzept wirklich verstanden hätte, müsste er sich nichts merken - er würde nur wissen, wie es geht, und würde leicht alles reproduzieren, was im Code notwendig ist.
Geh zu den Wurzeln
2012, als die Dominanz der Front-End-Frameworks noch nicht etabliert war, regiert die jQuery-Welt und ich las das Buch
Secrets of the JavaScript Ninja , verfasst von John Rezig, dem Erfinder von jQuery.
Das Buch zeigt dem Leser, wie Sie Ihre eigene jQuery von Grund auf neu erstellen können, und bietet eine einzigartige Gelegenheit, sich dem Gedankengang anzuschließen, der zur Erstellung der Bibliothek geführt hat. In den letzten Jahren hat jQuery seine frühere Popularität verloren, aber ich kann das Buch immer noch sehr empfehlen. Was mich an ihr am meisten beeindruckte, war das anhaltende Gefühl, dass ich selbst an all das denken konnte. Die Schritte, die der Autor gemalt hat, schienen so logisch und verständlich, dass es mir ernsthaft erschien, dass ich jQuery leicht erstellen könnte, wenn ich nur zur Sache käme.
In Wirklichkeit hätte ich so etwas natürlich nicht gemeistert - ich hätte entschieden, dass es extrem schwierig ist. Meine eigenen Entscheidungen scheinen mir zu einfach und naiv zu sein, um zu arbeiten, und ich würde aufgeben. Ich würde jQuery selbstverständlichen Dingen zuschreiben, an deren korrekte Funktionsweise Sie nur blind glauben müssen. In der Folge hätte ich kaum Zeit damit verschwendet, mich mit der Mechanik dieser Bibliothek zu befassen, sondern sie einfach als eine Art Black Box verwendet.
Aber dieses Buch kennenzulernen machte mich zu einer anderen Person. Ich begann den Quellcode zu lesen und stellte fest, dass die Implementierung vieler Lösungen tatsächlich sehr transparent und sogar offensichtlich ist. Nein, natürlich selbst an so etwas zu denken - das ist aus einer anderen Oper. Aber es ist das Studium des Codes eines anderen und die Reproduktion bestehender Lösungen, die uns hilft, etwas Eigenes zu finden.
Die Inspiration, die Sie zeichnen, und die Muster, die Sie bemerken, werden Sie als Entwickler verändern. Sie werden feststellen, dass die schöne Bibliothek, die Sie ständig benutzen und die Sie gewohnt sind, als magisches Artefakt zu betrachten, überhaupt nicht mit Magie funktioniert, sondern das Problem einfach kurz und einfallsreich löst.
Manchmal ist es notwendig, den Code zu durchforsten und ihn Schritt für Schritt zu zerlegen. Auf diese Weise können Sie jedoch in kleinen aufeinander folgenden Schritten den Pfad des Autors zur Lösung wiederholen. Auf diese Weise können Sie tiefer in den Prozess des Schreibens von Code eintauchen und mehr Vertrauen bei der Suche nach Ihren eigenen Lösungen gewinnen.
Als ich anfing, mit Versprechungen zu arbeiten, schien mir dies reine Magie zu sein. Dann fand ich heraus, dass sie auf denselben Rückrufen basierten, und meine Programmierwelt stellte sich auf den Kopf. Das heißt, ein Muster, dessen Zweck es ist, uns vor Rückrufen zu bewahren, wird selbst mithilfe von Rückrufen implementiert ?!
Dies half mir, die Angelegenheit mit anderen Augen zu betrachten und zu erkennen, dass sich keine abstrusen Codeteile vor mir befinden, die transzendente Komplexität, die ich in meinem Leben niemals verstehen werde. Dies sind nur Muster, die mit gebührender Neugier und tiefem Eintauchen leicht zu verstehen sind. Auf diese Weise lernen Menschen, als Entwickler zu programmieren und zu wachsen.
Dieses Rad neu erfinden
Sie können also die Räder neu erfinden: Schreiben Sie den Code für die Datenbindung selbst, erstellen Sie ein eigenes Versprechen oder treffen Sie sogar die Entscheidung, Ihre Bedingungen mit Ihren eigenen Händen zu verwalten.
Es spielt keine Rolle, dass niemand all dies jemals nutzen wird - aber jetzt können Sie es tun. Und wenn Sie die Möglichkeit haben, solche Entwicklungen später in Ihren eigenen Projekten zu nutzen, ist dies im Allgemeinen großartig. Sie können sie entwickeln und etwas anderes lernen.
Hier geht es nicht darum, Ihren Code an die Produktion zu senden, sondern etwas Neues zu lernen. Die Implementierung einer vorhandenen Lösung selbst vorzuschreiben, ist eine großartige Möglichkeit, von den besten Programmierern zu lernen und dadurch Ihre Fähigkeiten zu verbessern.