Zeitsparende VSCode-Kurzbefehle zur Steigerung der Entwicklerproduktivität

Observability ist ein entscheidender Aspekt bei der Entwicklung und Wartung zuverlässiger Anwendungen, und bei Easy Agile haben wir große Anstrengungen unternommen, um unsere Anwendungen so beobachtbar wie möglich zu machen. In einem kürzlichen Vortrag auf dem Atlas Camp 2025 berichtete Ryan Brown, unser Staff Engineer, über unsere Erfahrungen bei der Umstellung auf Forge und die dabei gewonnenen Erkenntnisse. Hier sind die wichtigsten Höhepunkte seines Vortrags.

Was ist Beobachtbarkeit und warum ist sie wichtig

Bei Observability geht es darum, genügend Daten zu sammeln und zu visualisieren, um den Zustand Ihrer Softwaresysteme zu verstehen und Probleme zu beheben, wenn sie auftreten. Im Gegensatz zur herkömmlichen Überwachung, bei der Sie erfahren, was wann passiert ist, geht Observability noch einen Schritt weiter und erklärt, warum und wie Probleme auftreten.

Für uns bei Easy Agile bedeutet starke Beobachtbarkeit:

• Hat uns geholfen, bessere Entscheidungen über Leistungs- und Infrastrukturanforderungen zu treffen
• Wir haben unseren Kundensupport drastisch verbessert, indem wir Probleme schnell lokalisieren konnten
• Passen wir uns an die Realität moderner, verteilter Anwendungen an

Ryan drückte es in seinem Vortrag so aus: „Als ich damals an Anwendungen gearbeitet habe, liefen wir auf zwei, drei, vielleicht höchstens vier Rechenzentren. Jetzt sprechen wir über Anwendungen, die auf globaler Ebene wachsen und von Menschen auf der ganzen Welt genutzt werden.“

Moderne Anwendungen sind weitaus verteilter als früher, und dicke Frontends werden so komplex wie Backends. Aufgrund dieser Verteilung ist der herkömmliche Ansatz, einige Server manuell zu überprüfen, unzureichend — wir benötigen ausgeklügelte Observability-Lösungen, um zu verstehen, was auf unseren Systemen vor sich geht.

Die drei Säulen der Beobachtbarkeit

Observability basiert auf drei Hauptpfeilern:

Metriken

Dies sind die zahlenbasierten Messungen Ihrer Software — CPU-Auslastung, Anforderungszeiten, Fehleranzahl usw. Aber rohe Zahlen allein sind nicht sehr hilfreich. Der Kontext ist entscheidend — zu wissen, dass Sie fünf Fehler haben, ist etwas ganz anderes als zu wissen, dass Sie innerhalb von zwei Minuten fünf Fehler von einem bestimmten Benutzer auf einem Server haben.

Metriken sind besonders aussagekräftig, wenn es darum geht, Trends im Laufe der Zeit zu identifizieren, sodass Sie genau feststellen können, wann Leistungsprobleme auftraten, oder Änderungen mit dem Systemverhalten korrelieren können.

Logs

Logs sind oft das Erste, womit Ingenieure Erfahrung sammeln, wenn es um Observability geht. Sie bieten detaillierte Aufzeichnungen von Ereignissen und sind der Eckpfeiler, um zu verstehen, was in Ihrem System vor sich geht. Sie liefern mehr Informationen als nur Metriken und erfassen nicht nur, was passiert ist, sondern auch Details zu jedem Ereignis, das eingetreten ist.

Sie sind reicher an Informationen, generieren aber auch mehr Daten. Logs könnten Ihnen beispielsweise sagen, dass ein Fehler aufgetreten ist, weil eine API eine schlechte Antwort zurückgegeben hat — aber das allein sagt Ihnen immer noch nicht, warum die Downstream-API ausgefallen ist.

Spuren

Mithilfe von Traces können Sie nachvollziehen, was auf all Ihren Systemen passiert, die zusammenarbeiten. Sie verfolgen Transaktionen, während sie verschiedene Dienste durchlaufen, und zeigen Ihnen genau, was passiert, wenn ein Benutzer auf eine Schaltfläche klickt oder eine Aktion ausführt.

„Die Rückverfolgung ist überraschend einfach“, erklärte Ryan. „Sie haben lediglich eine eindeutige Kennung für eine Transaktion, die von einem System zum nächsten System gemeinsam genutzt wird.“

Traces sind besonders nützlich, wenn Sie diese Kennung Endbenutzern zur Verfügung stellen können, wenn etwas schief geht. Diese ID kann Ihnen genau zeigen, was bei dieser Transaktion passiert ist, sodass das Rätselraten bei der Fehlerbehebung ein Kinderspiel ist.

‍

Beobachtbarkeit bei Connect und Forge

Unser aktueller Connect-Ansatz

Bei Easy Agile haben wir umfassende Observability für unsere Connect-Apps implementiert.

• Für alle unsere Anwendungen erfasste Metriken, Logs und Traces
• All diese Daten werden an einen Observability-Dienst eines Drittanbieters gesendet, um eine zentrale Ansicht zu erhalten
• Frontend-Komponenten, die auch Observability-Daten an denselben Dienst senden

Dieser Ansatz reduziert die kognitive Belastung unserer Techniker und bietet einen vollständigen Überblick über die Benutzerabläufe und das, was in unseren Systemen passiert. Dafür empfiehlt Ryan, kommerzielle Dienste wie Datadog oder New Relic oder sogar Open-Source-Optionen wie Signoz zu verwenden.

Bedenken hinsichtlich des Übergangs für Forge

Als wir uns Forge zum ersten Mal ansahen, hatten wir mehrere Fragen:

• Wie gut würde Tracing mit dem Kommunikationsmodell von Forge funktionieren?
• Könnten wir unsere eigenen benutzerdefinierten Metriken definieren?
• Wären wir in der Lage, Metriken und Logs sowohl vom Frontend als auch vom Backend zu sammeln?
• Könnten wir bestimmte Benutzertransaktionen zu Supportzwecken identifizieren?

Zum Zeitpunkt unserer Evaluierung waren Forge-Funktionen die primäre verfügbare Rechenoption, was Fragen zur Funktionsweise von Standard-Tracing-Bibliotheken im einzigartigen Kommunikationsmodell von Forge aufwarf.

Experimentieren mit einer einfachen App

Anstatt zu versuchen, eines unserer größeren Produkte zu migrieren, haben wir eine einfache „Sprint Notes“ -App erstellt, um die Beobachtbarkeit auf Forge zu testen. Dadurch konnten wir:

• Iterieren Sie schnell durch verschiedene Forge-Topologien
• Konzentrieren Sie sich beim Experiment auf die Beobachtbarkeit
• Beinhaltet alle notwendigen Komponenten (UI, API, Datenbank)

Wir haben diese App durch mehrere Phasen geführt:

1. Verbinde dich auf Forge: Unsere Connect-App über Forge ausführen
2. Forge mit Fernbedienungen: Verwenden Sie zwei Ansätze: Aufrufen von Fernbedienungen über Forge-Funktionen und Aufrufen von Fernbedienungen direkt von der Benutzeroberfläche aus‍
3. Forge Native: Die App komplett neu schreiben, um die Forge-Funktionen und den Entitätsspeicher zu verwenden

Wichtigste Ergebnisse

Auf Forge verbinden

Wenn Sie unsere Connect-App über Forge ausführen:

• Unsere gesamte bestehende Beobachtbarkeit funktionierte ohne Änderungen
• Frontend- und Backend-Metriken funktionierten weiterhin wie zuvor
• Die Ablaufverfolgungskennungen wurden korrekt weitergegeben
• Logs und Metriken wurden nicht in der Atlassian Developer Console angezeigt (was sinnvoll ist, da wir keine Forge-Module verwendet haben)

Die Observability-Story für Connect on Forge ist ziemlich einfach — sie funktioniert einfach. Ryan merkte an: „Die gesamte Observability, die wir auf Connect eingerichtet hatten, funktionierte genauso wie zuvor. Es gab keine großen Änderungen oder Probleme mit dem, was wir dort gesehen haben.“

Wir haben sogar mit verschiedenen Methoden experimentiert, um Daten an unseren Observability-Dienst zu senden, einschließlich der Verwendung eines Proxys unter unserer eigenen Domain, und alles funktionierte konsistent, solange die richtigen Content-Security-Header gesetzt waren.

Forge mit Fernbedienungen

Für Forge mit Fernbedienungen haben wir Folgendes gefunden:

• Frontend- und Backend-Observability funktionierten größtenteils
• Wir mussten permissions.external.fetch.client so einstellen, dass Metriken vom Frontend aus gesendet werden können
• Das Hinzufügen dieser Berechtigungen erforderte ein Upgrade der Hauptversion
• Metriken erfassten nicht alle API-Aufrufe, insbesondere Frontend-Aufrufe an Atlas-APIs
• Tracing-Identifikatoren waren Remote-Anrufern nicht zugänglich, wodurch die durchgängige Verfolgung eingeschränkt wurde

„Das ist ein bisschen enttäuschend... wir haben festgestellt, dass Forge bei Anrufen an unsere Fernbedienungen Tracing-Identifikatoren für die Verwendung im Backend generierte, aber leider waren diese Identifikatoren dann nicht dem ausgesetzt, was diese Fernanrufe tätigte“, erklärte Ryan.

Wir konnten zwar Protokolle in der Developer Console sehen und einige Metriken wurden erfasst, aber die Unfähigkeit, Tracing-Identifikatoren an Aufrufer weiterzuleiten, bedeutete, dass wir keine vollständige Rückverfolgbarkeit von der Benutzeroberfläche zur Datenbank erreichen oder Transaktions-IDs den Endbenutzern anzeigen konnten, ohne Problemumgehungen zu implementieren.

Forge-Einheimischer

Mit einem vollständig nativen Forge-Ansatz:

• Benutzerdefinierte Metriken und einfaches Tracing sind möglich, erfordern jedoch einen erheblichen Aufwand.
• Wir mussten eine benutzerdefinierte Handhabung mit Bibliotheken wie OpenTelemetry implementieren
• Die Beobachtbarkeit der Benutzeroberfläche blieb ähnlich wie bei der Remote-Implementierung.
• Wir könnten über undokumentierte Forge-API-Funktionen auf Korrelations-IDs zugreifen

Wir haben es geschafft, einen Machbarkeitsnachweis zu erstellen, der Spuren von Forge-Funktionen zu unserem Observability-Dienst zeigt, obwohl die Implementierung einer vollständigen Datenspeicherverfolgung zusätzliche Arbeit erfordern würde.

Empfehlungen und bewährte Verfahren

Basierend auf unseren Ergebnissen empfehlen wir:

1. Legen Sie Basiswerte für die Beobachtbarkeit fest

Finden Sie heraus, welche Daten Sie wirklich benötigen, anstatt alles zu sammeln. Observability-Dienste werden nach Volumen abgerechnet, sodass das Sammeln unnötiger Daten schnell teuer werden kann.

2. Verwenden Sie OpenTelemetry‍

Es entspricht der internen Implementierung von Forge und bietet eine gute Standardisierung. Es ist zwar schwieriger zu verwenden als einige sofort einsatzbereite Lösungen, aber die langfristigen Vorteile sind es wert.

‍3. Ziehen Sie einen Observability-Proxy in Betracht

Dies ermöglicht:

• Authentifizierung für eingehende Metriken
• Zusätzlichen Kontext hinzufügen
• Datenredigierung für sensible Informationen
• Entkopplung Ihrer Implementierung von bestimmten Anbietern

In Kombination mit OpenTelemetry bedeutet dieser Ansatz, dass Ihre Forge-Komponenten nicht wissen müssen, welchen Observability-Dienst Sie verwenden, wodurch Berechtigungsänderungen vermieden werden, wenn Sie den Anbieter wechseln.

4. Plane Genehmigungsaktualisierungen strategisch

Da sie wichtige Versionsupgrades erfordern, sollten Sie sie frühzeitig in Ihre Entwicklung einbeziehen.

5. Weitere wichtige Überlegungen

• Größere Versionsupgrades sind erforderlich, wenn Berechtigungen für Observability hinzugefügt werden
• Die Dokumentation für den Export von Logs und Metriken ist technisch korrekt, kann aber leicht falsch interpretiert werden
• Traces werden in Remote-Implementierungen nicht automatisch an Aufrufer weitergegeben

Abschließende Gedanken

Das Erreichen aller drei Säulen der Beobachtbarkeit auf Forge ist möglich, erfordert jedoch je nach Ihrer Implementierungsstrategie unterschiedliche Ansätze:

• Connect on Forge funktioniert nahtlos mit vorhandener Observability
• Forge mit Fernbedienungen erfordert eine zusätzliche Konfiguration
• Forge Native benötigt mehr benutzerdefinierte Implementierung

Diese Experimente werden für Open Source vorbereitet, also bleiben Sie dran Ryans LinkedIn für Updates.

Wir alle wissen, dass das Schreiben von Komponententests wichtig ist, aber manchmal fühlt es sich an, als ob es mehr Zeit in Anspruch nehmen kann als die Feature-Arbeit selbst. Ich habe ein paar praktische Hacks gefunden, von denen ich glaube, dass sie meine Geschwindigkeit beim Schreiben von Tests erhöht und gleichzeitig deren Qualität verbessert haben. Da ich der nette Kerl bin, werde ich sie mit Ihnen teilen:

Hack 1: Benutze Testing Playground

Ich denke, der erste Tipp in diesem Artikel ist - benutze Bibliothek zum Testen. Ich habe das nicht zu meinem eigenen Argument gemacht, weil es bereits so beliebt ist. Aber wenn Sie es noch nicht verwenden, stellen Sie sicher, dass Sie es tun!

Unit-Tests mit der Testing Library sind wirklich einfach und intuitiv. Trotzdem kann es immer noch schwierig sein, die richtigen Abfragen zu finden oder zu verstehen, warum ein Element nicht gefunden wird.

Geben Sie ein Playground testen.

Beim Testen von Playground können Sie eine Komponente in einer Sandbox rendern, sodass Sie direktes visuelles Feedback der Komponente erhalten. Außerdem können Sie mit der gerenderten Komponente interagieren, um die besten Abfragen für die Auswahl von Elementen zu erstellen. Und wie bei Testing Library steht bei allem, was es tut, Barrierefreiheit (a11y) im Vordergrund, sodass Sie bei der Verwendung von a11y über die Bedeutung von a11y und über bewährte Methoden informiert werden.

Es gibt viele Möglichkeiten, Testing Playground zu verwenden, einschließlich eines Chrome-Geräts Ausdehnung und ein browserbasierte App.

Der beste Weg, den ich gefunden habe und der für mich eine absolute Zeitersparnis war, ist der Aufruf screen.log testingPlaygroundUrl () direkt aus dem Testblock selbst. Normalerweise mache ich das, sobald ich das Komponenten-Rendering habe, nur um mir einen Überblick zu verschaffen und herauszufinden, mit welchen Teilen mein Test interagieren möchte.

Hack 2: Benutze test.todo

Bitte springen Sie mir nicht an die Gurgel, aber ich habe es versucht Testgetriebene Entwicklung und mochte es nicht. Wie beim Anarchismus finde ich, dass es in der Theorie großartig klingt, aber ich habe festgestellt, dass es meinen Entwicklungszyklus tatsächlich verlangsamt hat, als ich versuchte, ihn umzusetzen.

Mir gefällt jedoch immer noch die Idee, etwas über das Testen nachzudenken, bevor ich mit der Entwicklung eines Features fertig bin und mich für einen Prozess entschieden habe, der für mich gut zu funktionieren scheint und meine Entwicklung vorantreibt.

Ich verwende jetzt test.todo von Jest, um aufzuzeichnen, was ich testen werde, während ich ein Feature plane und ausbaue (Vielen Dank an Karl dafür, dass du mir die Idee zum ersten Mal vorgestellt hast!).

Mein üblicher Prozess läuft ein bisschen so ab. Zuerst erfasse ich die Anforderungen, die mein großartiger Product Owner (Hi Biz!) für mich formuliert hat im test.todo-Format, wie eine Todo-Liste. Wenn ich dann baue und auf andere Randfälle und wichtige Testbereiche stoße, füge ich diese auch als test.todo's hinzu. Auf diese Weise habe ich in Bezug auf die Testzeit vieles durchdacht, was ich testen werde, und es ist weniger wahrscheinlich, dass ich das Testen von Randfällen oder wichtigen funktionalen Anforderungen übersehe.

Ein einfaches Beispiel für ein test.todo für die folgende Komponente: <UserDetails />

importiere React aus „react“; Exportschnittstelle User {firstName: string; lastName: string; username: string; emailAddress: string; SEN: string;} Exportschnittstelle showHideUserDetailsProps {showDetails: boolean; user: user;} const userDetails = ({showDetails, user}: showHideUserDetailsProps) => (<> {showDetails? (<div><h1>Benutzerdetails</h1> <ul><li>{User.FirstName}</li> <li>{User.LastName}</li> <li>{user.username}</li> <li>{user.emailAddress}</li> <li>{user.SEN}</li></ul></div>): (<div><h1>Privacy Protected</h1></div>)} </>); Standard-Benutzerdetails exportieren;

Könnte wie folgt aussehen:

describe ('<UserDetails />', () => {test.todo ('Sollte Benutzerdetails anzeigen, wenn „Details anzeigen“ wahr ist'); test.todo ('Sollte KEINE Benutzerdetails anzeigen, wenn „Details anzeigen“ falsch ist');});

Hack 3: Builder-Funktionen verwenden

Früher habe ich für jeden Test Objekte erstellt, um Werte für das Testen nachzuahmen. Dann habe ich eine weitere Komponente geschrieben, die dasselbe Objekt verwendet hat, und es dort wieder verspottet. Es muss einen besseren Weg geben, dachte ich. Und Matt Smith von FinoComp hat mir einen vorgestellt.

Ich verwende jetzt Builder-Funktionen, die beim Testen häufig verwendete Objekttypen zurückgeben und es ermöglichen, Eigenschaften überall zu überschreiben. Es ist sicherlich ein bisschen mehr Zeit erforderlich, um sie einzurichten, aber ich finde, dass Sie, wenn sie einmal fertig sind, das nächste Mal, wenn Sie mit dem Objekt interagieren müssen, so froh sind, dass sie da sind.

//Beispiel für das Typinterface User {firstName: string; lastName: string; username: string; emailAddress: string; SEN: string;} interface showHideUserDetailsProps {showDetails: boolean; user: user;}//Builder-Muster zum Erstellen eines Scheinobjekts für den//showHideUserDetailsProps Typeexport const buildShowHideUserDetailsProps = (überschreibt? : Teilweise<ShowHideUserDetailsProps>): showHideUserDetailsProps => {const defaultShowHideUserDetailsProps = {showDetails: false, user: {firstname: „Jazmyne“, lastname: „Jacobs“, username: „Kylee_Skiles37", emailAddress:" Rashawn13@gmail.com „, SEN: „SEN-123456"}}; return {... defaultShowHideUserDetailsProps,... überschreibt};};

Dieses Muster weist jedoch einige Einschränkungen auf, da es bei tief verschachtelten Objekttypen weniger nützlich ist. Außerdem müssen sie gewartet werden, wenn sich Objekttypen in der Codebasis ändern, was mich zu meinem nächsten Punkt bringt...

Hack 4: Benutze ein Tool, um deine Typescript-Typen nachzuahmen

Schau, ich werde direkt herkommen. Das ist der Teil, in dem ich meine eigene Arbeit einfüge, aber wenigstens habe ich sie zum Schluss gelassen, oder?

Immer wenn ich ein anderes Scheinobjekt zum Testen erstellte, schaute ich mir meine Typescript-Typen an und dachte, kann sich das nicht etwas ansehen und für mich tun? Das hat mich auf die Suche nach einer Lösung geschickt und ich war so begeistert, sie zu finden Zwischenmatte welches ist ein Befehlszeilentool, das genau das tut. Es ist zwar noch in Arbeit und hat einige Einschränkungen, aber ich fand es sehr hilfreich beim Schreiben von Tests.

Ich fand es allerdings etwas umständlich, die Kombination aus CLI und Kopieren/Einfügen vom Terminal aus zu verwenden. Wie könnte ich das noch einfacher machen, dachte ich.

Gib meine VSCode-Erweiterung ein, Emulativ. Wählen Sie einfach Ihren Typnamen aus, führen Sie einen Befehl über die Befehlspalette in VSCode aus und Sie können Emulative verwenden, um Typescript-Objekte, Json-Objekte oder die oben genannten Builder-Funktionen aus Typescript-Typen zu erstellen. Diese werden automatisch in die Zwischenablage kopiert, aber die einfachen Objekte können auch in eine neue Scratch-Datei gesendet werden.

Aber warte, es gibt noch mehr! Wo ich arbeite Einfach und agil Wir haben eine Reihe von Eigenschaften, mit denen wir von Jira arbeiten, die nicht genau durch eine Zeichenfolge oder Zahl dargestellt werden. Mit Emulative können Sie Schlüssel/Wert-Paare einrichten, die alle passenden Eigenschaften, die in Ihren Typen enthalten sind, überschreiben.

Ein Lob an Easy Agile, dass sie mir während einer Inception Week die Zeit, die Ressourcen und die Ermutigung gegeben haben, an Emulative zu arbeiten!

Nun, das war's für mich. Ich hoffe, Sie finden einige dieser Tipps und Tricks nützlich, um Frontend-Tests zu beschleunigen.

In jedem Fall können Sie sich gerne in den Kommentaren über raffinierte Tricks äußern, die Sie gefunden haben, um Ihre Komponententestgeschwindigkeit zu verbessern (oder einfach, wie falsch ich in Bezug auf TDD liege).

Oder warum Sie Beispielvariablen aussagekräftige Namen geben sollten

Frustriert beugte ich mich über meinen Schreibtisch und unterdrückte den Drang zu schreien, um das rhythmische Klackern meiner Kollegen nicht zu stören. Ich war den ganzen Morgen über ein besonders fieses Problem beim unendlichen erneuten Rendern von React frustriert, das ich einfach nicht zum Laufen bringen konnte. Der Drang zu schreien kam, als ich mich, mein eigener Werkzeugkasten erschöpft, an Google wandte.

Sie sehen, es sah so aus, als wäre jemand anderes auf dasselbe Problem gestoßen und hätte beschlossen, eine Lösung für Wohlstand (und Internetpoints) aufzuzeichnen. Ich suchte eifrig auf der Seite nach dem Beispielcode, der mir den Morgen retten würde. Als ich ihn fand, wurde mein Blick auf den gefürchteten FooBarbaz gelenkt und ich wusste, dass mein Morgen noch viel schlimmer werden würde, bevor er besser wurde.

Ich liebe die Geschichte des Programmierens und die kleinen Ostereier, die andere Entwickler weitergegeben haben (mein persönlicher Favorit - Ich bin eine Teekanne). Diese tragen dazu bei, dass diese Arbeit mit Computern viel unterhaltsamer und menschlicher ist. Ich verstehe, dass die Verwendung von FooBarbaz bei der Benennung von Beispielfunktionen und Variablen eine lange und geschichtsträchtige Tradition hat, die mindestens bis in die Tech Model Railroad Club am MIT, um 1960. Ich erkenne an, dass die Verwendung von FooBarbaz in erster Linie nicht dazu dient, von dem, was gezeigt wird, ablenken zu lassen. Ich denke auch, dass wir so gut wie aufhören sollten, sie zu benutzen.

Ich bin immer wieder beeindruckt von der Menge an Informationen, die meine Entwicklerkollegen im Internet für mich weggelassen haben. So viele Menschen in diesem Bereich scheinen ein angeborenes Bedürfnis zu haben, anderen zu helfen, was dazu führt, dass sie unzählige Stunden investieren, um Stack Overflow und Blogs mit nützlichen Informationen zu füllen. Ich kann mir nur vorstellen, dass die Leute, die ihre Zeit und Mühe in dieses Ziel investieren, hoffen, dass ihre Bemühungen so vielen Menschen wie möglich helfen werden. fooBarbaz steht dem im Weg.

Lassen Sie mich für eine Sekunde meinen Entwicklerhut abnehmen und meinen kürzlich weggeworfenen, leicht unförmigen und angeschlagenen Psychologen-Hut aufsetzen. Das Verweben komplexer Fakten zu Geschichten ist eine bewährte Technik, die das Lernen erleichtert. Hier in Australien wurde die Technik wird seit Zehntausenden von Jahren von den Aborigines und den Torres Strait Islandern genutzt um ihnen zu helfen, sich wichtige und komplexe Informationen wie die Standorte von Wasserlöchern in weiten Teilen der unwirtlichen Wüste zu merken. Unser Gehirn besteht aus Netzwerken miteinander verbundener Neuronen. Es ist also wahrscheinlicher, dass wir an dem Gelernten festhalten, wenn wir in der Lage sind, neue Informationen in unsere aktuelle Wissensbasis zu integrieren. Der moderne Begriff dafür lautet assoziatives Lernen.

Darüber hinaus war es, wie Sie sich sicher aus der Schule erinnern werden, das Lernen interessant zu halten gezeigt ein starker Motivator zu sein, der das Lernen anregt.

Wenn wir uns all diese Zeit und Mühe nehmen, um mit unseren Entwicklerkollegen zu kommunizieren, können und sollten wir den Vorteil des assoziativen Lernens und der intrinsischen Motivation nutzen, um sicherzustellen, dass die Informationen, die wir veröffentlichen, für so viele Menschen wie möglich nützlich wie möglich sind. Deshalb glaube ich, dass wir bei der Erstellung von Beispielcode genauso viel über sinnvolle Benennungen nachdenken sollten wie in unseren eigenen Codebasen.

Marijn Haverbekes Beredtes Javascript steht regelmäßig an der Spitze Listen von Büchern, die Sie lesen sollten, wenn Sie Javascript lernen (JS). Es ist kein Zufall, dass er auch ein Meister darin ist, aussagekräftige Namen zu verwenden, um Menschen zu helfen, die Prinzipien der Codierung besser zu verstehen. Wenn er neuen Programmierern den Vergleich von Zeichenketten in JS beibringt, verwendet er das folgende Beispiel:

Marijn nutzt unser vorhandenes Wissen über Springfields Lieblings-Zeichentrickfiguren, um diesem Beispiel zusätzliche Bedeutung und Interesse zu verleihen. Wir wissen, dass Itchy und Scratchy jeweils eine Maus und eine Katze sind und daher definitiv nicht dasselbe sind.

Betrachten Sie dasselbe Beispiel, aber stattdessen mit dem gefürchteten Foo/Bar gerendert:

Für erfahrene Entwickler ist das vielleicht leicht zu analysieren: Sie haben Hunderte von Beispielen wie diesem gelesen und so den Zusammenhang zwischen Foo und Bar gelernt und verinnerlicht. Dies stellt jedoch eine Lernbarriere für neue Entwickler dar, die diese Regel noch nicht verinnerlicht haben, und erhöht stattdessen die mentale Belastung für sie, das Konzept zu verstehen. Es fehlt auch daran, den kleinen Funken von Interesse oder Freude zu erzeugen, um das Interesse der Leser zu wecken und so ihre Motivation zu steigern, das zugrundeliegende Konzept zu verstehen.

Ich sage nicht, dass FooBarbaz absolut keinen Platz hat (obwohl ich denke, dass ihr Nutzen begrenzt ist). Der beste Weg, diese Begriffe zu verwenden, besteht darin, zu betonen, dass alles an einem bestimmten Ort platziert werden kann. Ein Beispiel dafür ist, wenn wir über Argumente und Parameter in JS-Funktionen sprechen. Sie sehen, in Vanilla JS gibt es keine Typüberprüfung. Wenn wir also eine Funktion wie die folgende haben, die einen Parameter akzeptiert und seinen Wert einfach in der Konsole protokolliert, spielt es keine Rolle, welche Art von Argument wir übergeben:

Ich glaube, dass diese Begriffe in diesem Fall am nützlichsten sind, da sie betonen sollen, dass ihr Typ keine Rolle spielt. Ich möchte auch den Vorbehalt hinzufügen, dass die Verwendung dieser Begriffe auf diese Weise nur geeignet ist, wenn Sie Inhalte für erfahrene Entwickler produzieren, die sich ein funktionierendes Verständnis dieser Begriffe erarbeitet haben.

Auch wenn sich das an erfahrene Entwickler richtet, glaube ich immer noch, dass aussagekräftigere Namen in diesem Beispiel besser wären:

Ein anderes Beispiel, bei dem aussagekräftigere Variablennamen nützlich wären, bezieht sich auf metasyntaktische Variablen. Diese Variablen sind häufig im Quellcode zu finden und sollen vor der realen Verwendung geändert oder ersetzt werden. Diese Variablen sind zwar nur Platzhalter, aber ich glaube, dass es auch besser ist, einen Variablennamen zu verwenden, der Ihrem Entwicklerkollegen mehr Kontext bietet, um ihn beim Lesen und Implementieren des Codes in Zukunft zu unterstützen.

Wir arbeiten in einem wunderbaren Beruf mit einer reichen Geschichte, in dem viele Menschen bereit sind, ihre Zeit zu investieren, um ihre Programmiererkollegen auszubilden und zu betreuen. Die Verwendung aussagekräftiger Variablennamen anstelle von fooBarbaz ist eine Möglichkeit, sicherzustellen, dass sich dieser Aufwand lohnt und so vielen Menschen wie möglich hilft. Es senkt die Zugangsbarrieren für den Beruf und trägt zur Schaffung eines vielfältiger und eine freundliche Programmiergemeinschaft.

Also lass den FooBarbaz fallen (aber nicht den Teekanne) und geh raus und entfacht Freude!