¿Tan difícil es hacer un código limpio y estructurado?
¿A qué viene todo esto? Recientemente siguiendo un curso de CodigoFacilito de desarrollo de una aplicación web la gran mayoría del código está en app.js. Salvo cosas que realmente no pueden estar como las vistas y poco más.
Cierto es, que la aplicación no es nada del otro mundo y no llega a 200 líneas de código, sin embargo, para ser un tutorial, creo que con más motivo se debería estructurar y comentar inline, por no mencionar que la mejor forma de empezar es con buenas prácticas.
Todo esto vino en su día, a que hubo problemas con el módulo de cloudinary y al empezar a depurar donde estaba (lo que sirve en un vídeo puede no servir varias semanas después siendo el mismo código) me desanimé mucho al no saber bien por donde meterle mano y teniendo otras cosas que hacer pues... lo dejé de lado.
¿Por qué es tan difícil hacerlo? Mi opinión, es que los seres humanos somos por naturaleza vagos, perezosos y excesivamente optimistas.
Cuando nos topamos con un proyecto, especialmente si no es muy grande, en el momento en que estamos trabajando en él sabemos el motivo del código y creemos que añadir comentarios o crear una estructura más legible es innecesario, a eso se le une esa cierta pereza, una mala creencia de que podemos pensar que escribir comentarios es perder el tiempo, un tiempo que podríamos estar utilizando en que la aplicación progrese y como no, tendemos a pensar que todo va a ir bien, que la aplicación va a funcionar de primeras y no vamos a tener que depurarla. Realmente no es que creamos que va a funcionar de primeras, sino que esperamos a que así sea para no afrontar la realidad, o que no falle y luego el proyecto pase a otras manos y sea otra persona la que se coma el marrón. Tristemente es así, hay personas que esperan que funcione y luego el que venga detrás se come el marrón, eso sí, una gran cantidad de ocasiones el que viene detrás es nuestro yo del futuro y nos va a odiar por ello.
Estructurar código
Os voy a poner un ejemplo, tenemos por un lado el código original de CodigoFacilito en su GitHub https://github.com/codigofacilito/primera_pagina_node y luego mi versión https://github.com/ShinFDuran/codigofacilito-Node. Realmente, salvo algunos retoques la funcionalidad es la misma.
Sin embargo además de los archivos normales de la versión del tutorial, en mi versión hay otras carpetas:
- controllers: Contienen la gestión de las vistas
- docs: Documentos de los diferentes commits realizados
- models: Modelos de la base de datos
- routes: Gestión de las rutas de la aplicación
En lugar de tenerlo todo en un archivo, hemos separado las capas de vistas, enrutamiento, control y modelamiento de la base de datos. Es decir, en lugar de tener un archivo con 200 líneas de código, tenemos una serie de archivos con una función muy específica y delimitada. A partir de ahí podemos ir testeando y probar los diferentes módulos, lo que inicialmente nos permite una mayor facilidad para localizar el error, pero en el futuro nos permitirá que si queremos cambiar un desterminado aspecto, cambiar únicamente esos archivos, dejando intactos el resto.
Estructurar el código, nos permite además de tener un código más legible una modularidad y poder reutilizar bloques mucho más fácilmente.
Comentarios
Quizás algo que sí es criticable en los proyectos que estoy realizando es la excesiva cantidad de comentarios. Muchos comentarios inline y muchos archivos con información de los commits. ¿Es necesario tanto comentario? Pues la verdad es que no.
A mi modo de verlo, esta gran cantidad de comentarios tiene el fin de facilitar mi autoaprendizaje, el colocar esos comentarios como notas o recordatorios me permite que cuando estoy viendo el código refresco esos conocimientos, que a veces con echar un vistazo a los documentos de los commits entre en contexto y recuerde lo que hice y por qué.
El otro motivo, es facilitar a quienes vean mi código lo que es cada cosa, aun cuando su nivel de conocimiento no sea muy amplio. Una vez tenga soltura y a fin de reducir tiempos o excesivos comentarios, veo importante establecer algunos delimitadores entre secciones, pero la idea es comentar lo que necesite ser comentado.
Por ejemplo, una función que se use a modo de helper, indicar cuál es su objetivo, parámetros o que devuelve, siempre y cuando no sea algo muy evidente. En su momento leí/vi, que un buen código es aquel que no necesita ser comentado, con esto se refería, a que es importante que sea un código claro en cuanto a que las variables deben expresar lo que contienen y las funciones la acción que realizan, una buena elección de nombres puede reducir enormemente la necesidad de comentarios.
Código limpio
Una de las cosas que más me mosquean de JavaScript es que es un código terriblemente feo, en tanto que es muy fácil liarlo de una forma que no se entienda nada, entre parámetros, funciones, callback y otras cosas, se crea un infierno de callbacks y anidamientos que es horrible.
En el futuro, uno de los puntos que tendré que profundizar es en el concepto de las promises para mitigar el "Callback Hell" y preprocesadores como TypeScript o CoffeeScript para mitigar un poco la falta de visibilidad del código.
La clave, es que hay que intentar crear un código limpio, que sea fácil de leer y se vea claramente los ámbitos a fin de disminuir la posibilidad de errores.
Coste/beneficio
Esta es una parte muy importante, porque se entiende a malinterpretar. Seamos realistas, el crear un código estructurado, limpio y comentado requiere más tiempo, pero no es ya tanto el tiempo físico en si, sino el tiempo necesario para tomarlo como un hábito.
La inversión inicial de tiempo en algunos casos puede ser considerable y a eso hay que sumarle el tiempo dedicado a escribir los comentarios. Pero a mi modo de ver, ese tiempo es ridículo en comparación al tiempo que nos podemos ahorrar en el futuro ya sea más o menos inmediato.
El tener un código modular, reutilizable, claro y fácil de testear supone un enorme ahorro de tiempo (y por lo tanto dinero) no ya sólo a medio o largo plazo, sino también a corto plazo. Especialmente en el caso de las empresas, toda empresa que tenga un proyecto a medio-largo plazo debería fomentar esto, porque ayuda a reducir costes posteriores a la vez que lo hace menos dependiente de los trabajadores. Los programadores van y vienen, pero los programas de la empresa siguen ahí y tendrán que irse adaptando según las necesidades y por diferentes formas.
La inversión inicial de tiempo quedará rentabilizada con creces en la mayoría de las ocasiones; el mayor problema a mi modo de verlo es concienciar a los programadores que debemos tener una visión más a medio-largo plazo y unos hábitos más productivos. No solo para nuestro yo futuro, sino para otros trabajadores de la empresa.
Conclusión final
Más allá de todo lo dicho, de los beneficios y ahorros que conlleva adoptar unos hábitos y técnicas, hay algo un poco más rebuscado.
Digamos que es el factor psicológico o anímico, cuando hay un problema que tenemos que solucionar, ya sea un fallo o algunos cambios si vemos un código largo, confuso o mal estructurado, podemos perfectamente entrar en un estado en el que nos desanimemos ante la mala perspectiva que tenemos.
Horas perdidas sólo en ver qué se supone que hacen determinadas funciones o módulos, el intentar descifrar lo que contienen unas variables y estar continuamente usando la opción de buscar para localizar las líneas de código donde están las funciones que hay que modificar. Todo eso produce desánimo y junto a la pérdida de tiempo una bajada en la productividad enorme y una sensación de que avanza poco.
Por contra, un código limpio, en el que de un vistazo podamos saber lo que hace cada cosa, además del ahorro de tiempo en si nos pone en una situación opuesta, en la que nos apetece tocar el código, que hay una sensación positiva de que trabajo va a ser productivo y que va a avanzar rápido.
Ese punto psicológico lo considero muy importante y por eso creo que es necesario crear un código con el que nos guste trabajar, con el que nos sintamos código y que en lugar de maldecir a quien lo creó nos impulse a mejorarlo o aportar nuestro granito de arena. En definitiva, estar en una situación en la que nos apetezca trabajar porque nos gusta lo que estamos haciendo.
