Fundamentos de Frontend

El capítulo de frontend de Toss publicó un sitio donde presenta los criterios que considera para un buen código frontend.

• Explica con base en TypeScript, que es usado principalmente por desarrolladores frontend
• Presenta buenas prácticas desde cuatro perspectivas: legibilidad, predictibilidad, cohesión y acoplamiento
• Ofrece ejemplos usando librerías que se utilizan con frecuencia en frontend real

4 criterios

1. Legibilidad
   La legibilidad (Readability) se refiere a qué tan fácil es leer el código. Para que el código sea fácil de modificar, primero debe poder entenderse qué comportamiento tiene.

2. Predictibilidad
   La predictibilidad (Predictability) se refiere a qué tanto los compañeros con quienes colaboras pueden anticipar el comportamiento de una función o componente. El código con alta predictibilidad sigue reglas consistentes, y solo con ver el nombre de la función o componente, sus parámetros y su valor de retorno, se puede saber qué hace.

3. Cohesión
   La cohesión (Cohesion) se refiere a si el código que debe modificarse se modifica siempre en conjunto. El código con alta cohesión no provoca errores inesperados en otras partes aunque se cambie una parte del código. Esto se debe a que está estructuralmente respaldado para que las partes que deben modificarse juntas efectivamente se modifiquen juntas.

4. Acoplamiento
   El acoplamiento (Coupling) se refiere al alcance del impacto cuando se modifica el código. Un código cuyo impacto es limitado al cambiarlo, de modo que puede predecirse el alcance de los cambios, es un código fácil de modificar.

[savvykang]

Me pregunto por qué se usa el archivo como la unidad mínima de gestión para componentes y hooks. Supongo que puede deberse a un soporte insuficiente del IDE o del tree shaking, pero no estoy seguro, así que quisiera preguntar.

Mientras leo código, cuando veo archivos con una sola función o archivos index.ts que solo tienen sentencias import y export, siento que aumentan las cosas que hay que recordar. En comparación con mezclar hooks y componentes dentro de un solo archivo, me parece una organización que eleva la carga cognitiva más de lo necesario. Aun así, ¿hay ventajas o razones para usar ese tipo de estructura?

[firea32]

Por lo general, la gran premisa de lo que se considera “buen desarrollo” en contextos como este es que hay muchos desarrolladores trabajando.
Que, como mencionas, aumente la cantidad de cosas que hay que recordar = significa que uno mismo tiene la responsabilidad sobre todo el proyecto, pero
en un entorno con muchos desarrolladores, cada quien desarrolla solo la parte que le corresponde.
Si surge un problema, basta con revisar esa parte; no hace falta revisar todas las partes relacionadas.
Visto de cierta forma, diría que eligieron la productividad en lugar de una optimización extrema.

[savvykang]

Como mencionaste, en un entorno donde es posible dividir las responsabilidades del trabajo con más detalle, el contenido del texto es una elección acertada. Creo que sería un artículo más completo si explicara los trade-offs al separar el código y los criterios para tomar esa decisión.

[beenzinozino]

En mi caso, cuando hago desarrollo frontend, las razones por las que uso archivos como la unidad mínima de gestión para componentes o hooks son las siguientes.

1. Facilidad para hacer pruebas.

Es decir, es más fácil hacer corresponder una prueba unitaria con un módulo.

Creo que en el desarrollo frontend predomina un paradigma basado en funciones puras, y si existen varias funciones dentro de un mismo archivo, se vuelve difícil lograr una correspondencia 1 a 1 al escribir pruebas unitarias.

Si, por ejemplo, en un solo archivo llamado remark-plugin.js existen varias funciones utilitarias, ¿cómo habría que escribir las pruebas? ¿Sería una buena elección crear un solo archivo remark-plugin.test.js y escribir ahí, de forma conjunta, las pruebas para varias funciones utilitarias?

En una situación así, si se crea un directorio llamado remark-plugins y dentro de él se separan las funciones utilitarias una por una para escribir sus pruebas, creo que después se pueden definir con más claridad los roles de cada función, y también hay ventajas como un seguimiento mucho más limpio de los commits en GitHub.

2. Estructuración de directorios

Los module bundlers, como commonjs en desarrollo de servidor o webpack en el cliente, suelen designar el archivo index.js como el archivo de entrada de cierto directorio. Esto también es, en parte, porque es una convención que se viene usando desde hace mucho tiempo y simplemente se adopta tal cual.

Sin embargo, creo que la razón más importante es que, en el paradigma de funciones puras de la programación funcional, no se debe depender de estado externo, así que si muchas funciones están concentradas en un solo archivo, aumenta la probabilidad de cometer el error de referenciar estado externo. (Puede ser útil pensar en por qué apareció el module scope en ES6).

3. Facilidad para rastrear commits.

En lo personal, me parece que cuando las funciones utilitarias están divididas en archivos separados, en lugar de mezcladas dentro de un mismo archivo, seguir el historial de commits se vuelve mucho más sencillo.

Cuando se agrega una función o se corrige un bug en algún módulo, puedes concentrarte solo en ese módulo sin necesidad de revisar otros.

---

Mientras escribía, el texto se fue alargando y terminó quedando un poco desordenado. (Todavía siento que mi comprensión sobre tree shaking es limitada, así que prefiero no extenderme demasiado sobre eso...) Claro que lo que digo no necesariamente es la respuesta correcta, así que me gustaría que lo tomaran solo como referencia.

[thkimdev]

Está bueno.

[illiil1lii]

Está muy bien escrito y se lee con mucha fluidez. Lo recomiendo.

[tsboard]

¡Gracias por compartirlo! Yo también debería leerlo con mucha atención.

[bbulbum]

Aunque está escrito específicamente para FE, creo que son ideas muy útiles para aplicar al software en general. Gracias por compartir tan buenos insights.