Reusabilidad

Niveles de reusabilidad:

• Primer nivel (Clases y funciones) --> Ingredientes de la lasagna

• Segundo nivel (Patrones de diseño, ¿Cómo usar las funciones y de que forma se vana conectar?) --> Receta de la lasagna

• Tercer nivel (Frameworks, convenciones ¿Como manejar las rutas, peticiones, etc.) --> Lasagna congelada de tu preferencia.

Reusabilidad

• Ventajas: Reducción de costos y de tiempos para lanzar un producto, libera recursos para tareas más cruciales.
• Consideraciones: Eliminar la duplicación y crear una abstracción (DRY)
  • Algunas partes no deberían ser abstraídas
  • el código pude volverse innecesariamente complejo

Niveles de reusabilidad con una lasagna:

• Primer nivel Ingredientes de la lasagna → Clases y funciones
• Segundo nivel Receta de la lasagna → Patrones de diseño (¿Cómo usar las funciones y de que forma se van a conectar?)
• Tercer nivel Lasagna congelada → Frameworks, convenciones (¿Como manejar las rutas, peticiones, etc.)

Ejemplo de reusabilidad:

Servicios que dependen de un módulo, pero si ese módulo cambia hay que cambiar todos los servicios que lo usan.

Ahora ese servicio usa una interfaz que usa ese módulo, por lo que si cambia el módulo solo cambiamos la interfaz y no todos los servicios.

El ejemplo de la abstracción utilizada en esta clase me recuerda mucho a los principios SOLID. Dentro de estos principios, hay uno muy famoso que es el de “Open-Close principle”.
Lo que este principio quiere decir es que el código debería estar abierta a la extensión, pero cerrado a la modificación.
.
Si nosotros tenemos código que ya existe y funciona, al momento de agregar una nueva funcionalidad en el software, este no debería ser modificado, sino más bien, debería ser fácilmente extensible.
El único pequeño gran problema, es que no es tan sencillo como parece. Una de las técnicas utilizadas es crear una abstracción como la vista en esta clase.
.
httpGateway es un módulo del cual dependen más de un servicio que utilizan servicios http. Si nosotros queremos agregar una nueva funcionalidad que utilice http. Podemos agregar un nuevo método a httpGateway. Este nuevo método va poder ser usado por todos los servicios que consumen a nuestra abstracción.
De esa forma el código es más fácil de extender, sin la necesidad de ser modificado.

Profesor! este curso esta buenísimo

¿Qué será mas grave/común que cambie?

A mi parecer, La abstracción es lo que mas comúnmente puede y deberá cambiar. Así mismo, el módulo puede cambiar por motivos de solución de bugs, extensión de sus funcionalidades u optimización lo cual puede ser grave si no utilizamos una abstracción propia de nuestro proyecto para controlarlo.

Reusabilidad:

• Reduce: Costo y tiempo
• Beneficia a otras áreas
• Innovaciones e iteraciones
  pero…
• No siempre es ideal
• Puede generar complejidad

Niveles de Reusabilidad:

• Primer nivel: Clases y funciones (la expresión mínima de un programa)
• Segundo nivel: Patrones de diseño (pueden variar)
• Tercer nivel: Frameworks (facilitarse la vida)

La reusabilidad puede ser muy perjudicial cuando se lleva al extremo, por ejemplo, el tema de tipado de Typescript es muy común encontrarse dilemas si solo copiar tipos o abstraerlos para hacerlos reusables, lo cual se vuelve muy complejo fácilmente, debido a que es fácil caer en el error de hacer sobre ingeniería a dar tipado correctamente, en lugar de centrarse en el código como tal.

solo un comentario que se me ocurrió

• comienzas desde lo mas básico. Como la materia prima -> variables,funciones
• lo agrupas en elementos que puedes reutilizar -> clases
• y esos elementos puedes acomodarlos para buscar solucionar un problema -> patrones de diseño
• y finalmente un conjunto de soluciones puede formar una herramienta nueva -> frameworks

Soy nuevo en el mundo de desarrollo y trabajo sobre un software ya en produccion y siempre que tengo una nueva asigancion lo primero que hago es tratar de encontrar como reutilziar codigo ya existente y si no es posible lo neuvo que desarrollo lo hago pensnando DRY. debido a que tienod mucho a fallar en esto.

Dios mío esto es genial, desde esta clase empieza lo bueno.
Los cursos de patrones de diseño deberían estar antes de los de frameworks, pero como ya no existen las antiguas escuelas de platzi supongo que es difícil acomodar cursos dentro de las nuevas escuelas de platzi que contienen rutas.

Lo mismo está pasando con los cursos de algoritmos, y estos cursos de patrones de diseño igual, no están en ninguna ruta y al menos que llegues a buscarlos directamente no te das cuenta de que existen.

Lo cual a su vez limitan su alcance, y como ya paso con otros cursos, si no llaman la atención, no se seguirán produciendo, como los cursos de C, A un nuevo curso de CSS también le pasa.

Genial el curso, ha despejado muchas dudas

Esa pregunta del final de la clase me hizo plantearme mi existencia entera…
Yo facilmente hubiese hecho una abstraccióna sí como la de HttpGateway, pero, es mucho más probable que mi abstracción cambie antes de que lo haga el modulo http.

Si si la he utilizado desgraciadamente en el desarrollo para los jefes que imponen sus deadlines a veces no es posible pues lo importante es salir en tiempo con pruebas funcionales.

Se que es una mala practica pero prefiero tener código repetido que funciona a una método que no.

Creo que se me dificultó un poco con el ejemplo de la lasagna

¡Hola!

Algo de lo que he aprendido en toda mi ruta de aprendizaje es que una buena práctica puede ser relativa, puede depender del contexto o puede depender del programador, el principio DRY es un principio que he tratado de aplicar en mi código desde que empecé a programar, pero hay algo que es muy cierto y es, no siempre puede ser bueno abstraer, con tantas abstracciones le añadimos mucha complejidad al código, por esta razón DRY es un principio y no una regla, se recomienda que se aplique pero habrán ocasiones que no sea bueno aplicarlo, lo que más importa al final es no añadirle una complejidad innecesaria a nuestro código, el código que escribimos debemos de escribirlo para que en un futuro alguien más o nosotros mismos lo lleguemos a leer, por lo que debemos de tener un código limpio, organizado y que se auto-explique sólo sin tanta complejidad.

P.D.: Paso a recomendarles un curso en udemy que trata también este tema: Principios SOLID y Clean Code, no es muy costoso, cuándo lo compré, me salió por 10 USD apróximadamente y se complementa muy bien con este curso.

KISS over DRY

(keep it simple)