No hablemos de los precios de la vivienda, los atascos y el smog. . . Permítanme hablar primero sobre mi experiencia usando Node.js en los últimos seis meses. . . Todos son problemas encontrados en el trabajo y lecciones sangrientas. .
1. Número de versión preciso
"¡Debe ser preciso para el número de versión específico! Use * para rodar directamente, ^ y ~ ¡no está bien!" Tan pronto como llegamos a la compañía por la mañana, nuestro servidor estaba cubierto de ojos de sangre (probablemente era la hora de la mañana ir a la cama) y me quejó: "Maldición, la versión en paquete. El código JSON que escribí antes es diferente de la versión que se ejecuta en el servidor. Instale el último y luego informó un error". Aquí se omiten unos pocos miles de palabras. . .
Está bien. Primero me abofetearé en la cara. Solía usar solo *. . . La mayoría de las veces, no hay necesidad de escribir un número de versión muerto, y también es posible usar ^ y ~. Escanear la ceguera:
semver
Administración de versiones en Node.js
2. Prueba
Asegúrese de escribir casos de prueba. Llévame, por ejemplo. La pieza de la que soy responsable contiene la parte de filtrado (usando el texto del filtro de la shenma normal para extraer texto útil). Con los casos de prueba, después de cada cambio de las reglas de filtrado, es absolutamente cierto en la prueba NPM. Elija los módulos de prueba para usar de acuerdo con sus preferencias personales, moca, debería, cinta adhesiva, toque, supertest, etc.
Intente ejecutar localmente y cargue al servidor después de que la prueba sea exitosa. He modificado el código varias veces (acabo de cambiar algunas líneas) y pensé que podría haber un problema, pero tan pronto como se reinició el servidor, cuelga. . Maldita sea, carece de corchetes o algo así. . Este problema también se puede detectar utilizando complementos del editor como JSLint o Jshint.
Copia de seguridad del código del servidor. El método que estoy usando: al principio había dos proyectos idénticos en el servidor (biblioteca Git, diferentes nombres de archivos), uno en ejecución y el otro como copia de seguridad. Cuando haya cambios en el código, vaya al proyecto de copia de seguridad para obtener la extracción, luego detenga el programa de ejecución e inicie el programa de copia de seguridad. Si el programa no falla por un período de tiempo, significa que se siente relativamente estable, tome este proyecto como el principal y otro proyecto como la preparación. Cuando haya otro cambio, repita los pasos anteriores y el cambio principal y de copia de seguridad de un lado a otro. Si el programa falla, vuelva a una copia de seguridad más estable.
3. Use la depuración
La depuración es inevitable al escribir programas. A muchas personas les gusta y están acostumbradas a usar Universal Console.log (), incluido yo. . Personalmente, después de usar console.log () para ajustarlo, eliminarlo o comentarlo. Se puede usar más tarde si lo elimina, pero es muy feo comentarlo. También podría usar el módulo de depuración en este momento. Todavía no se ha utilizado el inspector de nodos, por lo que no se realiza una evaluación.
4. Mantenga el código simple
Intentar lograr más cosas con menos código también es una mejora y prueba de sus propias habilidades. Incluye la sangría correcta, nombres de variables apropiados, organización de código claro, etc. El código es más delgado y hermoso. Cuando algo sale mal, es más rápido verificar el error. Es mejor que averiguar qué hace un código desordenado y tarda varias horas en hacerlo.
Si el equipo no usa CoffeeScript, no lo use. Primero, otros no pueden entender su código para ayudarlo a corregir errores. En segundo lugar, el número de líneas que aparecen después de un error es diferente del número de líneas que se muestran en el código de café. . . Se puede utilizar su propio proyecto de código abierto.
5. Pide más consejos y sigue pensando de forma independiente
Cuando comencé a trabajar, también estaba confundido, incluidas las deficiencias técnicas y la falta de lógica comercial. A menudo preguntaba a los grandes del equipo. Luego intentaré compensar las deficiencias técnicas y aclarar la lógica de negocios. Más tarde, quería diseñar una API de acuerdo con los requisitos de PM, que no solo tenían en cuenta las necesidades de los usuarios (la situación de múltiples clientes), las necesidades y el comportamiento de los clientes, el diseño de la base de datos (cómo almacenar menos redundancia, menos consultas, fáciles de expandir, fáciles de modificar y diferentes consultas), etc. Después de considerarlo durante más de una semana, casi se bloquea. . . Aunque discutí con Tou muchas veces, siempre me da lógica y no me dice el método. Más tarde, finalmente encontré una solución bastante buena. . Más tarde me dijo que quería que siguiera pensando de forma independiente para resolver problemas para que yo pudiera mejorar. .
6. Use bibliotecas existentes
Actualmente, hay módulos de terceros de casi 9W en NPM. En teoría, todo lo que desea usar se puede encontrar en NPM. Por supuesto, hay muchos módulos excelentes en NPM, con documentación integral y un uso muy conveniente, que generalmente satisfacen las necesidades. Si encuentra que un módulo puede satisfacer la mayoría de las necesidades, puede mejorarse funcionalmente o tiene errores, puede ir a GitHub para agregar PR. Si encuentra que no puede encontrar un módulo satisfactorio, puede crearlo y publicarlo en NPM para compartir con usted. Por supuesto, si encuentra que un cierto tipo de módulo que implementa una determinada función es muy mierda, también puede publicar una mierda.
7. Mantenlo simple
Si desea mostrar un gráfico circular, simplemente use el lienzo HTML5 o CSS3. No es necesario usar la biblioteca de lienzo C ++ para dibujar una imagen, "La biblioteca de la que depende es de más de 400 MB", dijo esto.
8. Buena documentación
La buena documentación es el canal más importante para que los clientes se comuniquen con los equipos de servidor. El documento está claramente escrito. Si se produce el error de solicitud del cliente, primero puede verificar el documento (como lo que representa cada código de error), en lugar de pedirle al servidor que discuta cada vez que hay un problema. PD: Algunos ejemplos de solicitudes HTTP deben escribirse en curl, en lugar de objetos en JS, etc. Puede entenderlo muy bien, pero el cliente no entiende JS.
9. Archivo de configuración
Cree un archivo de configuración en cada directorio de proyecto, como config.js/config.json. En lugar de escribirlo muerto en el código. como:
{
"Aplicación": 3000,
"Mongo": {
"Anfitrión": "localhost",
"Puerto": 27017
},
"Redis": {
"Anfitrión": "localhost",
"Puerto": 6379
}
...
}
10. Use PM2
El uso de herramientas de administración de procesos como PM2 es muy conveniente, y el proceso se puede reiniciar automáticamente si falla. No he usado para siempre, no hay evaluación. . También hay gruñido. No lo he usado antes, así que no comentaré.