¿Qué trucos que pocas personas conocen me hacen un desarrollador elegante de Node.js?

Agregaré a las otras respuestas una cosa interesante que encontré:

• escriba las pruebas primero, cuando sea posible y calcule la cobertura,
• escriba cada archivo individual para publicarlo en npm.

Ahora, ¿por qué ayudarían estos (en combinación unos con otros)?

Escribir las pruebas primero asegura que pienses en la “API” de lo que quieres. Digamos que está escribiendo un servicio de usuario. Vas a:

• buscar usuarios y detalles del usuario,
• buscar usuarios
• seguir y dejar de seguir a los usuarios,
• comentar las publicaciones.

Ahora, ¿puedes detectar el problema allí? Un servicio de usuario no debería ser realmente sobre comentarios o publicaciones, ¿verdad?

Entonces, al escribir las pruebas primero, sabes lo que quieres que haga tu código. Es probable que escriba algo como esto en sus pruebas: userService.findByUsername (nombre de usuario), userService.search (searchTerm), userService.follow (usuario, seguidor); .

Ahora ya sabe cómo se verá su código para el extraño.

Y aquí viene la parte de “escribir cada archivo como si fuera para el módulo npm”. Ese servicio falso anterior tiene una API clara, y casi puede copiar y pegar esas pruebas en README , sección de documentación . También desacoplas tu servicio de usuario con cualquier otra cosa; eso significa que más adelante, tu código de servicio de usuario seguirá funcionando sin importar lo que hagas con commentsService o postsService. Realmente te obliga a hacer una cosa y concentrarte en esa única cosa.

Hay beneficios adicionales a esto. Después de un tiempo, comienza a notar patrones en su código, y cuando ve algunas cosas escritas con frecuencia, lo separa en su propio “módulo” (independientemente de si lo publica o no, y eso ayuda a reutilizar el código. Por ejemplo, frecuentemente incluso tener un repositorio separado real y módulos de espacios de nombres (por ejemplo, @ zladuric / my-project-utilities) para estas cosas comunes.

Para agregar a la respuesta excepcional de Corey, aquí está mi lista de cosas:

• Ten en cuenta las limitaciones. Una aplicación node.js que pretendes ejecutar en producción requiere una base sólida como una roca para evitar que se bloquee mientras tomas el sol junto al lago. Cualquier excepción que se pierda, cualquier error lanzado por cualquier módulo que incluya puede morderlo en cualquier momento.
  Esto es principalmente un problema de arquitectura, pero también nos lleva al siguiente punto …
• ¡Prueba todas las cosas! Hay una multitud de posibles errores para los que debe estar preparado. Y mientras más pruebas tenga, más estable es el contrato que forma: cada vez que cambie su código, ejecute las pruebas para asegurarse de que no fallen ahora.
• Abstenerse de usar módulos npm cuando puede hacerlo fácilmente usted mismo. No quiere decir que deba reinventar la rueda, pero a) le sirve para poder codificar una funcionalidad específica usted mismo cuando la necesita, yb) ese es su código, su control y un paquete menos para realizar un seguimiento de las actualizaciones.
• No te obsesiones con la optimización prematura. Lo más importante es que su código sea legible y mantenible. Mirando hacia atrás, siempre hay cosas que podrían haberse escrito de manera más eficiente, en menos líneas, o excluidas por completo. Está bien, puedes arreglar eso más tarde. Pero debe evitar gastar el dinero de un cliente para perfeccionar ese único método.

Si está buscando trucos reales que mejoren instantáneamente su código, lo siento, no. Los aprenderás en el camino mientras acumulas experiencia.

Para Corey: lo siento si algunas cosas parecen (o hacen) reformular cosas que ya has escrito, eso no es intencional 😉

Para mí, el truco o concepto más increíble en realidad es el almacenamiento local de continuación.

CLS es un paquete para acceder al objeto de solicitud / respuesta exprés actual desde un punto donde no es fácilmente accesible.

Funciona como thread-local-storage en la programación de subprocesos múltiples como java. Como nodejs es de subproceso único, admite eventos / devoluciones de llamada en lugar de subprocesos múltiples. Y para lograr lo mismo, utiliza el concepto de ** espacio de nombres **.

Node.js es asíncrono y utiliza un bucle de eventos para administrar la asincronía, AsyncListener le permite escribir software que puede mantener la información en todas las devoluciones de llamada.

Y aquí está el artículo completo.

NodeJS: ¿Almacenamiento local de continuación o almacenamiento local de subprocesos? – Array151

y otros conceptos que te pueden interesar

forever node.js (nunca lo decepcione, mantenga vivo el servidor)

Nodemon: Code Watcher y Auto-Reload, nodemon, node.js, npm

package.json: diferencia entre tilde (~) y caret (^) – Array151

En primer lugar, lea Javascript: las partes buenas, porque es realmente bueno y lo pondrá en la mentalidad para evaluar las decisiones que está tomando en Node.JS.

En segundo lugar, asegúrese de que el producto que implemente tenga los ganchos adecuados para la supervisión. Hay muchas herramientas para esto, elija una a su gusto. Pero asegúrese de tener algo que le diga qué está haciendo su software.

Mira tus versiones. Cuando usa NPM, es típico importar una biblioteca. Una vez que las cosas funcionen, regrese a ese archivo JSON y tome una instantánea del número de versión. Desea saber exactamente lo que está implementando.

Además de eso, considere algún tipo de “envoltura retráctil” para los archivos que envía. No solo envíe un repositorio de github y llame a la npm update en cada servidor web que esté ejecutando. Asegúrese de saber qué código se está ejecutando en cada servidor.

Lo # 1 que creo que distingue a los desarrolladores elegantes son aquellos que minimizan cuidadosamente sus dependencias.

He visto demasiadas bibliotecas dependiendo de Lodash. Demasiados módulos que extraen 20 dependencias adicionales solo para copiar algunos archivos.

Sí, estos paquetes facilitan las cosas. Pero sus usuarios están tratando de usar su paquete, no un conglomerado de 50 otros módulos.

No reinventes la rueda. No se preocupe si necesita usar una dependencia. Pero por favor, mire de cerca de lo que depende. Es mejor pasar un poco de tiempo desarrollando la funcionalidad de forma nativa que arriesgarse a otro incidente de la plataforma izquierda.