En este podcast trataré de responder la pregunta recurrente: ¿Cuál es la mejor metodología, arquitectura o patrón de diseño para mi proyecto?
Material Relacionado
Borrador del podcast (no es idéntico al audio)
Es curioso que cada semana vea uno o dos temas recurrentes en las comunidades de desarrollo o quizás cada semana uno o dos temas capturan mi atención, quien sabe. De cualquier forma esta semana he visto a varios programadores hacer preguntas en las redes sociales del tipo: ¿Cuál es la mejor arquitectura que puedo usar para mi proyecto X? ¿Cuáles son los mejores patrones que puedo aplicar con el framework Y? Y así sucesivamente.
Es bien complicado responder a esta pregunta. Cada proyecto es diferente y por lo tanto tendrá requerimientos diferentes donde apliquen patrones y metodologías o formas de desarrollo diferentes.
Si un desarrollador senior crea 2 proyectos, lo hará de 2 formas distintas a menos que ambos proyectos sean muy similares.
No hay peor forma de comenzar un desarrollo que agregando un sin fin de capas o abstracciones solo porque «es la manera correcta de trabajar». No existe una arquitectura, patrón de diseño o estructura que aplique y sea adecuada para todos los casos.
Hace un par de años sostuve una pequeña conversación en Twitter con Taylor Otwell, el creador del framework Laravel. Laravel es, para el momento de grabar este podcast, el framework más popular de PHP y uno de los frameworks de backend más populares en general.
La conversación se trataba sobre si Laravel era o no MVC. La respuesta de Taylor fue “no realmente”. Laravel comenzó con un framework para web orientado hacia el patrón de arquitectura MVC o, mejor dicho, la adaptación de MVC que muchos programadores visualizaron para la web, pero afortunadamente Laravel se alejó de este patrón en su versión 5. De hecho si buscas MVC en el sitio de Laravel no encontrarás una referencia a estas 3 siglas. ¿Por qué? Porque como el mismo creador del framework Laravel lo dijo, MVC es un término limitante en la forma en que es aplicado a desarrollo web y no hay una forma de encajar todos los aspectos de aplicaciones web robustas en una de esas 3 letras.
Por ejemplo en una aplicación de Laravel, tienes rutas para asignar URLs a ciertas acciones dentro de controladores. Los controladores son la C en MVC pero ¿Qué hay de las rutas? De igual forma tienes Middleware que permiten filtrar y/o modificar peticiones y respuestas antes de que éstas sean procesadas por controladores ¿Qué letra son los middleware? No la M, la M se refiere a los modelos. Pero los modelos hacen referencia a la interacción con la base de datos ¿En dónde se ubican los eventos o si por ejemplo tienes una clase que obtiene información de AWS? La V en MVC se refiere a la vista, pero ¿Qué sucede si estás escribiendo un API que no tiene vistas? Etc. etc.
Yo creo que MVC se hizo popular no por ser una buena manera de estructurar nuestras aplicaciones sino porque nos dio un lugar común y seguro para hacerlo. Por eso hay tantos desarrolladores que aún se aferran a MVC o que ahora están confundidos.
Pero haciendo referencia una vez más a Taylor, él dice no haber visto una arquitectura que sea maravillosa para el desarrollo web y sólo nos pide que construyamos aplicaciones de manera razonable.
Quizás a este punto te preguntas exasperado ¿Qué rayos significa eso? ¿Entonces qué puedo hacer?
Estudiar y practicar una y otra vez. Leer libros y artículos, ver video tutoriales, escuchar podcasts como éste, leer código, practicar muchísimo. Es importante que selecciones material que sea de buena calidad, si lees código mal hecho o escuchas una explicación pobre de cierto tema, es posible que dicho material te envíe en la dirección contraria a la que deberías ir. Por eso frunzo el ceño cada vez que alguien recomienda a YouTube como la academia número 1 de aprendizaje. Porque aunque sí se puede encontrar muy buen material buscando en YouTube, hay que saber buscar y discernir, no hay nadie en YouTube filtrando ni ordenando el contenido de acuerdo a su calidad y precisión. Aprender sólo de YouTube es el equivalente a reemplazar una visita al médico con una búsqueda en Google, sí, quizás Google te va a sacar de apuros para tratar una pequeña quemadura, pero puedes meterte en graves problemas si toda tu salud depende de los resultados que arroje el buscador.
Muchos programadores te dirán durante tu búsqueda que siempre hay que programar de cierta manera, por ejemplo, siempre hay que aplicar el patrón repositorio para el acceso a los datos, en vez de usar directamente el modelo desde el controlador, siempre hay que usar un repositorio y dentro del repositorio interactuar con el modelo, pero el repositorio no puede inyectarse directamente sino que tienes que crear una interfaz y luego un repositorio que implemente dicha interfaz por ejemplo PostMysqlRepository implementa la interfaz PostRepository y luego tienes que enlazar uno a otro en un Service Provider (si estás trabajando con Laravel) y esa es la única forma de trabajar. Porque pasado mañana el cliente te dirá que ya no quiere usar MySQL sino MongoDB y si no trabajas de esa manera tendrás que rehacer una gran parte del desarrollo. Pero si lo haces de esa forma entonces sólo tendrás que crear un PostMongoRepository que implemente PostRepository, luego cambiar la configuración del Service Provider y todo funcionará como antes. Fácil, no? La verdad que no. La realidad es que primero solo en uno de cada 10 o 20 proyectos necesitarás cambiar el motor o tipo de base de datos, segundo, aunque crees todas estas interfaces es muy probable que a la final debas hacer muchos cambios porque por ejemplo las características de MongoDB son distintas a las de MySQL y tercero, estarás complicando y retrasando el desarrollo de otros 9 o 19 proyectos sin necesidad.
Si el cliente te está contratando para crear un sitio web con una sección de contactos y un catálogo de productos ¿De verdad necesitas repositorios, interfaces y todo eso? Yo he, de hecho, realizado el proceso contrario un par de veces, eliminar todos esos repositorios e interfaces y simplificar el código de manera que sea más simple de leer, porque la realidad es que cada abstracción que agregues hará el código un poco más difícil de leer y seguir y aunque muchas veces necesitamos esas abstracciones, debemos analizar antes de cada decisión su equilibrio entre costo y beneficio.
La buena noticia es que siempre puedes refactorizar, siempre puedes cambiar el código para adaptarte a los cambios y solicitudes del cliente cuando dichas solicitudes sean reales y presentes, lo otro es tratar de predecir el futuro y nosotros somos programadores, no adivinos.
Ahora a nosotros nos da pánico cambiar código que ya funciona y esto se debe a que la mayoría no escribimos suficientes pruebas automatizadas durante el desarrollo. Para poder hacer cambios en el proyecto es importante utilizar una metodología de desarrollo con pruebas automatizadas. Hey! Aquí hay una metodología que casi siempre puedes utilizar. El problema y la razón porque esta metodología ha sido de una adopción más lenta que MVC es porque esta metodología requiere de más horas de estudio y dedicación que comenzar a crear archivos en 3 carpeta. ¿Cómo escribir pruebas? ¿Qué pruebas debo escribir? ¿Cómo adaptar pruebas a este sistema que no tiene pruebas? Todas estas son preguntas y dudas comunes que nos frustran, pero que afortunadamente ya tienen respuestas, no en Twitter, no en Facebook, sino en libros y cursos profesionales…
Así que si quieres mi consejo para seguir mejorando, creciendo y convirtiéndote en un profesional es que pases menos tiempo en las redes sociales y más tiempo leyendo, estudiando y practicando, sé que no es el consejo más sencillo de hacer pero sé que a la larga es uno que te rendirá verdaderos frutos y que la próxima vez que se te presente la oportunidad de desarrollar un proyecto, de cualquier envergadura, las respuestas llegarán por si solas o como mínimo ya sabrás dónde buscar y cómo discernir entre todas las arquitecturas, patrones y metodologías que existen, quien sabe, quizás hasta puedas crear una nueva.
Regístrate hoy en Styde y obtén acceso a todo nuestro contenido.
