Sprechen wir nicht über Immobilienpreise, Staus und Smog. . . Lassen Sie mich zuerst in den letzten sechs Monaten über meine Erfahrungen mit Node.js sprechen. . . Alle sind Probleme, die bei der Arbeit und im blutigen Unterricht auftreten. .
1. genaue Versionsnummer
"Sie müssen der spezifischen Versionsnummer genau sein! Verwenden Sie *, um direkt zu rollen, ^ und ~ sind nicht in Ordnung!" Sobald wir morgens in der Firma ankamen, war unser Server mit blutunterlaufenen Augen bedeckt (es war wahrscheinlich zu welcher Morgenzeit ins Bett) und beschwerte mich: "Verdammt, die Version in Paket.json -Code, die ich zuvor geschrieben habe, unterscheidet sich von der Version, die auf dem Server ausgeführt wird. Installieren Sie die neueste und berichteten dann über einen Fehler." Ein paar tausend Worte werden hier weggelassen. . .
In Ordnung. Ich werde mich zuerst ins Gesicht schlagen. Ich habe nur *verwendet *. . . Meistens müssen keine tote Versionsnummer geschrieben werden, und es ist auch möglich, ^ und ~ zu verwenden. Scannen Sie die Blindheit:
Semver
Versionsverwaltung in node.js
2. Test
Stellen Sie sicher, dass Sie Testfälle schreiben. Nehmen Sie mich zum Beispiel. Das Stück, für das ich verantwortlich bin, enthält den Filterteil (unter Verwendung des Filtertextes des regulären Shenma, um nützlichen Text zu extrahieren). Nach jeder Änderung der Filterregeln gilt dies unter dem NPM -Test absolut. Wählen Sie die Testmodule aus, die nach Ihren persönlichen Vorlieben, Mokka, sollte, Klebeband, Tippen, Supertest usw.
Versuchen Sie, lokal auszuführen und laden Sie nach dem erfolgreichen Test auf den Server hoch. Ich habe den Code mehrmals geändert (nur ein paar Zeilen geändert) und dachte, es könnte ein Problem geben, aber sobald der Server neu gestartet wurde, hängt er auf. . Verdammt, es fehlen Klammern oder so. . Dieses Problem kann auch mithilfe von Editor -Plugins wie JSINT oder JSHINT erfasst werden.
Sicherungscode -Sicherung. Die Methode, die ich verwende: Zunächst gab es zwei identische Projekte auf dem Server (Git -Bibliothek, verschiedene Dateinamen), eine laufende und die andere als Sicherung. Wenn es Codeänderungen gibt, gehen Sie zum Backup -Projekt, um Git Pull zu erhalten, dann das laufende Programm und starten Sie das Backup -Programm. Wenn das Programm für einen bestimmten Zeitraum nicht scheitert, bedeutet dies, dass es sich relativ stabil anfühlt. Nehmen Sie dieses Projekt als Haupt- und ein anderes Projekt als Vorbereitung. Wenn es eine weitere Änderung gibt, wiederholen Sie die obigen Schritte sowie der Haupt- und Sicherungsschalter hin und her. Wenn das Programm fehlschlägt, wechseln Sie wieder auf eine stabilere Sicherung.
3. Verwenden Sie Debug
Debugging ist unvermeidlich beim Schreiben von Programmen. Viele Menschen mögen und sind es gewohnt, die Universal Console.log () zu verwenden, einschließlich mir. . Persönlich, nachdem ich Console.log () verwendet habe, um es anzupassen, löschen Sie es entweder oder kommentieren Sie es aus. Es kann später verwendet werden, wenn Sie es löschen, aber es ist sehr hässlich, es zu kommentieren. Sie können das Debug -Modul zu diesem Zeitpunkt genauso gut verwenden. Es wurde noch kein Knoteninspektor verwendet, daher wird keine Bewertung durchgeführt.
4. Halten Sie den Code einfach
Der Versuch, mehr Dinge mit weniger Code zu erreichen, ist auch eine Verbesserung und Prüfung Ihrer eigenen Fähigkeiten. Beinhaltet korrekte Eindrücke, entsprechende Variablennamen, Clear Code -Organisation usw. Der Code ist dünner und schön. Wenn etwas schief geht, ist es schneller, den Fehler zu überprüfen. Es ist besser, als herauszufinden, was ein unordentlicher Code tut, und es dauert mehrere Stunden, um dies zu tun.
Wenn das Team CoffeeScript nicht verwendet, verwenden Sie es nicht. Erstens können andere Ihren Code nicht verstehen, um Ihnen zu helfen, Fehler zu korrigieren. Zweitens unterscheidet sich die Anzahl der Zeilen, die nach einem Fehler auftreten, von der Anzahl der Zeilen, die im Kaffeecode angezeigt werden. . . Ihr eigenes Open -Source -Projekt kann verwendet werden.
5. Fragen Sie mehr Rat und denken Sie weiterhin unabhängig nach
Als ich anfing zu arbeiten, war ich auch verwirrt, einschließlich technischer Mängel und mangelnder Geschäftslogik. Ich habe die großen Jungs im Team oft gefragt. Dann werde ich versuchen, technische Mängel auszugleichen und die Geschäftslogik zu klären. Später wollte ich eine API entsprechend den Anforderungen des PM entwerfen, die nicht nur die Bedürfnisse von Benutzern (die Situation mehrerer Kunden), die Bedürfnisse und das Verhalten von Kunden, das Design der Datenbank (wie man weniger Redundanz, weniger Abfragen, leicht erweitert, leicht zu ändern, und unterschiedliche Abfragen) usw. berücksichtigte. . . Obwohl ich viele Male mit Tou tou besprochen habe, gibt es mir immer Logik und sagt mir die Methode nicht. Später fand ich endlich eine ziemlich gute Lösung. . Er sagte mir später, dass er wollte, dass ich weiterhin unabhängig nachdenke, um Probleme zu lösen, damit ich mich verbessern kann. .
6. Verwenden Sie vorhandene Bibliotheken
Derzeit gibt es auf NPM fast 9W-Modulen von Drittanbietern. Theoretisch finden Sie alles, was Sie verwenden möchten, auf NPM. Natürlich gibt es viele hervorragende Module für NPM mit umfassender Dokumentation und sehr bequemer Gebrauch, die normalerweise den Anforderungen entsprechen. Wenn Sie feststellen, dass ein Modul die meisten Anforderungen erfüllen kann, es funktional verbessert werden kann oder Fehler aufweist. Sie können zu GitHub gehen, um PR hinzuzufügen. Wenn Sie feststellen, dass Sie kein zufriedenstellendes Modul finden, können Sie es auf NPM erstellen und veröffentlichen, um sie mit Ihnen zu teilen. Wenn Sie feststellen, dass eine bestimmte Art von Modul, die eine bestimmte Funktion implementiert, sehr Scheiße ist, können Sie auch eine Scheiße veröffentlichen.
7. Halten Sie es einfach
Wenn Sie ein Kreisdiagramm anzeigen möchten, verwenden Sie einfach HTML5 -Canvas oder CSS3. Es ist nicht erforderlich, die C ++ - Canvas -Bibliothek zu verwenden, um ein Bild zu zeichnen.
8. Gute Dokumentation
Gute Dokumentation ist der wichtigste Kanal für Clients, um mit Serverteams zu kommunizieren. Das Dokument ist klar geschrieben. Wenn der Client -Anforderungsfehler auftritt, können Sie zunächst das Dokument überprüfen (z. B. was jeder Fehlercode darstellt), anstatt den Server zu bitten, jedes Mal zu diskutieren, wenn ein Problem vorliegt. PS: Einige HTTP -Anforderungsbeispiele sollten in CULL und nicht in JS usw. geschrieben werden. Sie können es sehr gut verstehen, aber der Kunde versteht JS nicht.
9. Konfigurationsdatei
Erstellen Sie eine Konfigurationsdatei in jedem Projektverzeichnis, wie z. B. config.js/config.json. Anstatt es tot im Code zu schreiben. wie:
{
"App": 3000,
"Mongo": {{
"Host": "Localhost",
"Port": 27017
},
"Redis": {
"Host": "Localhost",
"Port": 6379
}
...
}
10. Verwenden Sie PM2
Die Verwendung von Prozessmanagement -Tools wie PM2 ist sehr bequem und der Prozess kann automatisch neu gestartet werden, wenn er fehlschlägt. Ich habe nicht für immer verwendet, keine Bewertung. . Es gibt auch Grunzen. Ich habe es noch nicht benutzt, also werde ich nicht kommentieren.