Italo Morales Fantone

🎉 Single Responsibility Principle en , todos saben que soy PHPero 👏 pero siempre hago experimentos en otros lenguajes para aprender un poco más, o tratar de hacerlo.

El punto es que al principio, puedes hacer que todo el código esté en una sola clase, pero no lo dejes así porque esto viola dicho principio.

Pensar en SOLID (o al menos la S) te hará dividir esta clase en clases más pequeñas y específicas, como ➕ `PaymentValidator`, ➕ `PaymentProcessor` y ➕ `PaymentRegister`, cada una por supuesto con su propia responsabilidad y no en una clase gigante llamada `Payment`.

😀 Esto nos ayuda a pensar en resolver el problema y luego en la implementación del principio de responsabilidad única.
🎉 Dividir las responsabilidades en clases específicas hace que el código sea más fácil de leer, testear, mantener y escalar.

Visita mi blog en https://fullstackexperience.com/blog

Principios SOLID 

Aquí es donde el gran Robert C. Martin es protagonista, él los definió y son clave para crear un código flexible, reutilizable, fácil de entender y de mantener.

🙂 Single Responsibility Principle: Cada clase debe tener una única responsabilidad, objetivo o propósito, lo que facilitará su comprensión e implementación de testing. 

🎉 Open/Closed Principle: Toda clase debe estar abierta a su extensión, pero cerrada para su modificación, esto permitirá añadir nuevas funcionalidades sin alterar el código existente. 

👍 Liskov Substitution Principle: Este concepto es un poco más complejo porque es difícil de imaginar al principio. Pero piensa que los objetos de una clase hija (derivada) deben ser capaces de reemplazar a los objetos de su clase padre o base sin afectar el funcionamiento o comportamiento.

👏 Interface Segregation Principle: Este principio nos dice que es mejor tener varias interfaces pequeñas y específicas que una sola interfaz general, grande o masiva.

 

➕ Dependency Inversion Principle: Las clases deben depender de abstracciones, no de implementaciones concretas. Esto reduce el acoplamiento y mejora la flexibilidad. En la práctica significa que debemos inyectar una interfaz o clase abstracta y no una clase concreta directamente.

Programar mal es un atajo, vas a ver un avance increíble pero luego de unos meses ya no habrá avance, o habrá muy poco avance.

Como resultado, si no estamos atentos, entonces dicho código se convierte en un desastre que es cada vez más difícil de mantener.

Es una metáfora perfecta para ilustrar lo que sucede en proyectos de programación cuando dejamos pasar pequeños problemas sin resolver.

Imagina por un momento un código mal estructurado o un pequeño error que decidimos ignorar porque de momento "no es tan importante"...

Al principio parece que no es gran cosa, pero con el tiempo, esos detalles pueden desencadenar una reacción "como efecto dominó" que deforma todo el proyecto.

Testing 🚀 su principal objetivo es mostrar el resultado de los cambios actuales y que estos no estén dañando lo anteriormente construido.

En pocas palabras, garantizan que el proyecto aún funciona bien 🙂

¿Cómo puedes crear un código que sea sostenible y mantenible en el tiempo?

Es una gran pregunta, te sorprenderá saber que escribir código es solo el comienzo (y nosotros solo nos enfocamos en ello).

Precisamente porque mantenerlo, editarlo, ampliarlo y optimizarlo es lo que realmente define a los proyectos exitosos a largo plazo.

Aquí es donde entran en juego dos de los pilares más importantes:

1️⃣ Los patrones de diseño
2️⃣ Los principios SOLID

Chatgpt me ha ayudado muchísimo, lo uso tanto que ya detecto automáticamente cuándo lo usan en emails o publicaciones de blog.

💫 ¡No se trata de copiar y pegar!

Lee, aprende, analiza, luego edita y expresa tus ideas💡

Copiar, pegar y enviar no está tan bueno 🤔

El testing es la clave para controlar la evolución 🧬 del código. Pero poco a poco, es decir, de manera gradual.

La idea es evitar cambios impulsados por "ideas 💡 brillantes".

🤜🏼💥🤛🏼

🌟 La idea es escribir un código que te haga sentir orgulloso [•••] todos los días.

💫 Para ello debes escribir tests y alcanzar cada vez un código más genérico.... La evolución en producción debe ser clara y flexible.

👉🏼 Un buen profesor enseña aquello que es realmente útil.
👉🏼 El conocimiento que transmitimos debe ser aplicable.
👉🏼 El éxito es que dichos conceptos se conviertan en herramientas.

¿Estás hablando demasiado?
¿No hay espacio para la práctica
Elimina esa clase 💥

En los últimos años he leído mucho sobre la creación de productos y emprendimientos, y la mayoría de los consejos apuntan hacia construir algo desde cero.

"Trabaja en tus sueños y no en los de otros" 😜

Esta es una ruta válida, pero también creo que deberíamos normalizar la idea de integrarse y aportar valor a un equipo ya existente 🤷🏻‍♂️

Por falta de conocimiento en su momento, me enfoqué en producir, generar capital y emprender por mi cuenta varias veces. Sin embargo, con el tiempo, descubrí que me ha ido mejor siendo útil dentro de grupos consolidados.

Aunque siempre tengo ese deseo de emprender, no creo que lo mejor sea recomendar a otros renunciar de inmediato a sus empleos.

👉🏼 Este es un camino personal.
👉🏼 Cada uno descubre su lugar y lo que funciona mejor.

Para emprender hay que estudiar 🎒 y aprender, en mi caso solo estudio programación y cómo enseñar.

👉🏼 Todo aquello que no pueda ser demostrado en la práctica es falso

Los Facades en Laravel son ideales cuando necesitamos acceder a un servicio sencillo y global, estos ofrecen una capa de simplicidad brutal 🚀

Pero ⚠️ "no crees un Facade por servicio", no abusar es fundamental 🤨🫣

La moderación es clave aquí y en la vida 🙂

Ok, atento con esto 📣

Hay una teoría llamada "la teoría de las ventanas rotas" y en programación la usamos como metáfora para ilustrar el caos 🔥

Digamos, pequeños problemas no resueltos que pueden desencadenar problemas más grandes si no se abordan a tiempo.

Dejar pasar pequeños defectos, cosas sin completar o malas prácticas puede crear una cultura de descuido, que nos podrían llevar a que el código se degrade progresivamente 🤷‍♂️

Como dice la teoría, no corregir un pequeño problema puede conducir a un ciclo de deterioro que es más difícil de reparar más adelante, y esto se conoce como "deuda técnica", pero en estos casos "deuda impagable".

Ejemplos:

1️⃣ Código mal estructurado: Si un pequeño componente no sigue los principios de diseño (o ningún principio), dará lugar a que otros componentes se diseñen mal. Sobre todo cuando copiamos, pegamos y luego editamos.

2️⃣ Mala arquitectura: Crear tu propia estructura, no usar ningún patrón, ni regla de diseño puede parecer inofensivo al principio (sobre todo si avanzamos rápido). Con el tiempo estos atajos pueden propagarse, haciendo que la arquitectura general del sistema se deteriore y a largo plazo nadie la entienda, ni el creador.

3️⃣ Problemas no resueltos: Termina lo que empiezas, si las inconsistencias no se corrigen a tiempo, estas pueden generar una cascada de problemas que afectarán la claridad y precisión del proyecto.

En este sentido, la metáfora de las ventanas rotas es una advertencia genial que podemos usar en el mundo de la programación para que, precisamente los programadores puedan abordar rápidamente los problemas pequeños antes de que estos se conviertan en problemas mayores.

Lo veo como una llamada de atención y disciplina, asegurando que el sistema mantenga su integridad y sea fácil de mantener a largo plazo.

Como puedes ver, la clave es garantizar el mantenimiento en el futuro. Allí está el éxito.

¿Conoces esta teoría? Cuéntame de qué trata...

¿No crees que el verdadero héroe (nuestro héroe 👀) es Fabien Potencier?

Gran parte de los frameworks y herramientas profesionales de hoy día se construyen sobre los componentes que él creó...

Hmm 🤔 y quizás Taylor Otwell es el visionario que nos trajo un framework que combina la potencia con la simplicidad.

💫 Laravel hizo que desarrollar con PHP sea algo hermoso y 👔 elegante.

🤜🏼💥🤛🏼