Y más y más. Entonces, en ese momento, probablemente terminaremos con un código simple como ese, con 20 líneas de código, a un componente con más, mucho más, como 10 más, 12 más, mucho código, como este. Solo para manejar dos casos de uso. Carga y mensaje de error. El más básico. Y luego, también, ¿qué sucede si quieres agregar más, digamos, en carga, 20%. En carga, 40%, mostrar un efecto de animación diferente, efecto de transición, mostrar un estado de error diferente cuando el mensaje de error, cuando el usuario, digamos, el servidor devuelve 500, 4, algo para el usuario, más y más casos de uso, agregando más y más problemas comenzarán a ocurrir. Y desafortunadamente, esto es muy, muy común. Comenzamos con algo muy pequeño y hemos agregado y agregado y agregado más y más sobre esto. Esto se llama, digamos, construimos un componente en el conjunto de acciones básicas, y cada vez que queremos algo, queremos agregar una nueva función. De acuerdo, genial, funciona. Solo necesitamos desarrollar algo que funcione de manera simple. No hay nada crítico aquí. Pero luego, cuando queremos agregar nuevas funciones, necesitamos agregar más, otra capa encima de lote, encima de él con nuevas acciones. Y porque no hay código perfecto, todavía tenemos correcciones de errores, lo corregimos encima del componente actual. Y luego las nuevas acciones también causarán algunos errores, todavía necesitamos corregir algunos errores. Y surge otra función, se deben manejar otras correcciones de errores, y así sucesivamente. Este enfoque se llama enfoque de abajo hacia arriba. Desafortunadamente, este enfoque es muy común, permítanme decirlo. Y no es tan malo, funciona la mayor parte del tiempo porque nos permite desarrollar algo rápido, rápido y tal vez sucio o tal vez limpio. Pero a lo largo del tiempo, se ha demostrado que es muy, muy complicado.
Por ejemplo, es difícil de mantener. Si tienes un componente central que crece y crece con más funcionalidad agregada, más funcionalidad agregada, más núcleo agregado, se vuelve difícil de entender, difícil de mantener. Y luego, debido a que es difícil de mantener, es difícil de probar cómo asegurarnos de que lo que probamos, lo que escribimos, no rompa algo en algún lugar que no conocemos, no entendemos. A veces dicen que tenemos un componente que es realmente largo, luego tenemos que leer. Pero si es demasiado largo, es posible que no podamos entender para qué casos de uso se está manejando. Y debido a eso, si algo sucede, no podremos entender si cubrimos la prueba o si ocurrió el paso. Eso es difícil de entender. Y en algún momento llegaremos a esto. Y esto no está de nuestro lado. En realidad, sucede en el lado del cliente y causa
Comments