¿Cómo evitar los típicos "errores de lenguaje dinámico"?

42

Recientemente he vertido un par de horas en JavaScript porque quería beneficiarme de la base de usuarios masiva. Al hacerlo, he notado un patrón que la mayoría de las personas atribuyen a los lenguajes dinámicos. Las cosas funcionan muy rápido, pero una vez que su código alcanza un cierto tamaño, pierde mucho tiempo con los errores de tipografía, ortografía y refactorización en general. Errores de los que normalmente me ahorraría un compilador. Y no me haga buscar errores en la lógica cuando acabo de hacer un error tipográfico en otro módulo.

Teniendo en cuenta el increíble seguimiento de JavaScript y otros lenguajes de tipos dinámicos, creo que hay algo mal con mi enfoque. ¿O es solo el precio que tienes que pagar?

Para ponerlo más conciso:

  • ¿Cómo aborda un proyecto de JavaScript (o cualquier otro lenguaje dinámico) con ~ 2000 LOC?
  • ¿Existen herramientas para evitar que cometa esos errores? He intentado fluir por Facebook y JSHint que ayudan un poco, pero no detectan errores tipográficos.
pregunta TomTom 09.05.2016 - 15:43

5 respuestas

37

Hablando específicamente de JavaScript, puedes usar TypeScript . Ofrece algunas de las cosas a las que te estás refiriendo. Citando el sitio web:

  

Los tipos permiten a los desarrolladores de JavaScript usar herramientas y prácticas de desarrollo altamente productivas como la comprobación estática y la refactorización de código al desarrollar aplicaciones JavaScript.

Y es solo un superconjunto de JS, lo que significa que parte del código existente funcionará bien con TS:

  

TypeScript comienza con la misma sintaxis y semántica que hoy conocen millones de desarrolladores de JavaScript. Use el código JavaScript existente, incorpore las bibliotecas populares de JavaScript y llame al código TypeScript desde JavaScript.

    
respondido por el VinArrow 09.05.2016 - 15:52
19

Hay algunos enfoques que pueden ayudar:

Prueba unitaria

Escriba las pruebas unitarias cuando sea posible. Confiar solo en las pruebas manuales o encontrar errores en la naturaleza es ir y venir.

Usar marcos

En lugar de rodar los suyos y arriesgar la introducción de errores, use los marcos establecidos siempre que sea posible.

Prefiere CSS / lenguajes de alto nivel

Donde puedes ceder la funcionalidad a CSS o cualquier lenguaje de alto nivel que estés escribiendo.

Refactor

Refactorizar para reducir la cantidad de código. Menos código = menos lugares para que las cosas salgan mal.

Reutir

Reutiliza el código existente donde puedas. Incluso si el código no es una coincidencia exacta, puede ser mejor copiar, pegar y modificar en lugar de escribir algo nuevo.

IDEs

Los IDEs modernos generalmente tienen al menos algo de soporte de Javascript. Algunos editores de texto también son compatibles con Javascript.

    
respondido por el Robbie Dee 09.05.2016 - 15:56
2

Una herramienta que aún no se ha mencionado es la búsqueda de texto simple para archivos locales o para todo el proyecto .

Suena simple, pero cuando incluyes algunas expresiones regulares puedes hacer un filtro básico a avanzado, por ejemplo. busque palabras ubicadas en la documentación o el código fuente.

Ha sido una herramienta efectiva para mí (además de los analizadores estáticos), y dado su tamaño de proyecto de 2k LOC, que en mi opinión no es particularmente grande, espero que funcione de maravilla.

    
respondido por el mucaho 10.05.2016 - 00:08
1

Actualmente estoy refactorizando varios miles de líneas de código en un gran proyecto AngularJS. Una de las mayores molestias es averiguar el contrato exacto de una función determinada. A veces terminé leyendo la documentación de la API porque los elementos de la respuesta de la API sin procesar se asignaron a variables que pasaron por 6 capas de código antes de ser modificadas y regresaron a través de 6 capas más de código.

Mi primer consejo es diseñar por contrato . Obtenga información específica, produzca resultados específicos, evite los efectos secundarios y documente esas expectativas utilizando TypeScript o al menos JSDoc.

Mi segundo consejo es implementar tantas comprobaciones como sea posible. Seguimos el estándar AirBnB y usamos eslint en todo nuestro código base. Los ganchos de verificación comprueban que siempre seguimos el estándar. Naturalmente, tenemos una batería de pruebas de unidad y aceptación, y todas las confirmaciones deben ser revisadas por un compañero.

El cambio de un editor de texto (texto sublime) a un IDE adecuado (WebStorm) también facilitó el trabajo con el código en general. WebStorm utilizará JSDoc para proporcionar sugerencias sobre los tipos de parámetros esperados y generar un error si proporciona el tipo incorrecto o utiliza un valor de retorno de la manera incorrecta.

En JavaScript, las nuevas características como símbolos y captadores / definidores pueden ayudar a imponer un cierto nivel de calidad agregando aserciones a la asignación de variables (por ejemplo, asegúrese de que el número entero esté dentro del rango o que el objeto de datos tenga ciertos atributos). / p>

Desafortunadamente, no creo que haya una verdadera solución para prevenir errores de lenguaje dinámico, solo una serie de medidas que pueden ayudar a reducir su frecuencia.

    
respondido por el Nicolas Bouliane 18.05.2016 - 13:00
0

Mi respuesta a la pregunta "¿Cómo aborda un proyecto de JavaScript (o cualquier otro lenguaje dinámico para esa materia) con ~ 2000 LOC?"

Desarrollo aplicaciones de formularios PDF. Me acerco a mi proyecto de desarrollo de software JavaScript (independientemente del tamaño del código fuente) utilizando los elementos de red y las anotaciones de Petri. El método no está vinculado a ninguna tecnología de lenguaje de programación en particular. Por lo tanto, se puede utilizar para otros "lenguajes de programación".

Creo un diagrama de la lógica de la aplicación. Para mantener el diagrama ordenado, agrego la mayoría de mis anotaciones a un formulario que uso con el diagrama. Las entradas en el formulario incluyen referencias a propiedades o funciones. Luego escribo el código fuente basado en la información en el diagrama y las entradas en el formulario. El método es sistemático porque cada código fuente escrito se asigna directamente desde el diagrama y las entradas en el formulario. El código fuente se puede verificar fácilmente porque también sigo las convenciones de nomenclatura y codificación cuando escribo el código.

Por ejemplo, he elegido una convención de que todas las funciones son prototipos. Si el rendimiento se convierte en un problema, se puede mejorar declarando las funciones en el constructor. Para algunas propiedades utilizo matrices. Nuevamente, si el rendimiento se convierte en un problema, se puede mejorar utilizando referencias directas.

Yo también uso eval. Esto puede reducir enormemente el tamaño del código fuente. Debido a problemas de rendimiento, uso eval en la parte inicial o inicialización de mi aplicación; Nunca lo uso en la "lógica de tiempo de ejecución", esta es otra convención de codificación que sigo.

    
respondido por el John Frederick Chionglo 25.07.2016 - 00:36

Lea otras preguntas en las etiquetas