Webentwicklung mit Node und Express, 2. Auflage

Kapitel 4. Aufräumen

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

In den beiden vorangegangenen Kapiteln haben wir nur experimentiert: Wir haben sozusagen unsere Zehen ins Wasser getaucht. Bevor wir zu komplexeren Funktionen übergehen, werden wir ein wenig Ordnung schaffen und einige gute Gewohnheiten in unsere Arbeit einbauen.

In diesem Kapitel beginnen wir ernsthaft mit unserem Meadowlark Travel Projekt. Bevor wir jedoch mit der Erstellung der Website beginnen, müssen wir sicherstellen, dass wir die Werkzeuge haben, die wir brauchen, um ein hochwertiges Produkt zu erstellen.

Tipp

Das laufende Beispiel in diesem Buch ist nicht unbedingt eines, dem du folgen musst. Wenn du deine eigene Website erstellen willst, kannst dudich an das laufende Beispielhalten, es aber entsprechend abändern, sodass du am Ende dieses Buches eine fertige Website hast !

Datei- und Verzeichnisstruktur

Die Strukturierung von Bewerbungen hat schon viele religiöse Debatten ausgelöst, und es gibt nicht den einen richtigen Weg, es zu tun. Es gibt jedoch einige allgemeine Konventionen, die man kennen sollte.

Es ist üblich, die Anzahl der Dateien im Stammverzeichnis deines Projekts zu begrenzen. Normalerweise findest du dort Konfigurationsdateien (wie package.json), eineREADME.md-Datei und eine Reihe von Verzeichnissen. Der meiste Quellcode befindet sich in einem Verzeichnis, das oft src genannt wird. Der Kürze halber werden wir diese Konvention in diesem Buch nicht verwenden (überraschenderweise tut dies auch die Express-Anwendung nicht). In realen Projekten wirst du wahrscheinlich irgendwann feststellen, dass das Stammverzeichnis deines Projekts unübersichtlich wird, wenn du dort Quellcode ablegst, und du wirst diese Dateien in einem Verzeichnis wie src sammeln wollen.

Ich habe auch schon erwähnt, dass ich meine Hauptanwendungsdatei (manchmal auch Einstiegspunkt genannt) lieber nach dem Projekt selbst benenne(meadowlark.js), als nach etwas Allgemeinem wie index.js,app.js oder server.js.

Es liegt weitgehend an dir, wie du deine Anwendung strukturierst, und ich empfehle, in der Datei README.md (oder in einem von ihr verlinkten Readme) einen Fahrplan für deine Struktur zu erstellen.

Ich empfehle, dass du mindestens die folgenden zwei Dateien in deinem Projektstamm hast: package.json und README.md. Der Rest ist deiner Fantasie überlassen.

Bewährte Methoden

Der Begriff der bewährten Methoden wird heutzutage oft verwendet und bedeutet, dass man "alles richtig machen" und nicht an der falschen Stelle sparen soll (wir werden gleich darauf eingehen, was das genau bedeutet). Sicherlich hast du schon einmal das Sprichwort gehört, dass es die Optionen "schnell", "billig" und "gut" gibt, und du dir zwei davon aussuchen kannst. Was mich an diesem Modell schon immer gestört hat, ist die Tatsache, dass es nicht berücksichtigt, dasssich der Wert von Dingen, dieman richtig macht,aufbaut. Wenn du etwas zum ersten Mal richtig machst, kann es fünfmal so lange dauern, wie wenn du es schnell und schmutzig machen würdest. Beim zweiten Mal dauert es aber nur noch dreimal so lange. Wenn du es dann ein Dutzend Mal richtig gemacht hast, bist du fast genauso schnell wie bei der schmutzigen Methode.

Mein Fechttrainer hat uns immer daran erinnert, dass nicht Übung den Meister macht, sondern Übung macht dauerhaft. Das heißt, wenn du etwas immer und immer wieder machst, wird es irgendwann automatisch, auswendig. Das stimmt zwar, aber es sagt nichts über die Qualität der Sache aus, die du übst. Wenn du schlechte Gewohnheiten praktizierst, werden sie zur Gewohnheit. Stattdessen solltest du die Regel befolgen, dass perfektes Üben perfekt macht. In diesem Sinne ermutige ich dich, die restlichen Beispiele in diesem Buch so zu befolgen, als würdest du eine echte Website erstellen, als würden dein Ruf und dein Gehalt von der Qualität des Ergebnisses abhängen. Nutze dieses Buch nicht nur, um neue Fähigkeiten zu erlernen, sondern auch, um dir gute Gewohnheiten anzueignen.

Die Praktiken, auf die wir uns konzentrieren werden, sind Versionskontrolle und QS. In diesem Kapitel geht es um die Versionskontrolle und im nächsten Kapitel um die Qualitätssicherung.

Versionskontrolle

Ich hoffe, ich muss dich nicht von den Vorteilen der Versionskontrolle überzeugen (dafür bräuchte man ein ganzes Buch). Im Großen und Ganzen bietet die Versionskontrolle diese Vorteile:

Dokumentation

Wenn du die Geschichte eines Projekts zurückverfolgen kannst, um zu sehen, welche Entscheidungen getroffen wurden und in welcher Reihenfolge die Komponenten entwickelt wurden, kann das eine wertvolle Dokumentation sein. Eine technische Historie deines Projekts kann sehr nützlich sein.

Zuschreibung

Wenn du in einem Team arbeitest, kann die Zuordnung von Änderungen sehr wichtig sein. Wenn du im Code etwas findest, das undurchsichtig oder fragwürdig ist, kann es dir viele Stunden ersparen, wenn du weißt, wer die Änderung vorgenommen hat. Es kann sein, dass die Kommentare zur Änderung ausreichen, um deine Fragen zu beantworten, und wenn nicht, weißt du, mit wem du reden musst.

Experimentieren

Eine gute Versionskontrolle ermöglicht es dir, zu experimentieren und etwas Neues auszuprobieren, ohne Angst haben zu müssen, dass die Stabilität deines Projekts beeinträchtigt wird. Wenn das Experiment erfolgreich ist, kannst du es wieder in das Projekt integrieren, und wenn es nicht erfolgreich ist, kannst du es aufgeben.

Vor Jahren habe ich auf verteilte Versionskontrollsysteme (DVCS) umgestellt. Ich habe mich für Git und Mercurial entschieden, weil Git so weit verbreitet und flexibel ist. Beides sind ausgezeichnete und kostenlose Versionskontrollsysteme, und ich empfehle dir, eines von ihnen zu benutzen. In diesem Buch werden wir Git verwenden, aber du kannst auch Mercurial (oder ein anderes Versionskontrollsystem) benutzen.

Wenn du mit Git noch nicht vertraut bist, empfehle ich dir Jon Loeligers ausgezeichnetes BuchVersionskontrolle mit Git(O'Reilly). Außerdem gibt es auf GitHub eine gute Liste von Git-Lernressourcen.

Wie du Git mit diesem Buch verwendest

Stelle zunächst sicher, dass du Git hast. Gib git --version ein. Wenn du keine Versionsnummer erhältst, musst du Git installieren. In derGit-Dokumentation findest du Anweisungen zur Installation .

Es gibt zwei Möglichkeiten, den Beispielen in diesem Buch zu folgen. Die eine ist, die Beispiele selbst abzutippen und den Git-Befehlen zu folgen. Die andere ist, das Companion Repository, das ich für alle Beispiele verwende, zu klonen und die zugehörigen Dateien für jedes Beispiel zu überprüfen. Manche Menschen lernen besser, wenn sie die Beispiele abtippen, während andere es vorziehen, die Änderungen einfach zu sehen und auszuführen, ohne alles abtippen zu müssen.

Wenn du selbst mitmachst

Wir haben bereits ein sehr grobes Gerüst für unser Projekt: einige Ansichten, ein Layout, ein Logo, eine Hauptanwendungsdatei und eine package.json-Datei. Legen wir ein Git-Repository an und fügen wir all diese Dateien hinzu.

Zuerst gehen wir in das Projektverzeichnis und richten dort ein Git-Repository ein:

git init

Bevor wir nun alle Dateien hinzufügen, erstellen wir eine .gitignore-Datei, um zu verhindern, dass wir versehentlich Dinge hinzufügen, die wir nicht hinzufügen wollen. Erstelle in deinem Projektverzeichnis eine Textdatei namens .gitignore, in der du alle Dateien oder Verzeichnisse hinzufügen kannst, die Git standardmäßig ignorieren soll (eine pro Zeile). Sie unterstützt auch Platzhalter. Wenn dein Editor zum Beispiel Sicherungsdateien mit einer Tilde am Ende erstellt (wie meadowlark.js~), kannst du *~ in die .gitignore-Datei eintragen. Wenn du einen Mac verwendest, solltest du .DS_Store einfügen. Außerdem solltest du dort node_modules einfügen (aus Gründen, die wir gleich besprechen werden). Im Moment könnte die Datei also so aussehen:

node_modules
*~
.DS_Store

Hinweis

Die Einträge in der Datei .gitignore gelten auch für Unterverzeichnisse. Wenn du also *~ in die .gitignore-Datei im Stammverzeichnis des Projekts einträgst, werden alle solchen Sicherungsdateien ignoriert, auch wenn sie sich in Unterverzeichnissen befinden.

Jetzt können wir alle unsere bestehenden Dateien hinzufügen. Es gibt viele Möglichkeiten, dies in Git zu tun. Ich bevorzuge im Allgemeinen git add -A, die die umfangreichste aller Varianten ist. Wenn du Git noch nicht kennst, empfehle ich dir, entweder eine Datei nach der anderen hinzuzufügen (z. B.git add meadowlark.js), wenn du nur eine oder zwei Dateien übertragen willst, oder alle deine Änderungen (einschließlich der Dateien, die du eventuell gelöscht hast) mit git add -A hinzuzufügen. Da wir die gesamte Arbeit, die wir bereits geleistet haben, hinzufügen wollen, verwenden wir die folgende Methode:

git add -A

Tipp

Git-Neulinge werden häufig durch denBefehl git addverwirrt: Er fügt Änderungen hinzu, keine Dateien. Wenn du also die Datei meadowlark.js geändert hast und dann git add meadowlark.js eingibst, fügst du in Wirklichkeit nur die Änderungen hinzu, die du vorgenommen hast.

Git hat eine "Staging Area", in die Änderungen gelangen, wenn du git add aufrufst. Die Änderungen, die wir hinzugefügt haben, sind also noch nicht übertragen worden, aber sie sind bereit zum Einsatz. Um die Änderungen zu übertragen, verwende git commit:

git commit -m "Initial commit."

Auf -m "Initial commit." kannst du eine Nachricht zu diesem Commit schreiben. Git lässt dich nicht einmal einen Commit ohne Nachricht machen, und das aus gutem Grund. Bemühe dich immer um aussagekräftige Commit-Nachrichten; sie sollten kurz, aber prägnant die Arbeit beschreiben, die du getan hast.

Wenn du über das offizielle Repository mitverfolgst

Um das offizielle Repository für dieses Buch zu erhalten, führe git clone aus:

git clone https://github.com/EthanRBrown/web-development-with-node-and-express-2e

In diesem Repository gibt es für jedes Kapitel ein Verzeichnis, das Codebeispiele enthält. Den Quellcode für dieses Kapitel findest du zum Beispiel im Verzeichnisch04. Die Codebeispiele in den einzelnen Kapiteln sind in der Regel nummeriert, um das Nachschlagen zu erleichtern. Im gesamten Repository habe ich großzügigREADME.md-Dateien mit zusätzlichen Hinweisen zu den Beispielen hinzugefügt.

Hinweis

In der ersten Version dieses Buches habe ich einen anderen Ansatz für das Repository gewählt, mit einem linearen Verlauf, als ob du ein immer anspruchsvolleres Projekt entwickeln würdest. Dieser Ansatz spiegelte zwar auf angenehme Weise die Art und Weise wider, wie sich ein Projekt in der realen Welt entwickeln könnte, bereitete aber sowohl mir als auch meinen Lesern viel Kopfzerbrechen. Wenn sich npm-Pakete änderten, änderten sich auch die Codebeispiele, und wenn man nicht die gesamte Geschichte des Repositorys neu schreiben wollte, gab es keine gute Möglichkeit, das Repository zu aktualisieren oder die Änderungen im Text zu vermerken. Der Ansatz "Kapitel pro Verzeichnis" ist zwar etwas künstlich, aber er ermöglicht es, den Text besser mit dem Repository zu synchronisieren und die Beiträge der Community zu erleichtern.

Wenn dieses Buch aktualisiert und verbessert wird, wird auch das Repository aktualisiert. Wenn das der Fall ist, füge ich ein Versions-Tag hinzu, damit du die Version des Repositorys auschecken kannst, die der Version des Buches entspricht, das du gerade liest. Die aktuelle Version des Projektarchivs ist 2.0.0. Ich halte mich hier grob an die Prinzipien der semantischen Versionierung (mehr dazu später in diesem Kapitel); das PATCH-Inkrement (die letzte Zahl) steht für kleinere Änderungen, die sich nicht auf deine Fähigkeit auswirken sollten, dem Buch zu folgen. Das heißt, wenn das Projektarchiv die Version 2.0.15 hat, sollte das noch mit dieser Version des Buches übereinstimmen. Wenn das MINOR-Inkrement (die zweite Zahl) jedoch anders ist (2.1.0), bedeutet das, dass der Inhalt des Begleitdokuments möglicherweise von dem abweicht, was du gerade liest, und du solltest dir einen Tag aussuchen, der mit 2.0 beginnt.

Das Companion Repo macht großzügig Gebrauch von README.md-Dateien, um zusätzliche Erklärungen zu den Codebeispielen hinzuzufügen.

Hinweis

Wenn du zu irgendeinem Zeitpunkt experimentieren möchtest, solltest du daran denken, dass du dich mit dem ausgecheckten Tag in einem Zustand befindest, den Git "detached HEAD" nennt. Du kannst zwar alle Dateien bearbeiten, aber es ist unsicher, etwas zu übertragen, ohne vorher einen Zweig zu erstellen. Wenn du also einen experimentellen Zweig auf der Grundlage eines Tags erstellen willst, musst du einfach einen neuen Zweig erstellen und ihn auschecken: git checkout -b experiment ( experiment ist der Name deines Zweigs; du kannst jeden beliebigen Namen verwenden). Dann kannst du diesen Zweig so oft bearbeiten und übertragen, wie du willst.

npm-Pakete

Die npm-Pakete, auf die dein Projekt angewiesen ist, befinden sich in einem Verzeichnis namensnode_modules. (Leider heißt es node_modules und nicht npm_packages, denn Node-Module sind ein verwandtes, aber anderes Konzept). Du kannst dieses Verzeichnis gerne durchsuchen, um deine Neugier zu befriedigen oder dein Programm zu debuggen, aber du solltest niemals den Code in diesem Verzeichnis verändern. Abgesehen davon, dass dies eine schlechte Praxis ist, können alle deine Änderungen von npm leicht wieder rückgängig gemacht werden.

Wenn du ein Paket ändern musst, von dem dein Projekt abhängt, ist es am besten, wenn du einen eigenen Fork des Pakets erstellst. Wenn du diesen Weg wählst und das Gefühl hast, dass deine Verbesserungen für andere nützlich sind, herzlichen Glückwunsch: Du bist jetzt an einem Open-Source-Projekt beteiligt! Du kannst deine Änderungen einreichen, und wenn sie den Projektstandards entsprechen, werden sie in das offizielle Paket aufgenommen. Zu bestehenden Paketen beizutragen und angepasste Builds zu erstellen, würde den Rahmen dieses Buches sprengen, aber es gibt eine lebendige Gemeinschaft von Entwicklern, die dir helfen, wenn du zu bestehenden Paketen beitragen möchtest.

Zwei der Hauptzwecke der package.json-Datei sind die Beschreibung deines Projekts und die Auflistung seiner Abhängigkeiten. Sieh dir jetzt deinepackage.json Datei an. Sie sollte in etwa so aussehen (die genauen Versionsnummern werden sich wahrscheinlich unterscheiden, da diese Pakete häufig aktualisiert werden):

{
  "dependencies": {
    "express": "^4.16.4",
    "express-handlebars": "^3.0.0"
  }
}

Im Moment enthält unsere package.json-Datei nur Informationen über Abhängigkeiten. Das Caret (^) vor den Paketversionen bedeutet, dass jede Version, die mit der angegebenen Versionsnummer beginnt, bis zur nächsten Hauptversionsnummer funktioniert. Diese package.jsonzeigt zum Beispiel an, dass jede Version von Express, die mit 4.0.0 beginnt, funktioniert. 4.0.1 und 4.9.9 würden also beide funktionieren, aber 3.4.7 nicht und auch nicht 5.0.0. Dies ist die Standardversion, wenn du npm install verwendest, und ist im Allgemeinen eine ziemlich sichere Sache. Das hat zur Folge, dass du die Datei bearbeiten musst, um die neue Version anzugeben, wenn du auf eine neuere Version umsteigen willst. Im Allgemeinen ist das eine gute Sache, denn es verhindert, dass Änderungen in den Abhängigkeiten dein Projekt zerstören, ohne dass du davon weißt. Die Versionsnummern in npm werden von einer Komponente namenssemver (für "semantische Versionierung") analysiert. Wenn du mehr über die Versionskontrolle in npm wissen willst, schau dir dieSemantic Versioning Specification und diesen Artikel von Tamas Piros an.

Hinweis

In der Spezifikation für semantische Versionierung heißt es, dass Software, die semantische Versionierung verwendet, eine "öffentliche API" deklarieren muss. Ich habe diese Formulierung immer als verwirrend empfunden; was sie wirklich bedeutet, ist: "Jemand muss sich um die Schnittstelle zu deiner Software kümmern." Wenn du das im weitesten Sinne verstehst, kann es wirklich alles bedeuten. Lasst euch also nicht von diesem Teil der Spezifikation irritieren; die wichtigen Details stehen im Format.

Da die Datei package.json alle Abhängigkeiten auflistet, ist das Verzeichnisnode_modules eigentlich ein abgeleitetes Artefakt. Das heißt, wenn du es löschen würdest, müsstest du nur npm install ausführen, um das Projekt wieder zum Laufen zu bringen. Dadurch wird das Verzeichnis neu erstellt und alle notwendigen Abhängigkeiten darin abgelegt. Aus diesem Grund empfehle ich dir, node_modules in deine .gitignore-Datei aufzunehmen und sie nicht in die Versionskontrolle zu integrieren. Manche Leute sind jedoch der Meinung, dass dein Repository alles Notwendige enthalten sollte, um das Projekt zu betreiben, und ziehen es vor, node_modules in der Versionskontrolle zu behalten. Ich finde, dass dies "Lärm" im Projektarchiv ist, und lasse es lieber weg.

Hinweis

Ab der Version 5 von npm wird eine zusätzliche Datei, package-lock.json, erstellt. Während package.json die Versionen der Abhängigkeiten "locker" angeben kann (mit den Modifikatoren ^ und ~ ), zeichnetpackage-lock.json die genauen Versionen auf, die installiert wurden, was hilfreich sein kann, wenn du die genauen Versionen der Abhängigkeiten in deinem Projekt neu erstellen musst. Ich empfehle dir, diese Datei in die Versionskontrolle einzuchecken und sie nicht von Hand zu ändern. Weitere Informationen findest du in derpackage-lock.jsonDokumentation.

Projekt-Metadaten

Der andere Zweck der Datei package.json ist die Speicherung von Projekt-Metadaten, wie z. B. der Name des Projekts, die Autoren, die Lizenzinformationen und so weiter. Wenn du npm init verwendest, um deine package.json-Dateizu erstellen, füllt es die Datei mit den notwendigen Feldern für dich aus und du kannst sie jederzeit aktualisieren. Wenn du dein Projekt auf npm oder GitHub zur Verfügung stellen willst, sind diese Metadaten sehr wichtig. Weitere Informationen zu den Feldern in package.json findest du in derpackage.json Dokumentation. Ein weiterer wichtiger Teil der Metadaten ist die Datei README.md. In dieser Datei kannst du die allgemeine Architektur der Website sowie alle wichtigen Informationen beschreiben, die jemand, der neu in das Projekt einsteigt, benötigen könnte. Sie ist in einem textbasierten Wiki-Format namens Markdown verfasst. Weitere Informationen findest du in derMarkdown-Dokumentation.

Knoten-Module

Wie bereits erwähnt, sind Node-Module und npm-Pakete verwandte, aber unterschiedliche Konzepte. Node-Module bieten, wie der Name schon sagt, einen Mechanismus zur Modularisierung und Kapselung. npm-Paketebieten ein standardisiertes Schema zur Speicherung, Versionierung und Referenzierung von Projekten (die nicht auf Module beschränkt sind). Wir importieren zum Beispiel Express selbst als Modul in unsere Hauptanwendungsdatei:

const express = require('express')

require ist eine Node-Funktion zum Importieren eines Moduls. Standardmäßig sucht Node nach Modulen im Verzeichnis node_modules (es sollte also nicht überraschen, dass es innerhalb von node_modules ein Verzeichnis express gibt). Node bietet aber auch einen Mechanismus, mit dem du deine eigenen Module erstellen kannst (du solltest niemals deine eigenen Module im Verzeichnis node_modules erstellen). Zusätzlich zu den Modulen, die über einen Paketmanager in node_modules installiert werden, gibt es mehr als 30 "Kernmodule", die von Node bereitgestellt werden, wie , , und . Die ganze Liste findest du fs http os pathin dieser aufschlussreichen Stack Overflow-Frage und in deroffiziellen Node-Dokumentation.

Schauen wir uns an, wie wir die Glückskeks-Funktionalität, die wir im vorherigen Kapitel implementiert haben, modularisieren können.

Zuerst erstellen wir ein Verzeichnis, in dem wir unsere Module speichern. Du kannst es nennen, wie du willst, aber lib (kurz für "library") ist eine gängige Wahl. Erstelle in diesem Ordner eine Datei namens fortune.js(ch04/lib/fortune.js im Companion Repo):

const fortuneCookies = [
  "Conquer your fears or they will conquer you.",
  "Rivers need springs.",
  "Do not fear what you don't know.",
  "You will have a pleasant surprise.",
  "Whenever possible, keep it simple.",
]

exports.getFortune = () => {
  const idx = Math.floor(Math.random()*fortuneCookies.length)
  return fortuneCookies[idx]
}

Wichtig ist hier die Verwendung der globalen Variableexports. Wenn du willst, dass etwas außerhalb des Moduls sichtbar ist, musst du es zuexports hinzufügen. In diesem Beispiel ist die Funktion getFortune außerhalb des Moduls verfügbar, aber unser Array fortuneCookies bleibt komplett verborgen. Das ist eine gute Sache: Kapselung ermöglicht weniger fehleranfälligen und fragilen Code.

Hinweis

Es gibt mehrere Möglichkeiten, Funktionen aus einem Modul zu exportieren. Wir werden im Laufe des Buches verschiedene Methoden behandeln und sie in Kapitel 22 zusammenfassen.

In meadowlark.js können wir nun das Array fortuneCookies entfernen (obwohl es nicht schaden würde, es beizubehalten; es kann in keiner Weise mit dem gleichnamigen Array in lib/fortune.js in Konflikt geraten). Es ist üblich (aber nicht erforderlich), Importe am Anfang der Datei anzugeben. Füge also am Anfang der Datei meadowlark.js die folgende Zeile hinzu(ch04/meadowlark.js im Companion Repo):

const fortune = require('./lib/fortune')

Beachte, dass wir unserem Modulnamen das Präfix ./ voranstellen. Das signalisiert Node, dass es nicht im Verzeichnis node_modules nach dem Modul suchen soll; wenn wir das Präfix weglassen würden, würde es fehlschlagen.

Jetzt können wir in unserer Route für die Info-Seite die Methode getFortune aus unserem Modul verwenden:

app.get('/about', (req, res) => {
  res.render('about', { fortune: fortune.getFortune() } )
})

Wenn du mitkommst, lass uns die Änderungen übertragen:

git add -A git commit -m "Moved 'fortune cookie' into module."

Du wirst feststellen, dass Module eine leistungsstarke und einfache Möglichkeit sind, Funktionen zu kapseln, die das Gesamtdesign und die Wartbarkeit deines Projekts verbessern und das Testen erleichtern. Weitere Informationen findest du in deroffiziellen Node-Modul-Dokumentation .

Hinweis

Node-Module werden manchmal auch CommonJS (CJS)-Module genannt, in Anlehnung an eine ältere Spezifikation, von der sich Node inspirieren ließ. Die JavaScript-Sprache führt einen offiziellen Paketierungsmechanismus ein, der ECMAScript Modules (ESM) genannt wird. Wenn du JavaScript in React oder einer anderen progressiven Frontend-Sprache schreibst, bist du vielleicht schon mit ESM vertraut, das import und export (anstelle von exports, module.exports undrequire) verwendet. Weitere Informationen findest du in Dr. Axel Rauschmayers Blogbeitrag"ECMAScript 6 modules: the final syntax".

Fazit

Jetzt, da wir mehr über Git, npm und Module wissen, können wir darüber sprechen, wie wir ein besseres Produkt herstellen können, indem wir gute Qualitätssicherungspraktiken bei der Programmierung anwenden.

Ich möchte dich ermutigen, die folgenden Lektionen aus diesem Kapitel im Kopf zu behalten:

• Die Versionskontrolle macht den Softwareentwicklungsprozess sicherer und berechenbarer. Ich möchte dich ermutigen, sie auch bei kleinen Projekten einzusetzen, denn sie schafft gute Gewohnheiten!

• Modularisierung ist eine wichtige Technik, um die Komplexität von Software zu beherrschen. npm bietet nicht nur ein reichhaltiges Ökosystem von Modulen, die andere entwickelt haben, sondern du kannst auch deinen eigenen Code in Module verpacken, um dein Projekt besser zu organisieren.

• Node-Module (auch CJS genannt) verwenden eine andere Syntax als ECMAScript-Module (ESM) und du musst eventuell zwischen den beiden Syntaxen wechseln, wenn du zwischen Frontend- und Backend-Code wechselst. Es ist eine gute Idee, mit beiden vertraut zu sein.