10 expériences résumées lors de l'utilisation de node.js pendant six mois_node.js

Ne parlons pas des prix des logements, des embouteillages et du smog. . . Permettez-moi d'abord de parler de mon expérience d'utilisation de Node.js au cours des six derniers mois. . . Ce sont tous des problèmes rencontrés au travail et des leçons apprises par le sang. .

1. Numéro de version précis

"Il doit être précis par rapport au numéro de version spécifique ! Utilisez * pour faire défiler directement, ^ et ~ ne fonctionnera pas ! Quand je suis arrivé dans l'entreprise le matin, la tête de notre serveur était pleine d'yeux injectés de sang (je suppose) » il s'est endormi à quelle heure du matin), et il s'est plaint à moi : " Bon sang, la version dans package.json du code que j'ai écrit auparavant est différente de la version exécutée sur le serveur. Quand j'ai installé la dernière, J'ai encore eu une erreur." Omettez quelques milliers de mots ici. . .

D'accord. Je me gifle d'abord. Dans le passé, seul * était utilisé. . . La plupart du temps, il n'est pas nécessaire de coder en dur le numéro de version. Vous pouvez également utiliser ^ et ~. Scannez les aveugles :

semver
Gestion des versions dans node.js

2.Test

Assurez-vous d'écrire des cas de test. Prenez-moi par exemple, la partie dont je suis responsable inclut la partie filtrage (en utilisant le texte du filtre Shenma standard pour extraire le texte utile). Avec les cas de test, chaque fois que vous modifiez les règles de filtrage, exécutez npm test et tout ira bien. Choisissez le module de test à utiliser en fonction de vos préférences personnelles, comme moka, Should, Tape, Tap, Supertest, etc.

Essayez de l'exécuter localement et de le télécharger sur le serveur uniquement une fois le test réussi. Après avoir modifié le code plusieurs fois (quelques lignes seulement), j'ai pensé qu'il pouvait y avoir un problème, mais dès que j'ai redémarré le serveur, il s'est écrasé. . Bon sang, il me manque des parenthèses ou quelque chose comme ça. . Ce type de problème peut également être résolu en utilisant des plugins d'éditeur tels que jslint ou jshint pour détecter les erreurs de syntaxe de bas niveau.

Sauvegarde du code du serveur. La méthode que j'utilise actuellement : Au départ il y a deux projets identiques (bibliothèques git, les noms de fichiers sont différents) sur le serveur, l'un est en cours d'exécution et l'autre est utilisé comme sauvegarde. Lorsqu'il y a des changements de code, accédez au projet de sauvegarde et git pull, puis arrêtez le programme en cours et démarrez le programme de sauvegarde. Si le programme ne raccroche pas après un certain temps, c'est-à-dire après avoir semblé relativement stable, ce projet sera considéré comme le projet principal et l'autre projet comme la sauvegarde. Lorsqu'il y a à nouveau des changements, répétez les étapes ci-dessus et basculez entre actif et veille. Si le programme se bloque, revenez simplement à un appareil plus stable.

3. Utiliser le débogage

Le débogage est inévitable lors de l'écriture de programmes. Beaucoup de gens aiment et sont habitués à utiliser le console.log() polyvalent, y compris moi. . Personnellement, après avoir utilisé console.log(), soit je le supprime, soit je le commente. Supprimez-le et il pourra être utilisé à l’avenir. Le commenter aura l’air moche. À ce stade, vous pourriez aussi bien utiliser le module de débogage. Je n'ai pas encore utilisé node-inspector, donc je ne ferai pas de commentaire.

4. Gardez le code rationalisé

Essayer d'accomplir plus de choses avec moins de code est également une amélioration et un test de vos propres capacités. Y compris une indentation correcte, des noms de variables appropriés, une structure organisationnelle claire du code, etc. . Le code est simple et beau. Lorsque quelque chose ne va pas, il est plus rapide de revenir en arrière et de vérifier les erreurs. C'est mieux que de passer des heures à essayer de comprendre d'abord ce qu'un fouillis de code fait.

N'utilisez pas CoffeeScript si votre équipe ne l'utilise pas. Premièrement, les autres ne peuvent pas lire votre code et vous aider à corriger les erreurs. Deuxièmement, après qu'une erreur se soit produite, le nombre de lignes affichant l'erreur est différent du nombre de lignes du code café. . . Vous pouvez l'utiliser pour vos propres projets open source.

5. Demandez conseil et maintenez une pensée indépendante

Quand j'ai commencé à travailler, j'étais confus à propos de tout, y compris des lacunes techniques et des lacunes en matière de logique métier, j'ai donc souvent demandé conseil aux experts de l'équipe. Ensuite, j'essaierai de combler les lacunes techniques et de clarifier la logique métier. Plus tard, j'ai dû concevoir une API selon les exigences du PM. J'ai dû prendre en compte les besoins des utilisateurs (situation multi-clients), les besoins et comportements des clients, ainsi que la conception de la base de données (comment stocker). moins de données redondantes, réduire le nombre de requêtes et être facile à développer). Facile à modifier, requête différentielle), etc., j'y ai réfléchi pendant plus d'une semaine et je me suis presque effondré. . . Même si j'en ai discuté à plusieurs reprises avec le patron, cela me donne toujours de la logique mais ne me dit pas la méthode. Plus tard, j'ai finalement trouvé une très bonne solution. . Il m'a également dit plus tard qu'il voulait que je réfléchisse de manière indépendante et que je résolve les problèmes afin de pouvoir m'améliorer. .

6. Utiliser les bibliothèques existantes

Actuellement, il existe près de 9W de modules tiers sur npm. En théorie, tout ce que vous souhaitez utiliser se trouve sur npm. Bien sûr, il existe de nombreux excellents modules sur npm. . C'est généralement un besoin satisfaisant. Si vous constatez qu'un module peut répondre à la plupart des besoins, présente des améliorations fonctionnelles ou présente des bogues, vous pouvez soumettre un PR sur github. Si vous constatez que vous ne trouvez pas de module qui répond à vos besoins, vous pouvez en créer un vous-même et le publier sur. npm. Partagez-le avec tout le monde. Bien sûr, si vous trouvez qu'un certain type de module qui implémente une certaine fonction est très merdique, vous pouvez également publier un module qui ne l'est pas.

7. Restez simple

Si vous souhaitez afficher un diagramme circulaire, utilisez simplement un canevas HTML5 ou CSS3. Il n'est pas nécessaire d'utiliser la bibliothèque de canevas de C pour dessiner une image. "Le simple téléchargement des bibliothèques dépendantes représente 400 Mo", a déclaré Toutou.

8. Bonne documentation

Une bonne documentation est le canal de communication le plus important entre les équipes client et serveur. La documentation est clairement rédigée. Si une demande client tourne mal, vous pouvez d'abord vérifier la documentation (par exemple, ce que représente chaque code d'erreur), au lieu d'aller sur le serveur pour en discuter à chaque fois que quelque chose ne va pas. PS : essayez d'utiliser curl pour écrire des exemples de requêtes http au lieu d'objets en js. Peut-être que vous pouvez le comprendre, mais les personnes sur le client ne comprennent pas js.

9. Fichier de configuration

Créez un fichier de configuration dans chaque répertoire de projet, tel que config.js/config.json. Plutôt que de le coder en dur dans le code. Tel que :

{
"application": 3000,
"mongo": {
"hôte": "localhost",
"port": 27017
},
"redis": {
"hôte": "localhost",
"port": 6379
>
...
>
10. Utilisez pm2

Il est très pratique d'utiliser des outils de gestion de processus tels que pm2. Au pire, le processus peut être automatiquement redémarré s'il s'arrête. Jamais utilisé depuis toujours. Aucune évaluation. . De plus, je n’ai pas utilisé Grunt Shenma, donc je ne ferai pas de commentaire à ce sujet.