¿Mejores prácticas de JavaScript del lado del servidor?

Tenemos un CMS basado en Java y tiene Mozilla Rhino para el lado del servidor JS. Por el momento, la base de código JS es pequeña pero está creciendo. Antes de que sea demasiado tarde y el código se haya convertido en un lío horrible, quiero presentar algunas prácticas recomendadas y un estilo de codificación.¿Mejores prácticas de JavaScript del lado del servidor?

Obviamente, el control del espacio de nombres es muy importante. Pero, ¿qué hay de otras mejores prácticas, especialmente para los programadores de Java?

Fuente

2009-11-30 Petteri Hietavirta

¿Es demasiado tarde para portarlo a Node.js? – Nosredna

¿Cuáles serían los beneficios de usar node.js? –

Acabo de empezar a usar nodejs hoy, y escribí mi primer mini-servidor de documentos (necesario para varias tareas de integración continua donde trabajo). Después de haber visto el rinoceronte antes, prefería mucho la simplicidad, en mi humilde opinión, de nodejs. – jeremyosborne

Aquí hay algunos consejos de las primeras líneas:

como Java, uso docblocks en el estilo/jsdoc Doxygen para funciones
Unidad de prueba. Personalmente, como JsTestDriver, ya que también se puede ejecutar automáticamente desde el servidor de CI.
Use JSLint. Se minuciosa sobre el código incorrecto
Considere utilizar Google Closure Compiler. Se minuciosa sobre el código como JSLint, pero puede ser útil para detectar bloques de documentos pobres, etc.
Asegúrese de que todos en su equipo entiendan cómo funcionan los cierres.De lo contrario, va a dar lugar a dolores de cabeza
Como usted menciona, espacios de nombres son importantes, especialmente si usted quiere que su código funcione bien con otras bibliotecas JS (var myns = myns || {};)
Personalmente, creemos que el uso de una biblioteca que proporciona ayudantes programación orientada a objetos como las clases etc. servicial. Puede usar herencia de prototipos, pero a menudo es un poco más complicado de esa manera.

Fuente

2009-12-03 06:56:52

+1 a usted. Iba a escribir mi propia respuesta, pero la simple verdad es que tocas la mayoría de los puntos en común que, por simples que sean, nadie realmente lo hace. Solo puedo reiterar las viñetas n.º 1 y nº 2, no sé qué le ocurre a los jefes de desarrollador de JS, es como si pensaran porque escriben JavaScript y se han fugado de las buenas prácticas de programación. – jeremyosborne

¿Puedo reiterar la sugerencia de JSLINT y agregar que esto debería reemplazar el paso de compilación en cualquier configuración de integración continua que tenga? Si el código falla JSLINT, no debe registrarse en el repositorio. Algunas personas no están de acuerdo con algunas de las comprobaciones que hace JSLINT, pero debo enfatizar que al integrar JSLINT de esta manera evitará que los errores SYNTAX, que rompen el código que de otro modo funciona, se incorporen en un producto. – Breton

Y asegúrese de usar JSLint y no Javascript lint. Son dos productos separados. No es que javascript lint sea malo, pero no capta los ítems globales implícitos, y JSLINT sí. Tu código no debería tener ningún globo terráqueo implícito que no conozcas. JSLint también proporciona una forma de declarar todos los globales que usted conoce en un comentario especialmente formateado. Tener este comentario a la cabeza de cada archivo .js es increíblemente útil de todos modos, jslint o no. – Breton

Dado que tiene un motor JS en Java, tenga la costumbre de escribir pruebas unitarias para su código JS. Seleccione un estilo de codificación y aplíquelo vigorosamente. Si es posible, use herramientas para verificar que el código se envíe al estilo de codificación.

Fuente

2009-11-30 12:49:05

Me gustaría ver CommonJS (anteriormente ServerJS). Es un trabajo en progreso, pero tienen un sistema de módulos estandarizado con varias implementaciones. Ya hay algunas bibliotecas útiles escritas en la especificación CommonJS, como Narwhal.

Fuente

2009-11-30 20:30:24

Como le gusta decir a Douglas Crockford, JavaScript es el lenguaje de programación más incomprendido del mundo. Aunque muchas personas no lo saben, existe una forma de para codificar en JavaScript. No tengo dudas de que si permites que los desarrolladores de Java comiencen a codificar antes de entender cómo escribir un buen JavaScript, te encontrarás con serios problemas.

Lo primero que debe hacer es asegurarse de que todos hayan leído el excelente artículo de Mozilla, Una nueva introducción a JavaScript (https://developer.mozilla.org/en/a_re-introduction_to_javascript). Uno de los mayores problemas con JavaScript es que hay muchas maneras de hacer las tareas más comunes, y este artículo debería hacer que las personas estén en la misma página. Otra referencia esencial es el trabajo de Douglas Crockford, que incluye JavaScript: The Good Parts.

Otra cosa que recibe una gran cantidad de programadores de Java/C++ es que JavaScript utiliza función alcance NO bloquear el alcance. Esto puede causar algunos problemas muy difíciles. Hay un excelente artículo sobre este tema en A List Apart llamado Binding en JavaScript.

para resumir los temas principales se habla en los recursos anteriores, las diferencias más importantes para aprender son

cómo escribir código orientado a objetos utilizando herencia de prototipos (herencia basada vs.class)
cómo utilizar los cierres y lambdas
cómo utilizar el poder de los objetos dinámicos
cómo escribir código de función de ámbito de

Fuente

2009-12-03 06:36:38