Zwölf einfache anfängliche Modulentwicklungsschritte für Node.js

  • Tutorial
[Aristoteles]"Der Anfang ist mehr als die Hälfte von allem."

Dies ist ein sehr altes GTD- Prinzip: Es ist wahrscheinlich Tausende von Jahren alt. (Zum Beispiel schreibt Wikiquote es derzeit Aristoteles zu, obwohl es keine Beweise für die Quelle enthält.) Das Wesentliche ist, ein Projekt von Grund auf neu zu startenes ist sehr schwierig (und du musst dich selbst zwingen); Aber wenn es ein paar einfache erste Schritte gibt, deren Umsetzung zum Erscheinen eines teilweise abgeschlossenen Projekts führt, wird es viel einfacher, „durch Trägheit“ daran weiterzuarbeiten - so einfach, als ob dieses Projekt bereits gestartet, aber auch noch mehr fertig wäre als die Hälfte. Und außerdem ist es schwierig, einen Fehler zu machen, wenn Sie im Voraus wissen, wie die ersten Schritte aussehen sollten.

Ich hatte die Möglichkeit, mehr als ein Dutzend Module für Open Source Node.js zu komponieren und als npm-Pakete zu veröffentlichen. Je mehr Module ich gemacht habe, desto mehr wurde mir klar (auch durch Ausprobieren), dass die ersten Schritte zu ihrer Erstellung dieselben und sogar in derselben Reihenfolge ausgeführt werden können. Heute veröffentliche ich diesen Befehl in der Hoffnung, dass er den Programmierern beim Schreiben ihres JavaScript-Codes für die Node-Engine helfen wird.

Bitte beachten Sie, dass jeder dieser Schritte sehr einfach und logisch ist.

Schritt 1. Den Namen und das Repository des npm-Pakets erfinden


Ohne einen Namen wird nichts funktionieren. Ohne einen Namen für Ihr Projekt können Sie weder auf dem github noch auf dem npm-Paket ein Repository dafür erstellen.

Stellen Sie sicher, dass der Name des npm-Pakets nicht bereits im Voraus vergeben wurde. (Hier ein Beispiel: Wenn Sie sich im Herbst dazu entschließen, Ihr Paket "Herbst" oder "Herbst" zu nennen, besuchen Sie https://www.npmjs.org/package/autumn und https://www.npmjs.org/package/fall without of labour wird Sie davon überzeugen, dass es bereits npm-Pakete mit solchen Namen gibt.)

Wenn der Name Ihres npm-Pakets ein einfaches Wort oder ein bekannter technischer Begriff ist, sollten Sie das Präfix „node-“ hinzufügen , um um den Namen des Repositorys zu erhalten. (Zum Beispiel Paketcodesqlite3 wird im node-sqlite3-Repository gespeichert , und der Code des geöffneten Pakets wird im node-open- Repository gespeichert .) Dieser Zusatz dient dem Komfort von Programmierern, die an gleichnamigen Projekten in anderen Programmiersprachen arbeiten. (Wenn beispielsweise jemand bereits ein Projekt mit dem Namen "open" in Rust, Ruby oder Python hat, können er und das Node-Open- Repository die Auswahl aufheben und die Konsequenzen eines Namenskonflikts nicht feststellen.)

Wird es kurz sein Ist Ihr Paketname npm oder lang? Wenn es kurz ist, ist es einfacher, es manuell einzugeben (z. B. in der Befehlszeile nach " npm install ").und wenn es lang ist, kopieren sie es und fügen es ein (diese Aktion erfolgt genauer, aber länger - und wird daher als weniger bequem empfunden). Beachten Sie auch, dass die Site nodei.co solche Histogramme mit Statistiken zu Downloads des Pakets npm erstellt, deren Breite von der Länge des Paketnamens abhängt (sodass der gesamte Name auf das Histogramm passen kann). Hier zwei Beispiele:

[Histogramm Nummer 1: uue]

[Histogramm Nr. 2: Fidonet-Marmelade]

Bei Modulen mit zu langen Namen kann eine Vergrößerung der Breite eines solchen Histogramms dazu führen (und wird es sicherlich auch bewirken!), Dass Statistiken in einer separaten Zeile und nicht rechts oder links von anderen Bildern platziert werden müssen, wenn Sie mit der Erstellung einer Zusammenfassung beginnen Informationen zu seinem Modul - sogar so einfach wie README auf Github.

Schritt 2. Eine kurze Beschreibung erfinden


Eine kurze Beschreibung ist hilfreich, wenn Sie ein Projekt in Github und später erstellen (z. B. wenn Sie das Beschreibungsfeld in der Datei package.json ausfüllen ).

Es ist am besten, nur einen kurzen Satz zu schreiben, der beschreibt, was Ihr Modul macht. Es erleichtert die Durchsuchbarkeit und begleitet den Namen des Pakets oder des Repositorys auf vielen Websites mit Hyperlinks. Wenn Sie die Beschreibung zu lang machen, passt sie nicht auf die Karte bei Twitter (und auf andere Websites, die die Beschreibung in der Länge zuschneiden). Darüber hinaus wird die Öffentlichkeit das Lesen der Listen, auch wenn es passt, immer noch nicht zu Ende führen.

Schritt 3. Erstellen eines Github-Repositorys mit einer automatisch ausgefüllten README-Datei.


In der Regel werden Knotenmodul-Repositorys auf dem Github erstellt. Ich habe Ausnahmen von dieser Regel festgestellt, aber selten. Daher werde ich hier alle Schritte auf der Basis von Github und Git erläutern und Lesern von anderen DVCS-Benutzern und / oder anderen Open-Source-Hosting-Anbietern die Möglichkeit geben, diese Schritte für sich selbst anzupassen: Dies ist kein heikles Geschäft.

Auf der Seite https://github.com/new schlagen sie vor, den Namen und die Beschreibung des Repository auszufüllen (Sie könnten sich beide in den vorherigen beiden Schritten einfallen lassen) sowie automatisch eine README- Datei (Projektbeschreibung) zu erstellen , eine Datei mit dem Lizenztext (um anzugeben) wie offen Ihr Code ist) und die .gitignore- Datei(um keine unnötigen temporären Hilfs-Junk-Dateien in das Repository hochzuladen).

Wenn sich von Anfang an mindestens eine Datei im Github-Repository befindet, können Sie das Repository einfach klonen (z. B. mit dem Befehl git clone “). Dies ist schneller und einfacher (etwa eineinhalb oder sogar zweimal) als das lokale Repository zu initialisieren ( Zum Beispiel mit dem Befehl git init “) und dann mit den Händen in den Einstellungen die Adresse des Github-Repositorys als Ursprung registrieren .

Die von Github automatisch übermittelte Lizenzdatei muss jedoch häufig für sich selbst bearbeitet werden (geben Sie beispielsweise anstelle des Github-Anmeldenamens Ihren vollständigen Namen oder den Namen der Organisation an) und sogar automatisch übermittelt werden.gitignore Sie möchten möglicherweise auch etwas hinzufügen , das Ihrer Vorstellung entspricht, welche Dateien im Repository nicht benötigt werden. Wenn Sie also nicht das erste Knotenmodul in Ihrem Leben erstellen, sollten Sie sich auf die automatische Erstellung der README-Datei beschränken unddieLizenz und die .gitignore-Datei in der fertigen Form von einem Ihrer vorherigen Module kopieren. Machen Sie dasselbesie wieder (wenn auch nicht von Null, sondern aus den Ergebnissen githabovskoy automatische Generierung) - diese Muda (無駄, zusätzliche Arbeit) und vergeblich unübersichtlich die SeiteGeschichte.

Vergessen Sie nach dem Erstellen des Repositorys auf Github nicht, alle Änderungen an den Repository-Einstellungen vorzunehmen, die Sie für erforderlich halten. Wenn zum Beispiel nur wenig Zeit zur Verfügung steht und Sie daher keine Zeit haben, die Wikis im Auge zu behalten, können Sie die Wiki-Unterstützung im Repository deaktivieren. Wenn Sie es beispielsweise gewohnt sind, in der Liste "Markiert" (in der Liste der mit Sternen gekennzeichneten Repositorys) nicht nur einige andere Repositorys, sondern auch alle Ihre Repositorys anzuzeigen, können Sie den ersten Stern sofort in das neu erstellte Repository einfügen.

Schritt 4. Hinzufügen einer Textdatei mit einer Lizenz


С этим шагом лучше всего не затягивать: чем раньше вы дадите понять, под какою лицензией распространяются все последующие правки, тем лучше.

Как я и говорил на предыдущем шаге, если вы создаёте не первый модуль Node в своей жизни, то можно скопировать файл LICENSE из другого модуля, подправить при необходимости год в тексте — и можно коммитить.

Если же вы в первый раз принимаете решение о том, под какой лицензией распространять свой открытый исходный код, то можете последовать примеру сообщества (а в сообществе Node.js, насколько я могу судить, лицензия MIT наиболее популярна, хотя встречаются и исключения из этого правила), или проконсультироваться с сайтом choosealicense.com, или и то, и другое вместе.

Schritt 5. Hinzufügen von .gitignore- und .npmignore-Dateien .


Wie Sie wissen, listet die .gitignore- Datei die Namen der Dateien und Verzeichnisse auf, die sich nicht im Git-Repository befinden sollten, da sie es nur vergeblich überladen würden. Hierzu zählen in der Regel Archive und Distributionen des Projekts, Protokolle, Datenbanken, Hilfsdateien des Betriebssystems (zum Beispiel das Speichern von Thumbnails von Bildern in einem bestimmten Unterverzeichnis).

Wenn Sie ein Projekt entwickeln, in dem ein oder mehrere Knotenmodule als Abhängigkeiten verwendet werden, empfiehlt es sich , der .gitignore-Datei den Verzeichnisnamen node_modules hinzuzufügen , da die Korrespondenz zwischen der Version und dem Inhalt des npm-Pakets eindeutig ist. Daher reicht es aus, nur die Datei in Ihrem Git-Repository zu speichernpackage.json (в котором перечислены имена и версии зависимостей), но не сами необходимые модули.

(Для расширения кругозора упомяну, что Mikeal Rogers высказывал и деятельно продвигал совершенно противоположную рекомендацию. Но это случилось до того, как в 2014 году соответствие между версией и содержимым пакета npm сделалось однозначным.)

Также в файл .gitignore полезно добавить имя отчёта npm-debug.log, появляющегося в том случае, если при работе с пакетами npm возникла какая-нибудь ошибка.

В итоге файл .gitignore приобретает какой-то такой вид:

.gitignore
# Архивы, дистрибутивы
*.7z
*.dmg
*.gz
*.iso
*.jar
*.rar
*.tar
*.zip
# Базы данных, логи
*.log
*.sql
*.sqlite
# Спецфайлы операционных систем
Thumbs.db
Desktop.ini
.DS_Store*
ehthumbs.db
Icon?
# Модули Node, логи npm
node_modules
npm-debug.log

Datei .npmignore grob ähnliche Datei .gitignore - aber es wird die Namen der Dateien und Unterverzeichnisse , die nicht bekommen sollten in dem NPM-Paket Ihres Modul.

Ich empfehle Ihnen , kopieren Sie in .npmignore den gesamten Inhalt Ihres .gitignore , und dann auf den Namen des Unterverzeichnisses hinzufügen Test oder einem anderen Ort , in dem Sie Ihre Unit - Tests werden speichern. Tests sind äußerst nützlich für die Entwicklung, daher sind sie auch im Git-Repository angemessen. Das Herunterladen und Speichern von Tests wäre jedoch eine zusätzliche Belastung für die Endbenutzer Ihres Moduls, da die meisten Konsumenten aus ihnen bestehennpm-Paket.

In der Regel können Sie zu Beginn der Arbeit an einem neuen Knotenmodul .gitignore- und .npmignore- Dateien unverändert von einem Ihrer vorherigen Module kopieren (es sei denn, Sie erstellen das erste Knotenmodul in Ihrem Leben). Sie müssen sie in seltenen Fällen korrigieren, aber Sie müssen wissen, dass solche Fälle vorkommen. (Insbesondere wenn sich ein Modul mit ZIP-Archiven befasst, muss zwangsläufig die Zeile * .zip aus der .gitignore- Datei entfernt werden, um mindestens einen Testfall im Repository zu platzieren - und ein solcher Bedarf ist entstanden bei der Entwicklung eines Moduls zum Lesen von Fidonets Nodelistzum Beispiel.)

Schritt 6. Beschreibung des Moduls in README.md, Erwähnung der Lizenz und unvollendete Entwicklung.


Ich erinnere Sie daran, dass im dritten Schritt automatisch eine README- Datei erstellt wurde , die nur aus dem Namen und einer kurzen Beschreibung des Moduls besteht.

Nun kann diese Beschreibung etwas ergänzt werden, indem über die Ziele des Projekts gesprochen wird. Zusätzlich ist in einem separaten Unterabschnitt der Beschreibung der Lizenztyp (zum Beispiel MIT oder BSD) und der Name der Datei (normalerweise LICENSE ) anzugeben , die den vollständigen Text der Lizenz enthält.

Damit Versuche, die Leser mit den Fähigkeiten des Moduls in dieser Phase praktisch vertraut zu machen, keine Enttäuschung hervorrufen (oder sogar noch besser, so dass solche Versuche bisher überhaupt nicht auftreten), ist es sinnvoll, umgehend einen Warnhinweis zu posten, dass die Entwicklung des Moduls nicht nur unvollständig ist, sondern sich auch auf befindet frühes Stadium.

Nach einem solchen Nachschub ist die README-Datei als Erstbeschreibung der Erstversion des npm-Pakets geeignet .

Wenn Sie jedoch den geplanten Paketnamen in README erwähnen, nehmen Sie sich Zeit, um die Ergebnisse dieses Schritts in das Repository zu stellen (z. B. mit dem Befehl git commit ), und beeilen Sie sich nicht, sie zu veröffentlichen (z. B. mit dem Befehl git push ).auf Github. Tatsache ist, dass, wenn die Erstregistrierung des Pakets mit dem geplanten Namen fehlschlägt (dh wir werden uns im nächsten Schritt damit befassen), Sie in README einen anderen Namen registrieren müssen (und es besser ist, wenn dies nicht zu einer unangenehmen Wahl zwischen Verstopfen und Löschen des Bearbeitungsverlaufs führt ); Die Veröffentlichung auf dem Github (wenn sie der Veröffentlichung auf npm vorausgeht) kann sogar einige Cybersquatter (die den Paketnamen vor Ihnen abstecken möchten), aber normale Benutzer (die den Befehl "npm install package-name" versuchen ) und frage mich, warum es nicht so funktioniert, wie es sollte).

Im Allgemeinen empfehle ich zu berücksichtigen, dass in diesem Schritt die Erwähnung des geplanten Paketnamens in README zu früh wäre.

Schritt 7. Erstellen Sie package.json und registrieren Sie das npm-Paket der allerersten Version.


Das ultimative Ziel dieses Schritts ist es, das npm-Paket unter einem zuvor festgelegten Namen zu registrieren , um diesen Namen abzustecken.

Sie müssen diesen Schritt starten, indem Sie die Datei package.json erstellen und mehrere Felder des Objekts darin ausfüllen. In diesem Fall müssen Sie gleichzeitig das JSON-Format und die Beschreibung der Bedeutung der Felder beachten , die auf der npm-Website angegeben sind .

Es gibt einen " npm init " -Befehl , der Sie nach dem Modul fragt und package.json entsprechend den Antworten selbst ausfüllt . Ich bevorzuge es jedoch, package.json zu füllenin einem Texteditor - auf diese Weise können Sie den gesamten JSON-Code in seiner reinsten Form (nicht mit Fragen verdünnt) überprüfen und darüber hinaus einfach ein paar Zeilen zurückgeben, um etwas nach Bedarf zu korrigieren oder zu ändern .

In der Tat, die Dokumentation zugrunde liegt die Website npm , sollte genug sein , um alle; aber ich werde es nicht ertragen und auf Habrahabr werde ich kurz auf die Bedeutung der Hauptfelder eingehen , die in package.json platziert sind .

Der Wert für das Feld „ name “ gibt den gewünschten Namen des npm-Pakets an. Sie könnten früher daran denken (im ersten Schritt).

Der Wert für das Feld „ version “ gibt die Paketversion gemäß dem Semantic Versioning- Standard an. Um die allererste Version zu registrieren, empfehle ich " " 0.0.1 " ".

Der Wert für das Feld " Beschreibung " gibt eine kurze Beschreibung des Pakets an. Sie könnten früher daran denken (im zweiten Schritt).

Der Wert für das Feld " keywords " gibt eine Reihe von Schlüsselwörtern an, anhand derer das Paket bei der Suche auf der npm-Site gefunden werden kann. Jeder, der jemals die Labels unter dem Text des Blogposts auf Habrahabr gelistet hat, wird diese Aufgabe problemlos bewältigen können.

Der Wert für das Feld " Lizenz " gibt eine ID- Zeichenfolge an, die dem SPDX-ID- Standard entspricht, und bezeichnet die Lizenz, die Sie zuvor (im vierten Schritt) für Ihren Code ausgewählt haben.

Der Wert für die "author ”gibt eine Zeichenfolge (oder ein Objekt) mit dem Namen des Autors des Pakets (sowie möglicherweise mit Kontaktinformationen) an. Zeigen Sie sich dort an.

Der Wert für das Feld „ Repository “ gibt das Objekt an, das den Typ und die Adresse des Repository enthält.

Der Wert für das Feld „ main “ gibt den Pfad zur Hauptdatei des Modulcodes an (dies ist dieselbe Datei, die von der Knotenfunktion require ( moduleName )aufgerufen wird , wenn Sie anstelle von moduleName den Namen des Moduls angeben).

Wenn das Modul als Utility ist gemeint, dass läuft von der Kommandozeile, dann wird dieses Modul nützlich sein , in package.json Eigenschaft « preferGlobal» со значением «true» (которое будет рекомендовать глобальную установку модуля) и свойство «bin» со значением наподобие «"./moduleName.js"», содержащим путь к некоторому джаваскрипту (к тому именно, который будет запускаться по команде, совпадающей с именем модуля). Строка «#!/usr/bin/env node» должна стать первою в таком джаваскрипте, потому что npm ожидает её увидеть там (даже если установка и последующая работа модуля совершается под Windows).

Код модуля на этом шаге может быть простейшим — например, содержать какой-нибудь«hello world»oder sogar « "use strict" ».

In der Beschreibung des Commits sollte der Ausdruck "Das Paket ist registriert" (oder "Das Paket ist veröffentlicht") eingefügt und erst festgeschrieben werden, nachdem der Befehl " npm publish " erfolgreich ausgeführt wurde (falls dies der Fall ist). Daher ist das Festschreiben nicht verfrüht (das Ausgeben des Befehls " npm publish " kann einen oder mehrere einfache Fehler aufdecken, deren Korrektur nur den Verlauf von Änderungen vergeblich beeinträchtigen würde).

Schritt 8. Erläuterung der Installation in README.md


Während dieses Schritts sollten Erklärungen in die Datei README.md eingefügt werden, die den zukünftigen Benutzern die Bedeutung der beiden Befehle mitteilen:

  • npm install Paketname ist der Befehl, mit dem das npm-Paket aus dem npm-Repository installiert wird.
     
  • npm install https://github.com/User name / Repository name / tarball / master - ein Befehl, der das Modul aus dem Master-Zweig des Github-Repositorys installiert .

Es ist auch nützlich, zukünftigen Benutzern den Unterschied zwischen den Ergebnissen des einen und des anderen Teams zu erläutern, um beispielsweise über die Entscheidung zu berichten, die zuvor (im fünften Schritt) getroffen wurde, um Tests nur auf Github und nicht in npm zu speichern (um das Volumen des npm-Pakets nicht zu erhöhen ).

Sie können auch feststellen, dass sich die neueste Version der Datei README.md nur auf Github befindet (es sei denn, Sie planen, die nächste neue Version Ihres npm-Pakets nicht nur nach Änderungen im Code, sondern auch nach Änderungen in README zu erstellen und zu veröffentlichen ).

Im gleichen Schritt können Sie auch den entsprechenden Code für informative statistische Zähler und Histogramme auf der Website nodei.co abrufen , der die Anzahl der Abhängigkeiten und Moduleinstellungen angibt, und diese in die Datei README.md einfügen.

Schritt 9. Der Beginn der Arbeit am Hauptmodulcode


In diesem Stadium das Modul Rudiment (dh einige « hallo world » oder « ‚use strict‘ ») verwandelt sich allmählich in einen Code, der etwas Vernünftiges macht - und damit mit zu diesem Zweck eine oder mehrere Funktionen (oder Objektmethoden oder Utility-Befehle).

Während des Aufbaus sollten alle diese Funktionen des Quellcodes sorgfältig in README.md dokumentiert werden, damit der Code selbst nicht die einzige Dokumentation für den Open Source-Code bleibt.

Sobald der Quellcode dieses Stadium erreicht, wäre es außerdem hilfreich, ihn sofort mit Tests zu belegen, die die Richtigkeit des Codes und sein Verhalten überprüfen. Dies ist der nächste Schritt.

Schritt 10. Erleichtern Sie das Testen und erklären Sie es.


In diesem Schritt müssen Sie in README.md klare Informationen zur Installation und Verwendung der Testtools zum Schreiben des Quellcodes (z. B. JSHint) und seines Verhaltens (z. B. Mocha) eingeben.

Zu diesem Zeitpunkt werden auch Konfigurationsdateien für Testtools (z. B. .jshintrc für JSHint) zum Repository hinzugefügt .

Das Feld scripts.test wird im Objekt in der Datei package.json ausgefüllt (und wenn zwei oder drei Testtools vorhanden sind, werden auch die Felder scripts.pretest und scripts.posttest ausgefüllt ). Ein Beispiel:



"scripts": {
   "pretest": "jshint имяМодуля.js test/",
   "test": "mocha --reporter spec --timeout 60s"
}

Ab diesem Schritt sollte vor jedem Festschreiben sichergestellt werden, dass der Befehl npm test fehlerfrei ausgeführt wird. (Um diesen Befehl aussagekräftiger zu machen, sollten Sie bei Verwendung von Mocha auch mindestens einen Test schreiben und im Unterverzeichnis test / ablegen .)

Schritt 11. Travis CI konfigurieren


Travis CI ist ein Dienst, der einen kostenlosen Open-Source-Testdienst anbietet: Nach jedem Commit kann der Code automatisch vom Github heruntergeladen und in verschiedenen Umgebungen getestet werden, um festzustellen, ob der Code ordnungsgemäß funktioniert.

Es wäre schön, sich auf die erstmalige Verwendung von Travis CI vorzubereiten, dh die Dokumentation zu lesen und zu registrieren.

Das Anschließen eines neuen Javascript-Moduls ist viel einfacher und besteht aus zwei einfachen Schritten.

Gehen Sie zunächst in Ihrem Benutzerprofil zu https://travis-ci.org/profile/ . Es werden Schalter angezeigt, die jeweils einem der Repositorys auf dem Github entsprechen. es sieht ungefähr so aus:

[Screenshot]

Der Schalter, der dem neuen Modul entspricht, muss in die Position Ein gezogen werden.

Zweitens unmittelbar danach ist es notwendig , eine Datei zu begehen .travis.yml im Repository root. Diese Datei beschreibt die Umgebung, die zum Ausführen der Tests erforderlich ist. Sie können mehr darüber in der Travis-Dokumentation lesen, aber der übliche Inhalt ist ziemlich unkompliziert und sieht ungefähr so ​​aus :

language: node_js
node_js:
  - "0.10"
  - "0.12"
  - iojs
before_install:
  - "npm install -g npm"
  - "npm config set spin false"
before_script:
  - "npm install jshint"
  - "npm install mocha"

Im Abschnitt " language " sehen Sie die Angabe der "language" (genauer gesagt der Engine) von Node, und im Abschnitt " node_js " sehen Sie eine Liste der Versionen, in denen das Modul getestet wird.

Der Abschnitt before_install enthält Befehle, mit denen npm auf die neueste stabile Version aktualisiert und die Animation des sich drehenden Cursors deaktiviert wird (der immer noch nicht in den Travis CI-Protokollen angezeigt wird, sodass Sie keine Zeit damit verschwenden müssen).

Der Abschnitt before_script enthält Befehle, mit denen Testtools installiert werden (in diesem Beispiel JSHint und Mocha).

Schritt 12. Hinzufügen des Travis CI-Indikators zu  README.md .


Travis CI gibt die URL des Bildes an, die einmal in der README-Datei auf dem Github abgelegt werden kann, um zu prüfen, ob die Ergebnisse des letzten Commits bei Travis CI erfolgreich getestet wurden.

Der Server shields.io bietet die Möglichkeit, eine etwas andere Form dieses Bildes zu erhalten - beispielsweise das Volumen oder die Abrundung der Kanten oder einen Teil der Inschrift zu ändern.

Methodenverallgemeinerung


Damit ist die Liste der einfachen ersten Schritte zum Entwickeln eines Moduls für Node.js abgeschlossen.

Natürlich hoffe ich, dass eine solche Methode (dh die Möglichkeit, sich einen ersten Impuls zu geben, indem Sie mit der Reproduktion zuvor vorbereiteter Schritte beginnen) nicht nur für die Entwicklung von Modulen für Node geeignet ist.

Ich werde ein Beispiel geben. In dem Artikel über Entwicklerlähmungen (der von PerseptronYar übersetzt wurde) konnte man auf Habrahabr die Geschichte sehen, dass jeder moderne Bauleiter, der seine Arbeit aufnimmt, sofort die dringende Notwendigkeit hat, eine nicht offensichtliche Wahl zwischen verschiedenen Möglichkeiten zu treffen, die annähernd gleichermaßen attraktiv sind - wie ein Buridan-Esel : Sie können Ihr zukünftiges Leben jedoch erheblich vereinfachen, wenn Sie eine solche Entscheidung nicht nur einmal treffen, sondern sich auch in Zukunft einfach daran halten können. Dazu genügt es, die in einem solchen Schritt getroffene Auswahl schriftlich festzuhalten, alle diese Schritte in ihrer fertigen Form aufzuschreiben (z. B. nicht "CSS-Framework auswählen", sondern "Bootstrap installieren", wenn Sie "Bootstrap" ausgewählt haben) und dann zu befolgen zu Beginn jedes neuen Projekts, wenn nur in der Pause zwischen den Projekten kein Grund bestand, bewusst etwas Neues auszuprobieren ( naja , Sie können beispielsweise Underscore.js zugunsten der neuesten JavaScript-Funktionen ablehnen , wenn Ihnen ein schrittweiser Übergang von Lesern zu neuen Browsern zur Verfügung steht so ein Wagen ozhnost).

Jetzt auch beliebt: