No ajustan el diseño de un componente listo para usar para adaptarlo a la situación. Es al revés. Lo adaptan a la solución que ya tienes, y de esta manera puedes construir mucho más rápido, y estás ahorrando tus fichas de innovación para las cosas que son realmente nuevas y diferenciadoras en tu empresa.
Lo que nos lleva a simplemente resolver el problema, no un problema diferente y más difícil. Lo más difícil de hacer en ingeniería de software es construir una solución genérica, especialmente cuando solo tienes un problema específico. En general, es una buena idea, o más bien, lo diré de esta manera. Cuanto más viejo me hago, más se parece mi code a un proceso muy simple paso a paso. No impresiona a nadie. Es súper aburrido de ver, y personalmente, creo que el mayor cumplido que puedes recibir sobre tu code es cuando alguien lo mira y dice, espera, ¿eso es todo? Sí, eso es todo. Es simple, es fácil de entender y es fácil de mantener.
Porque siempre tienes que rechazar la complejidad. La ingeniería es una lucha interminable contra la complejidad, y a veces eso significa decir no a un architecture astronauta que intenta construir un framework genérico para resolver un problema para siempre cuando solo necesitas, ya sabes, necesitamos enviar este code mañana, ni siquiera sabemos qué construiremos en diez días, y estás tratando de construir un framework. Simplemente soluciona el problema, resuélvelo y continúa.
Esto también significa que, nuevamente, porque comprendes tu dominio, porque tienes propiedad a largo plazo de las cosas que estás construyendo, también puedes resistirte a tu producto, a tus gerentes de producto. Muy a menudo, tienes un requisito que arruina toda la historia y la hace mucho más difícil de lo necesario. Por lo general, puedes resistirte a tu PM y decir, oye, esta cosa está dificultando mucho nuestro trabajo. Y ellos dirán, oh, sí, mierda, en realidad no necesitamos eso, no nos importa. Simplemente elimina ese requisito y ahora puedes usar una solución muy simple.
Y de dónde proviene la mayor parte de la complejidad en un proyecto de ingeniería de software no es el code que estás escribiendo, es la architecture que estás creando. Si piensas en tu code como una serie de cajas interconectadas, las cajas son como tu code, esas son clases, modules, servicios, como quieras llamarlos, y las líneas son cómo se comunican entre sí. Cuanto más conectadas estén estas líneas, más entrelazado se vuelve todo, más complejo es.
Una lección que he aprendido es que siempre puedes cambiar cómo funciona una caja autocontenida. Puedes eliminar todo el code y escribir nuevo code que sea más limpio o mejor o lo que sea, pero es muy difícil cambiar esas conexiones. Y una forma de limitar esa complejidad es organizar tu code verticalmente en lugar de horizontalmente. Entonces, en lugar de dividir componentes, hooks, tipos, utilidades o lo que tengas en tu stack, no sé qué stack usas, pero si en su lugar divides tu code por todo lo que va en un panel de control, todo lo que va en un perfil de usuario, en una lista de tareas, entonces tendrás modules o cajas que no están tan entrelazados. Y son esas APIs claras las que hacen todo más fácil.
Un truco que me gusta usar es utilizar el desarrollo impulsado por tipos o contratos, donde de antemano hablamos sobre cuáles son las diferentes piezas móviles de una historia que estamos construyendo, y luego hablamos sobre cómo van a comunicarse entre sí, y luego todos los que escriben el code tienen la capacidad de construir la implementación interna de la manera que deseen. Desafortunadamente, o afortunadamente, el uso de modules verticales puede significar que tendrás que copiar y pegar algo de code. Y esta es probablemente una de mis opiniones más controvertidas, que reducir la duplicación de code, no repetirte a ti mismo, en realidad es malo. Y siempre que sea posible, debes apoyarte en la separación de responsabilidades más que en reducir la duplicación de tu code.
Comments