Reutilização de código: até onde vale a pena
Contenido del curso
El software y la ingeniería
Diseño de software
Patrones de diseño
POO
Conclusiones finales
Reutilização de código: até onde vale a pena
Reutilização de código: até onde vale a pena
Contenido del curso
Isabela Osorio Martinez
Alfonso Neil Jiménez Casallas
Irving Juárez
Daniel Basulto
Profesor
Rodrigo Spillere
Roberto Bock
Daniel Basulto
Profesor
Gustavo Adolfo Mejía
Daniel Basulto
Profesor
Pablo Pincay Alvarez
Jesús Loayza Tacuchi
Gerald de Jesús González Zeledón
Daniel Basulto
Profesor
Josshua Fletes
N40 M10
José Josías Padilla Martínez
Daniel Basulto
ProfesorIrving Juárez
Carlos Andres Bohorquez Duran
Juan Daniel Martínez Navarro
Chanel Mariannis Paredes Sánchez
Eduardo Rodriguez Cisneros
Josian Francisco Cáceres Suazo
Marco Antonio Alducin Garcia
Daniel Basulto
Profesor
Karen Edith Moreno Moreno
Diego Reyes Cabrera
Flores Santiago Jose Gerardo
Daniel Basulto
Profesor
Leyla Priscila Marroquín Henríquez
Nicolás Acuña Niampira
Jorge Arias Argüelles
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.
qué coincidencia que hoy comí lasagna :p
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.
Eres bilingue Irving? Porque veo que hablaste en el idioma de la razon :)
Reusabilidad
Niveles de reusabilidad con una lasagna:
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.
Profesor! este curso esta buenísimo
Me halagas Roberto, gracias por tomarlo!
solo un comentario que se me ocurrió
Impecable
me encanta este comentario
¿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.
El modulo podría cambiar por algún actualización en la tecnología, un switch de httpModule a Axios u otra librería si así se requiere, esto es muy común debido a x razones. Si se necesitara cambiar la abstracción para eso estaría la extensibilidad que indica en la capacidad de integrar nuevos cambios sin tener que modificar lo ya existente .
Es correcto Gerald, en promedio es mas probable que se cambien tecnologias que elementos asociados al negocio
Reusabilidad:
Niveles de Reusabilidad:
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.
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.
De acuerdo José!
En ese caso hay que tener en cuenta que TS muchas veces infiere el tipo de dato. Por lo que un tipado "extremo" puede ser en muchas ocasiones innecesario. Buen ejemplo
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 :)
Muy interesante, gracias por compartir tu perspectiva.
Si he tenido temas con la abstracción, pero usando los generics ya me funciona un poco mejor
Desde comencé en Programación Web utilice el concepto de Do not Repeat, ya que usaba Django para programar y fue creado bajo esa prémisa.
Uno de los principales fuertes de los cuales cuenta dicho Framework es el tema de la "escalabilidad", ya que fácilmente un sistema se puede convertir en un módulo debido a que es fácilmente escalable.
Yo creo que la reusabilidad es fabulosa, siempre y cuando esos componentes reutilisables usen bien hechos y que tengan siempre un fin común, por ejemplo, si se utiliza para mostrar una tabla, para mostrar una lista de datos, una galería de imágenes, ¿quien sabe?, pero si que sea bien definido con que fin lo vamos a usar, porque no todo se puede reutilizar.
De acuerdo Marco, la resusabilidad es buena pero no es una bala de plata que nos ayuda con todo mal.
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.
Desde hace unos meses me he empezado a cuestionar lo que representan "las buenas y malas practicas", y esto visto desde la idea sencilla que describe a mi parecer la labor de los que hacemos software que es: lanzar software que funcione, a los usuarios no les importa si usamos patrones o frameworks. Habran veces que no habra pruebas y esta perfecto si eso nos da una ventaja competitiva y acorta el periodo de lanzamiento del producto.
Aun no le doy play, pero pienso que seria mas grave cambiar una abstraccion. porque No por que cambie algo en el modulo se me va a fregar todo en el modulo, sin embargo si use una abstraccion varias veces y la cambio, entonces se va a afectar todos los lugares donde use esa abstraccion.
El tipo de reusabilidad que se caracteriza por el uso de convenciones sobre configuraciones se refiere a los frameworks. En el contexto de la reusabilidad, los frameworks actúan como "lasañas congeladas", ofreciendo estructuras predefinidas que facilitan el desarrollo y evitan la reinvención de la rueda. Esto permite a los desarrolladores centrarse en la lógica de negocio sin preocuparse por los detalles de configuración, lo que ahorra tiempo y reduce costos.
Reusabilidad: Crear código que se puede usar en diferentes contextos.
Principio DRY (Don't Repeat Yourself): Evitar la duplicación de código.
Niveles de Reusabilidad:
Ejemplo: Uso de un HTTP gateway para evitar cambios múltiples si el módulo cambia.