Aquí estoy echando el rato últimamente: https://refactoring.guru/ y en un libro de PacktPub. Estoy aprendiendo patrones de diseño de software que es algo que siempre lo he visto como inalcanzable pero la verdad es que me ha gustado mucho.
He de decir que he descubierto un nuevo mundo. Como con muchas otras cosas, trabajar a diario con Magento 2 te obliga a ver cosas que en otras plataformas igual no… Una de las primeras cosas que me chocaron al empezar con Magento era la “rigidez” de hacer las cosas de una cierta forma. Ahora entiendo, una vez peleado y ahora aprendiendo ésto, que son simplemente buenas prácticas para evitar code smells, adquirir escalabilidad, mantenibilidad, etc
Esto es completamente contrario al mundo WordPress, y que no se me malinterprete, no es algo malo. Simplemente WordPress tiene esta forma de trabajar que es más laxa en cuanto a estándares, estilos, formas de hacer las cosas en general. Pero es así adrede, por eso digo que no es algo malo. Es algo que permite a todo el mundo meterse con una curva de aprendizaje muy poco empinada, lo que es muy positivo.
En Magento antes de empezar, ya hay ciertas cosas que te topas con ellas y muchas veces las aceptas sin entenderlas porque de otra forma no puedes trabajar… y como se van acumulando acabas por normalizarlas y no investigarlas. Con el tiempo aprendes y te das cuenta que son buenas prácticas, pero hasta entonces es código extraño que tú lo harías de otra forma.
Qué me ha gustado de estar mirando patrones de diseño de software?
Por supuesto que no pretendo ser capaz de aplicar estos patrones a mi propio código con una gran soltura, aunque sería ideal.
Pretendo ser capaz de identificarlos cuando los vea (esto sobre todo), y no tener esa sensación que todos alguna vez hemos tenido, de leer un código y por un lado sentir que lo entendemos pero por otro lado sentimos que es otro nivel, que a nosotros nunca se nos hubiera ocurrido montar una estructura así. Yo he pensado muchas veces “a mi jamas se me hubiera ocurrido montar esto así… pero la verdad es que funciona de maravilla. La persona que lo ha hecho tiene que ser un crack”.
Ahora veo, que la rueda ya está inventada. El tema está en saber usar ruedas 😉
Y como objetivo secundario, mejoraré mi forma de escribir código, al menos me gustaría ser capaz de identificar que en ese caso se aplicaría tal o cual patrón de diseño. Siempre ocurre que estamos con un desarrollo que no sabemos el motivo, pero que se nos complica, se nos va quedando algo enrevesado, extrañamente complejo y vamos avanzando a duras penas con inseguridad… Seguramente aquí haya un patrón de diseño que optimice lo que queremos hacer.
Esto lo veo como en la música cuando aprendes escalas, tonalidades, armonía en general… cuando vemos a los músicos improvisar, no les viene la inspiración divina y tocan notas que por arte de magia suenan bien. Lógicamente son años de práctica y de estudio, sobre pequeños trocitos de música que suenan bien, sobre determinadas notas que juntas suenan bien, etc.
Actualización: terminado el libro
Muy interesante en todos los aspectos. Me he dado cuenta de una serie de aspectos que pretendo mejorar con el tiempo.
Me he dado cuenta de la cantidad de veces que estropeamos nuestro propio código por no saber aplicar una solución eficiente, cuando vemos que no funciona como queremos o que se nos empieza a complicar y lo resolvemos “como podemos”. Quizás el problema no es estar programando mal la solución, sino que no está eficientemente programada y por ese detalle acabamos con código espagueti. En ese punto conviene parar, refactorizar, resolver ese cuello de botella y continuar.
Me he dado cuenta también que hay código que realiza funciones muy sencillas pero que parece muy difícil de leer, dando la apariencia de que es un código “top” porque no somos capaces de seguirlo. Si no somos capaces de seguirlo con soltura, será seguramente que que nuestro nivel es inferior al necesario para entender el código no? Pues la mayoría de las veces no. Es que ese código está refactorizado ni optimizado, está escrito para funcionar, no para ser entendido y/o mantenido.
He aprendido los múltiples code smells que aplico, unos cuántos sí y yo pensando que eran buenas prácticas 😀 El ejemplo más sencillo: los comentarios. Un code smell simplemente por el hecho de que si necesitas explicarlo con palabras, es que el código no es lo suficientemente semántico por sí mismo, no has extraído métodos, tus variables no son expresivas, no has nombrado métodos autoexplicativamente, no tienes clases que encapsulen complejidad, etc, etc… y por ello ves tu propio código y te pones una nota mental porque sabes que en 2 meses lo leerás y no entenderás que has querido hacer. Y como esa, un montón más.
Conclusión
Así que por supuesto queda un montón por aprender, no considero que sepa refactorizar como toca ni mucho menos. Pero sí que soy capaz en este momento de detectar muchos code smells, buscar por internet la forma de solucionarlo y lo importante, entender cómo aplicar el cambio, eso es lo imporante.