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 💛💚
Introducción al Clean Code
Deuda técnica y refactorización de código
Reglas del diseño simple
Qué es Clean Code
Nombre y uso de las variables
Uso correcto de var, let y const
Reglas para la nomenclatura
Cómo nombrar según el tipo de dato
Ejercicio: Nombra correctamente según su tipo de dato
Ámbito de las variables
Ámbito global
Ámbito local o de función
Ámbito de bloque
Ámbito estático
Hoisting
Funciones
Declaración y expresión de funciones
Parámetros y argumentos
Funciones de flecha y el this
Clases
POO con ES6 (constructores, métodos y herencia)
Herencia en JavaScript
Tamaño reducido (responsabilidad única)
Organización
Optimizaciones
Cuándo usar comentarios
Formato coherente (codear en equipos)
Principio DRY
Notación big O
Cierre
Sigue aprendiendo JavaScript
Deuda técnica y refactorización de código
1/24Recursos
Aportes 17
Preguntas 0
Ordenar por:
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.)
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.
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 BoochEntusiasta 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.
El curso está buenisimo y solo es segundo video,
He caído en deuda técnica, por falta de conocimientos habitualmente
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!!!
un buen complemento del curso seria el libro clean code de Robert C. Martín
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
## Deuda técnica y refactorización de código
“Nuestro código tiene que ser simple y directo, debería de leerse con la misma facilidad que un texto bien escrito” -Grady Booch
Deuda Técnica
La Deuda Técnica hace referencia a los costos de un esfuerzo que se va a tener que hacer adicionalmente, porque se ha elegido un desarrollo sencillo y rápido, en lugar de utilizar un mejor enfoque que quizás tomaría más tiempo.
Es un esfuerzo extra que lo que va a hacer es como si se tuviera un crédito, ya que a futuro vamos a tener que pagar esa deuda, y esto lo que puede hacer es multiplicar el tiempo de desarrollo del proyecto inicial.
A la larga hace que el código sea difícil de mantener. Existen 4 tipos de deuda técnica:
1 - **Imprudente y deliberada** → El/ la desarrolladora actúa de forma consciente del factor de deuda que están dejando en el código.
2 - **Imprudente e inadvertida** → Dejar deuda técnica sin saberlo por falta de conocimiento.
3 - **Prudente y deliberada** → Se planea para obtener otro beneficio o seguir otra ruta y se tiene en cuenta que se tiene que pagar lo más pronto posible.
4 - **Prudente e inadvertida** → Cuando tenemos conocimiento en el código pero se puede realizar mejor con menos deuda.
**Refactorizar** → Es un proceso que tiene como objetivo mejorar el código de un proyecto sin alterar su comportamiento para que sea más entendible y tolerante a cambios.
Se refactoriza principalmente en dos momentos, siempre que existan test automáticos del código:
1 - Cuando el código sea de baja calidad(Código duplicado, cuando las funciones tienen más de una acción, etc.)
2 - Al detectar un code smell (indicadores superficiales de posibles problemas en el sistema)
La deuda técnica se paga mediante la refactorización del código, identificando y corrigiendo problemas como duplicación y la complejidad excesiva. Es crucial reconocer cuándo se incurre en deuda técnica y actuar para mantener un código limpio y mantenible, respaldado por pruebas automatizadas.
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
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?