Ne parlons pas des prix des logements, des embouteillages et du smog. . . Permettez-moi d'abord de parler de mon expérience en utilisant Node.js au cours des six derniers mois. . . Tous sont des problèmes rencontrés au travail et des leçons sanglantes. .
1. Numéro de version précise
"Vous devez être précis au numéro de version spécifique! Utiliser * pour rouler directement, ^ et ~ ne sont pas OK!" Dès que nous sommes arrivés dans l'entreprise le matin, notre serveur a été couvert dans des yeux injectés de sang (c'était probablement l'heure du matin pour aller au lit) et me plaignait: "Merde, la version dans Package.json du code que j'ai écrit précédemment est différente de la version qui s'exécute sur le serveur. Installez le dernier et ensuite signalé une erreur." Quelques milliers de mots sont omis ici. . .
D'accord. Je vais d'abord me gifler au visage. J'utilisais uniquement *. . . La plupart du temps, il n'est pas nécessaire d'écrire un numéro de version mort, et il est également possible d'utiliser ^ et ~. Scannez la cécité:
Semver
Gestion de la version dans Node.js
2. Test
Assurez-vous d'écrire des cas de test. Prenez-moi par exemple. La pièce dont je suis responsable contient la pièce de filtrage (en utilisant le texte filtrant de la shenma ordinaire pour extraire du texte utile). Avec les cas de test, après chaque changement des règles de filtrage, il est absolument vrai dans le test NPM. Choisissez les modules de test à utiliser en fonction de vos préférences personnelles, Mocha, devriez, bande, appuyez sur, super-test, etc.
Essayez d'exécuter localement et téléchargez sur le serveur une fois le test réussi. J'ai modifié le code plusieurs fois (j'ai juste changé quelques lignes) et j'ai pensé qu'il pourrait y avoir un problème, mais dès que le serveur a été redémarré, il raccroche. . Merde, il manque de supports ou quelque chose comme ça. . Ce problème peut également être détecté en utilisant des plugins d'éditeur tels que JSlint ou Jshint.
Sauvegarde du code du serveur. La méthode que j'utilise: au début, il y avait deux projets identiques sur le serveur (bibliothèque GIT, différents noms de fichiers), l'un en cours d'exécution et l'autre comme sauvegarde. Lorsqu'il y a des modifications de code, accédez au projet de sauvegarde sur Git Pull, puis arrêtez le programme d'exécution et démarrez le programme de sauvegarde. Si le programme n'échoue pas pendant un certain temps, cela signifie qu'il se sent relativement stable, prenez ce projet comme le principal projet et un autre projet comme préparation. Lorsqu'il y a un autre changement, répétez les étapes ci-dessus et le commutateur principal et de sauvegarde d'avant en arrière. Si le programme échoue, passez à une sauvegarde plus stable.
3. Utiliser le débogage
Le débogage est inévitable lors de la rédaction de programmes. Beaucoup de gens aiment et ont l'habitude d'utiliser la console universelle.log (), y compris moi. . Personnellement, après avoir utilisé Console.log () pour l'ajuster, supprimez-le ou commentez-le. Il peut être utilisé plus tard si vous le supprimez, mais il est très laid de le commenter. Vous pourriez aussi bien utiliser le module de débogage pour le moment. Aucun inspecteur de nœud n'a encore été utilisé, donc aucune évaluation n'est effectuée.
4. Gardez le code simple
Essayer d'accomplir plus de choses avec moins de code est également une amélioration et un test de vos propres capacités. Comprend une indentation correcte, des noms de variables appropriés, une organisation de code claire, etc. Le code est plus mince et beau. Lorsque quelque chose ne va pas, il est plus rapide de vérifier l'erreur. C'est mieux que de comprendre ce que fait un code désordonné et il faut plusieurs heures pour le faire.
Si l'équipe n'utilise pas CoffeeScript, ne l'utilisez pas. Tout d'abord, les autres ne peuvent pas comprendre votre code pour vous aider à corriger les erreurs. Deuxièmement, le nombre de lignes qui apparaissent après une erreur est différent du nombre de lignes qui sont affichées dans le code de café. . . Votre propre projet open source peut être utilisé.
5. Demandez plus de conseils et continuez à réfléchir indépendamment
Quand j'ai commencé à travailler, j'étais également confus, y compris les lacunes techniques et le manque de logique commerciale. J'ai souvent demandé aux grands gars de l'équipe. Ensuite, j'essaierai de compenser les lacunes techniques et de clarifier la logique commerciale. Plus tard, je voulais concevoir une API en fonction des exigences de PM, qui non seulement prenait en compte les besoins des utilisateurs (la situation de plusieurs clients), les besoins et le comportement des clients, la conception de la base de données (comment stocker moins de redondance, moins de requêtes, facile à développer, facile à modifier et différentes requêtes), etc. Après l'avoir considéré pendant plus d'une semaine, il a presque écrasé. . . Bien que j'aie discuté avec Touch Touchance à plusieurs reprises, cela me donne toujours une logique et ne me dit pas la méthode. Plus tard, j'ai finalement trouvé une assez bonne solution. . Il m'a dit plus tard qu'il voulait que je continue de penser indépendamment pour résoudre des problèmes pour que je puisse m'améliorer. .
6. Utiliser les bibliothèques existantes
Actuellement, il y a près de 9W de modules tiers sur NPM. En théorie, tout ce que vous voulez utiliser peut être trouvé sur NPM. Bien sûr, il existe de nombreux excellents modules sur NPM, avec une documentation complète et une utilisation très pratique, qui répondent généralement aux besoins. Si vous constatez qu'un module peut répondre à la plupart des besoins, il peut être amélioré fonctionnellement ou a des bogues, vous pouvez aller sur GitHub pour ajouter des relations publiques. Si vous constatez que vous ne pouvez pas trouver de module satisfaisant, vous pouvez le créer et le publier sur NPM pour partager avec vous. Bien sûr, si vous constatez qu'un certain type de module qui implémente une certaine fonction est très merde, vous pouvez également publier une merde.
7. Gardez les choses simples
Si vous souhaitez afficher un graphique à secteurs, utilisez simplement HTML5 Canvas ou CSS3. Il n'est pas nécessaire d'utiliser la bibliothèque du canevas C ++ pour dessiner une image, "la bibliothèque qui dépend est de 400+ MB", a déclaré ceci.
8. Bonne documentation
Une bonne documentation est le canal le plus important que les clients peuvent communiquer avec les équipes de serveur. Le document est clairement écrit. Si l'erreur de demande du client se produit, vous pouvez d'abord vérifier le document (comme ce que chaque code d'erreur représente), au lieu de demander au serveur de discuter chaque fois qu'il y a un problème. PS: Certains exemples de demande HTTP doivent être écrits en curl, plutôt que des objets en js, etc. Vous pouvez le comprendre très bien, mais le client ne comprend pas JS.
9. Fichier de configuration
Créez un fichier de configuration dans chaque répertoire de projet, tel que config.js / config.json. Au lieu de l'écrire mort dans le code. comme:
{
"App": 3000,
"Mongo": {
"hôte": "localhost",
"Port": 27017
},
"redis": {
"hôte": "localhost",
"Port": 6379
}
...
}
10. Utiliser PM2
L'utilisation d'outils de gestion de processus tels que PM2 est très pratique, et le processus peut être automatiquement redémarré en cas d'échec. Je n'ai pas utilisé pour toujours, aucune évaluation. . Il y a aussi un grognement. Je ne l'ai pas utilisé auparavant, donc je ne commenterai pas.