Organización por características de proyecto - Tutorial de AngularJS

Los proyectos grandes generalmente suelen ser un dolor de cabeza por toda la administración y organización de código que vamos a tener. Pero si desde un inicio logramos tener una muy buena estructura, esto se vuelve algo muy sencillo. Por esto podemos dividir todo nuestro proyecto por características del proyecto. Generalmente, cuando tú inicias la administración de un proyecto, tú puedes identificar cuáles son todas las características y tareas que debes cumplir. Eso te puede servir de base para que tengas esta organización. En esta estructura tenemos varias carpetas. Tenemos una carpeta llamada 'lib', que es donde van todas las librerías externas o de terceros. Tenemos una carpeta de imágenes, una carpeta de cascadas de estilo. Generalmente, y ya a este nivel, las carpetas de 'css' y de 'img' pueden ir englobadas en una carpeta llamada 'assets', cualquiera de las dos formas es correcta. También tenemos una carpeta llamada 'dist', que es donde van todos mis archivos para distribución. Cuando trabajamos con algún automatizador de tareas, como es Grunt, me permite estar generando versiones para publicar directamente en esta carpeta. Grunt, ¿qué es lo que hace? Toma toda la información de todo el código que tú estés tirando, lo compila, lo organiza, minifica, hace muchas tareas que tú tendrías que hacer al momento de publicarla, y las arroja directamente a la carpeta 'dist'. Y en la carpeta 'dist' siempre vamos a tener un archivo o archivos que ya podemos mandar a su publicación. Vamos a ver qué hay en la carpeta 'app'. Como ven, aquí ya no le llamamos 'js', ya le llamamos 'app'. Dentro de 'app' vamos a tener siempre nuestro archivo inicial, pero dividido por características principales. Podemos tener primero una carpeta de datos común donde, por ejemplo, aquí podemos trabajar con directivas o filtros, que esas no se repiten, solamente se pueden generar una vez. En el caso del usuario, por ejemplo, vean como tenemos aquí englobadas todas las características. Tenemos el "login", la plantilla del usuario, el modelo del usuario y el servicio del usuario. ¿Qué sucede en este caso? Cuando tenemos todas estas características englobadas de esta manera, me permite localizar fácilmente el archivo que necesito modificar, no tengo que estar navegando entre varias carpetas para encontrar todas las del modelo o todas las del servicio. Esto sucede cuando un proyecto comienza a crecer de una manera hasta desmesurada. En producto, por ejemplo, también tengo lo mismo. Tengo una plantilla, tengo el controlador, el modelo, su servicio. Y también tengo aquí una subcarpeta, que en este caso se llama 'search', para la búsqueda, y dentro de 'search' tengo lo mismo: plantilla, controlador y modelo. Si nosotros hacemos una división por cada una de las características y los convertimos en carpetas, va a ser muchísimo más sencillo poder dar mantenimiento a este código en un proyecto que sea muy grande. Aquí, si tú tratas de aplicar esto en un proyecto que es pequeño, te va a quedar muy sobrada esta organización. En proyectos grandes, esto es lo ideal para poder avanzar y tener bien administrado el código. Siempre es importante considerar que el nivel de complejidad de la organización de proyectos debe de llegar a un nivel razonable. A veces podemos exagerar de entrar en muchas carpetas, pero debemos tener cuidado de tener un cierto nivel. Siempre habrá que ser muy cuidadoso en separar el código de mi aplicación al código de las pruebas. Si yo voy a estar integrando algunas cosas como Karma, o algunas cosas como Protractor, para poder hacer mis pruebas, va a ser importante que estos estén en otra carpeta separado por completo de mi código. Algo que se ha indicado expresamente es tener separadas claramente las librerías externas, porque, aparte de que me permite a mí el mantenimiento más sencillo de mi aplicación, en caso de que exista una actualización de estas librerías de terceros, puedo también hacerla de una manera más rápida. Al final, yo puedo separar todo en un 'view' final, que en este caso lo tengo todo en mi carpeta de distribución. Esto es importante porque así, tal vez, cuando estemos trabajando en un proyecto grande y haya muchas personas incluidas en el proyecto, probablemente solamente sea una la que se encargue de estar haciendo las publicaciones o de estar revisando la calidad del código antes de publicarla. Para esto, como un "tip" extra, si tú quieres probar las características que tienes, te recomiendo dos herramientas para probar tu código de JavaScript. Una de ellas es JSHint y la otra de ellas es JSLint, 1 que ambas te van a indicar si es que hay algún potencial error en 1 tu código de JavaScript o si hay alguna cuestión que es necesario 1 que actualices o que modifiques. 1 Administrar proyectos por características nos da 1 la facilidad de un mejor mantenimiento y una mejor 1 actualización de nuestro código cada que esto es requerido.