Deuda técnica y refactorización de código

1/24
Recursos

Aportes 15

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

o inicia sesión.

Estoy a full con las rutas y cursos de JS + el reto de #30díasdeJS, y estaba buscando justamente este tema!!! Platzi no decepciona con sus lanzamientos 💛💚

Deuda tecnica y Refactorizacion de código

Nuuestro código debe ser simple y directo, debería leerse con la misma facilidad que un texto bien escrito.

Tipos de deuda técnica:

  • Imprudente y deliberada
  • Imprudente e inadvertida
  • Prudente y deliberada
  • Prudente e inadvertida

¿Cómo pagar las deudas?

Refactorizando el código, esto es mejorar el código sin alterar su comportamiento para que sea mas entendible y tolerante a cambios.Y es importante que el código tenga tests ( units o integration tests ) automáticos que validen el comportamiento del código.( Para no romperlo … 🤣 )

¿Cuándo refactorizar?

Cuando hay código de baja calidad ( duplicación de código, funciones con mas de una acción) o se detecta cualquier otro tipo de code smell ( código duplicado, métodos o clases demasiado grandes y complejos, falta de cohesión entre diferentes partes del código, uso excesivo de condicionales y bucles anidados, por ej.)

Clase 1: Deuda técnica y refactorización de código

Notas

  • Nuestro código debe ser simple y directo, debería leerse con la misma facilidad que un texto bien escrito.
  • Grady Booch Entusiasta del diseño de patrones
  • 1992 fue implementado el concepto de Deduda Tecnica por Ward Cunningham -> coautores del maniesfiesto agil
  • La deuda técnica en si no es mala, se deja para poder liberar un producto mas agíl, con la promesa que se va pagar esa deuda

Tipos de deuda técnica:

  • Imprudente y deliberada -> Se da cuando el desarrollador actua de manera consciente e imprudente, ya que no toma cuenta el factor del error en el código.
  • Imprudente e inadvertida -> No se sabe que se esta dejando un error ya que no se posee los conocimientos
  • Prudente y deliberada -> Se tiene el 100% de consciencia que se esta dejando la deuda y se tiene la promesa que se va a pagar.
  • Prudente e inadvertida -> Es la mas comun, se obtiene cuando se tiene la idea que el desarrollo es el mas eficiente pero se llega a discusión que se podia realizar ciertas mejoras

¿Cómo pagar las deudas?

  • Refactorización -> Es el proceso el cual se pagan las deudas.
  • Refactorizando el código, esto es mejorar el código sin alterar su comportamiento para que sea mas entendible y tolerante a cambios.
  • Y es importante que el código tenga tests ( units o integration tests ) automáticos que validen el comportamiento del código.

¿Cuándo refactorizar?

  • Cuando hay código de baja calidad ( duplicación de código, funciones con mas de una acción)
  • Se detecta cualquier otro tipo de code smell ( código duplicado, métodos o clases demasiado grandes y complejos, falta de cohesión entre diferentes partes del código, uso excesivo de condicionales y bucles anidados, por ej.)
  • Se debe tener test de código para antes refactorizar.

hOLA, somos Jose y Perla, casi de setenta años, entre los dos tenemos mas de 140 años de edad. Jeje.

Hemos aprobado 69 cursos, sobre temas que nos interesan, ya hicimos nuestro sitio web, aprendimos a usar ChatGPT, depuramos nuestro Python, conocimos otros lenguajes, hemos hecho nuestros primeros juegos educativos… guau la lista no termina sobre lo que hemos aprendido en Platzi. Lo recomendamos.

Tipos de deuda técnica:

  • Imprudente y deliberada
  • Imprudente e inadvertida
  • Prudente y deliberada
  • Prudente e inadvertida

¿Cómo pagar las deudas?
Refactorizando el código
¿Cuándo refactorizar?
Cuando hay código de baja calidad o se detecta code smell

Vamos por ese Senior Developer!!!

El curso está buenisimo y solo es segundo video,
He caído en deuda técnica, por falta de conocimientos habitualmente

No puedo creerlo, justo hoy estaba investigando al respecto, y salió este curso, es como si me leyeran la mente

Me ha pasado que veo condigo de hace un año y puedo ver que se puede optimizar, pero en ese momento no tenia las mismas skills que ahora voy adquiriendo con el tiempo

un buen complemento del curso seria el libro clean code de Robert C. Martín

Si son proyectos legacy que no tiene pruebas unitarias y test pruebas de integración como entraría la factorización, ya que tampoco cuenta con la documentación del respectivo software.

Acabo de iniciar este curso. Excelente la explicación de Alex y muy claro como aplicar estos conceptos.

Excelente esta clase

Muy interesante el curso, son las cosas que uno debe aprender si o si cuando se desarrolla software; y creo que todos de alguna u otra forma hemos desarrollado con deudas técnicas de los 4 tipos.

Los tests y los comments que vienen de la revision de los PR de los desarrolladores senior ensenan un montón