No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Reusabilidad

6/14
Recursos

Aportes 21

Preguntas 0

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

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 鈥淥pen-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.

**DRY (Don't Repeat Yourself)**: Cuando sientas que una tarea se est谩 volviendo repetitiva, por ejemplo una pieza de c贸digo que sientes que la estas escribiendo una y otra vez, para un segundo y considera plantearte si 茅sta tarea se podr铆a facilitar haciendo una separaci贸n que pueda ser reusable en 茅sta y las dem谩s partes en donde se ha implementado. Aqu铆 es donde viene la parte de la **Abstracci贸n**; De lo complejo, captar la escencia o idea principal y reducirlo a algo m谩s simple, adapta ese c贸digo para que pueda ser utilizado en esos diferentes escenarios. Claro que debe haber un balance como lo comenta el profe, esto no significa que abosolutamente todo se tenga que abstraer para ser re-utilizado "por si a caso". Y se preguntar谩 uno, de qu茅 manera puedo hacer esa abstracci贸n? c贸mo puedo saber cual es el mejor acercamiento que puedo tener para cierto problema? es ah铆 cuando debes pensar justo en esos patrones de dise帽o, que son instrucciones que han sido estudiadas y comprobadas para problemas muy comunes en el dise帽o de software. Estoy lejos de ser un experto, por eso estoy tomando este curso, pero les quer铆a dejar este razonamiento m铆o porque si hago retrospectiva en base a mis experiencias trabajando como programador, el estar aprendiendo todos estos conceptos que van mas all谩 de escribir c贸digo como un robot, me hace darme cuenta de c贸mo es que uno interact煤a con todos estos temas en su d铆a a d铆a sin darse cuenta y lo importante que es saber identificarlos, es as铆 como uno va creciendo y pasando de Jr a SSR, y de SSR a SR y as铆 sucesivamente :)

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.

Seg煤n investigo, la reutilizaci贸n de la reusabilidad en exceso o inapropioada si puede ser perjudicail en algunos casos, tales como: * Acomplamiento no deseado. * Sobregeneralizaci贸n. * Perdida de rendimiento.
He tenido ocaciones donde el mismo desarrollo se complica o extiende demasiado, en pro de ser lo m谩s reutilizable posible, cuando la soluci贸n m谩s sencilla tal vez est谩 en medio de "Costo" y "Beneficio" o entre hacerlo f谩cil y hacerlo supremamente reutilizable.
En mi grupo de trabajo sol铆amos decir: Si vas a usar un mismo bloque de c贸digo **m谩s de una vez**, convi茅rtelo en una funci贸n global. As铆 realiz谩bamos a abstracci贸n en un proyecto orientado a funciones. Sin embargo, al ignorar la regla de "m贸dulos que realicen una sola cosa", termin谩bamos con funciones que hac铆an muchas cosas y requer铆an muchos argumentos, lo que les quitaba su atractivo funcional.
Para mejorar ese producto, no es reinventar la rueda, es hacer ese producto mejor, por eso salen nuevos Frameworks y nuevos JS Runtimes

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)