Clean Code: Optimización,

Refactorización y Documentación

Contenidos

1. Clean Code: Introducción

2. Documentación.
3. Refactorización.
4. Optimización.

1. Clean
Code: código
limpio, ¿qué es?
Seguro que alguna
vez programando o
analizando programas,
has visto un código
mal hecho o con un
título que no
correspondía de
verdad a su función.
Este escenario es más
común de lo que te
puedes imaginar y es
justamente el que
Clean Code busca
combatir.

Clean Code, o Código Limpio, es una filosofía de desarrollo de software que consiste en
aplicar técnicas simples que facilitan la escritura y lectura de un código, volviéndolo más
fácil de entender.
¿Cuándo surgió el término Clean Code?

Las técnicas de código limpio aparecieron por primera vez en el libro “Clean Code: A
Handbook of Agile Software Craftsmanship”, lanzado en 2008. Este fue escrito por Robert
Cecil Martin, conocido en la comunidad como Uncle Bob. El autor trabaja con desarrollo y
programación desde 1970 y es uno de los profesionales que lideró el Manifiesto Ágil, en
2001.

Con sus largos años de experiencia, Bob encontró que el problema principal en el desarrollo
de software era precisamente el mantenimiento. Es decir, un código mal escrito en su
primera versión puede funcionar, pero va a generar grandes problemas en el futuro.

El término de Clean Code se acuñó en la comunidad de forma unánime; y uno de los

motivos puede justificarse con el siguiente dato: en promedio, las personas dedican diez
veces más tiempo a leer y comprender el código fuente ya existente que a escribir nuevo
código, lo que sugiere que la comprensión de códigos hechos por otras personas, es una
actividad crítica en el desarrollo de software.

Podemos decir entonces que además de tener buena arquitectura y buenas prácticas, el
código fuente (código principal, que hace que el computador ejecute nuestros comandos)
necesita de principios; y esta es la propuesta que Clean Code presenta.

¿Para qué sirve el Clean Code?

Uno de los principales errores que los programadores cometen es creer que, una vez que el
código esté listo y funcionando, no necesita de revisiones.

Es importante tener en cuenta que un sistema nunca está totalmente finalizado, pues
siempre existe la necesidad de realizar actualizaciones y nuevas funcionalidades. Además
de esto, el código envejece, y Clean Code encaja perfectamente en esta situación.

La idea de los principios de Clean Code es convertir la programación de código y el

mantenimiento del código cada vez más simple.

Un código con muchos ajustes durante mucho tiempo, se vuelve imposible de mantener, por
lo que es mejor crear un código nuevo y no continuar con una versión problemática.

Un código limpio evita gastos innecesarios y prepara al software para las actualizaciones y
mejoras.
Las 7 reglas principales del Clean Code

En el libro anteriormente mencionado de Uncle Bob se enumeran buenas prácticas para

tener un código limpio. Las principales son:

1. Los nombres son importantes

La definición de nombre es esencial para el entendimiento de un código. Aquí no

importa el tipo de nombre, sean estos:

○ Variable;
○ Función;
○ Parámetro;
○ Clase;
○ Método.

Al definir un nombre, es necesario tener en mente dos aspectos principales:

○ Debe ser preciso y representar la idea central.

○ No te preocupes por los nombres grandes. Si la función o parámetro necesita
de un nombre extenso para demostrar lo que realmente representa, es lo que
debes hacer.

2. Regla del boy scout

Existe un principio que afirma que, si sales del área en que estas acampando, debes
dejarla más limpia que cuando la encontraste.

Si traemos esta regla al mundo de la programación, la podemos adaptar como dejar

el código más limpio de lo que estaba antes de editarlo.

3. Debes ser el verdadero autor del código

El ser humano está acostumbrado a pensar de manera narrativa, así que el código
funciona de la misma forma. Éste es una historia y, como los programadores son sus
autores, deben preocuparse por el modo en el que este cuento será presentado.

Resumiendo, para estructurar un código limpio, es necesario crear funciones

simples, claras y pequeñas. Existen dos reglas para crear la narrativa del código:

○ Las funciones deben ser pequeñas;

 ○ Las funciones deben ser aún más pequeñas.

El tamaño de las funciones debe ser tal que hagan una sola cosa.

No confundas los términos “nombre” y “función”. Como lo dijimos en el primer

principio, los nombres grandes no son un problema, pero las funciones sí.

Para asegurarnos que nuestras funciones hacen una sola cosa, tenemos que
asegurarnos que de las sentencias dentro de nuestra función están al mismo nivel
de abstracción, lo que significa que deben estar en el mismo nivel de detalle y
enfocarse en la misma tarea específica. Por lo tanto, una buena práctica es separar
las tareas en funciones más pequeñas y especializadas que se encarguen de una
tarea específica cada una, y que sean llamadas en secuencia por una función de
más alto nivel que coordine las tareas más complejas. De esta manera, se puede
asegurar que cada función se enfoca en una tarea específica y que todas las
sentencias dentro de ellas están al mismo nivel de abstracción, lo que facilita su
comprensión y mantenimiento.

Veamos un ejemplo:

En este ejemplo, se utiliza una lista de números como entrada y se devuelve un

valor de tipo Double que representa el promedio de la lista.
La función calcularPromedio se asegura de que todas las sentencias dentro de
ella estén en el mismo nivel de abstracción y se enfoquen en la misma tarea
específica. En este caso, la función primero verifica si la lista está vacía y devuelve
 null si es así. Luego, se utiliza un bucle for para sumar los números en la lista y
calcular el promedio. Finalmente, se devuelve el resultado.
De esta manera, la función cumple con el principio de tener una sola tarea y
asegurarse de que todas las sentencias estén en el mismo nivel de abstracción, lo
que facilita su comprensión y mantenimiento.

4. DRY (Don’t Repeat Yourself)

Este principio puede ser traducido como “no te repitas a ti mismo”. Una expresión,
que fue descrita por primera vez en un libro llamado The Pragmatic Programmer y
se aplica a áreas de desarrollo, como:

○ Bases de datos
○ Tests
○ Documentaciones
○ Codificaciones

DRY defiende que cada parte del conocimiento de un sistema debe tener
representación única y estar totalmente libre de ambigüedades. En otras palabras,
define que no pueden existir dos partes del programa que realicen la misma función.

El código debe ser conciso, modular y reutilizable, de modo que no tengamos que
repetir la misma lógica en diferentes partes del programa.

Cuando se repite el código en diferentes partes del programa, esto puede hacer que
el código sea más difícil de mantener y aumentar la posibilidad de errores, ya que
cualquier cambio en una parte del código tendría que ser replicado en todas las
demás partes. Además, la repetición de código también puede aumentar el tamaño
del programa, lo que puede afectar negativamente su rendimiento.

Para aplicar la técnica DRY en Clean Code, se recomienda seguir las siguientes
prácticas:

1. Extraer el código repetitivo a una función o método reutilizable: Si hay

código que se repite en diferentes partes del programa, se recomienda
extraer ese código a una función o método que pueda ser llamado desde
cualquier parte del programa. De esta manera, el código puede ser
reutilizado y no tiene que ser repetido en diferentes partes.
2. Crear una biblioteca de funciones reutilizables: Si hay funciones o
métodos que se utilizan con frecuencia en el programa, se recomienda crear
una biblioteca de funciones reutilizables que puedan ser utilizadas en
diferentes partes del programa. De esta manera, el código puede ser
reutilizado y no tiene que ser repetido en diferentes partes.

3. Utilizar patrones de diseño: Los patrones de diseño son soluciones

probadas y eficaces para problemas comunes en el desarrollo de software.
 Al utilizar patrones de diseño, se puede reducir la repetición de código y
hacer que el código sea más modular y reutilizable.

5. Comentar solamente lo necesario

Este principio afirma que los comentarios pueden hacerse; sin embargo, estos
deben ser necesarios. Según Uncle Bob, los comentarios mienten; y esto tiene una
explicación lógica.

Lo que ocurre es que, mientras los códigos son modificados, los comentarios no.
Estos son olvidados, y por lo tanto, no retratan la funcionalidad real de los códigos.

Entonces, ya sabes; si vas a comentar el código, que sea solamente lo necesario y

que sea revisado en conjunto con la versión del código que lo acompaña.

6. Tratamiento de errores

El tratamiento de errores es una parte importante en el desarrollo de software, ya

que permite que el programa maneje situaciones imprevistas y proporcione
información útil al usuario en caso de que algo salga mal.

Hay una frase del autor Michael Feathers, bastante conocida en el área de
desarrollo web, que afirma que las cosas pueden salir mal; pero cuando esto ocurre,
los programadores son los responsables por garantizar que el código continúe
realizando lo que necesita.

En Clean Code, se proponen varias prácticas para manejar los errores de manera
efectiva y clara:

- Utilizar excepciones en lugar de códigos de retorno: En lugar de devolver

códigos de retorno especiales para indicar errores, se recomienda utilizar
excepciones para manejar las situaciones de error. Las excepciones
proporcionan una forma más clara y estructurada de manejar los errores, y
permiten al programa distinguir entre diferentes tipos de errores.

- Crear excepciones específicas para cada tipo de error: En lugar de utilizar

excepciones genéricas como Exception o RuntimeException, se
recomienda crear excepciones específicas para cada tipo de error que pueda
ocurrir en el programa. Esto ayuda a hacer más claro el tipo de error que se
está manejando y permite una mejor gestión de los errores.

- Es importante asegurarse de que las excepciones sean manejadas de

manera adecuada y clara. Esto implica proporcionar mensajes de error
 significativos y útiles, y asegurarse de que el programa tenga una forma de
recuperarse de la excepción o notificar al usuario sobre el error.

- No utilizar excepciones para controlar el flujo del programa: Aunque las

excepciones son una herramienta útil para manejar errores, no deben
utilizarse para controlar el flujo del programa. Las excepciones deben ser
utilizadas solo para manejar situaciones de error inesperadas y no como
parte del flujo normal del programa.

7. Tests limpios

Realizar tests en el área de programación, es una etapa muy importante. Un código

solo se considera limpio, después de ser válido a través de pruebas, que también
deben ser limpias. Por esta razón, estos deben seguir algunas reglas, como:

○ Fast: El test debe ser rápido, permitiendo que sea realizado muchísimas
veces y en cualquier momento;
○ Independent: Debe ser independiente, con el fin de evitar que cause efecto
cascada cuando ocurra alguna falla, lo que dificulta el análisis de los
problemas;
○ Repeatable: Debe permitir la repetición del test, muchísimas veces y en
diferentes ambientes;
○ Self-Validation: Los tests bien escritos retornan con las respuestas true o
false para que el error no sea subjetivo;
○ Timely: Los tests deben seguir estrictamente el criterio de puntualidad.
Además de esto, lo ideal es que sean escritos antes del propio código, pues
evita que sea muy complejo para realizar el test.

El Clean Code es un concepto que llegó y se quedó. Sus principios solucionan con
eficacia uno de los principales problemas que gran parte de los proyectos de
sistemas enfrentan: el mantenimiento de código.

¿Cómo hacemos entonces para escribir código siguiendo estas pautas?

Es muy difícil seguir todas estas reglas cuando se empieza a escribir código. El truco está
en ir mejorando el código en etapas. Escribir, hacer funcionar, refactorizar para dejarlo
mejor (regla del boy scout sobre nuestro propio código).

2. Documentación

El proceso de documentación de código, es uno de los aspectos más importantes de la

labor de un programador.
Documentar el código nos sirve para explicar su funcionamiento, punto por punto, de forma
que cualquier persona que lea el comentario, puede entender la finalidad del código.

La labor de documentación es fundamental para la detección de errores y para su

mantenimiento posterior, que en muchos casos, es realizado por personas diferentes a las
que intervinieron en su creación. Hay que tener en cuenta que todos los programas tienen
errores y todos los programas sufren modificaciones a los largo de su vida.

La documentación añade explicaciones de la función del código, de las características de un

método, etc. Debe tratar de explicar todo lo que no resulta evidente. Su objetivo no es
repetir lo que hace el código, sino explicar por qué se hace.

La documentación explicará cual es la finalidad de un clase, de un paquete, qué hace un

método, para que sirve una variable, qué se espera del uso de una variable, qué algoritmo
se usa, por qué hemos implementado de una manera y de otro, qué se podría mejorar en el
futuro, etc.

2.1 Herramientas para la documentación: Javadoc

Javadoc es una herramienta de documentación de Java que se utiliza para generar

documentación en formato HTML para los archivos de código fuente Java.

Un javadoc es un programa, que toma los comentarios que se colocan en el código con
marcas especiales y construye un archivo HTML con clases, métodos y la documentación
correspondiente. Este HTML tiene el formato de toda la documentación estándar de Java
provista por Sun Microsystems; Javadoc extrae dichos comentarios y genera con ellos un
juego de documentación en formato HTML.

Javadoc es el estándar para documentar clases de Java. La mayoría de los IDEs para Java
utilizan javadoc para generar de forma automática documentación de clases.

Javadoc no afecta el rendimiento en Java ya que todos los comentarios se eliminan en el

momento de la compilación, simplemente conseguiremos comprender mejor el código y, por
lo tanto, mantenerlo mejor.

Javadoc fue uno de los primeros generadores de documentación en lenguaje Java. Antes
del uso de generadores de documentación, se acostumbraba utilizar redactores técnicos
que normalmente escribían sólo documentación independiente para el software, pero era
mucho más difícil mantener esta documentación sincronizada con el propio software.

Los entornos de programación que implementa Java, como Eclipse o Netbeans, incluyen
esta herramienta. Para que JavaDoc pueda generar las páginas HTML es necesario seguir
una serie de normas de documentación en el código fuente, estas son:

● Los comentarios de Javadoc se generan desde el código fuente y, por lo tanto, hay
que incluir en el mismo etiquetas especiales para poder interpretarlas en la
 generación. La etiqueta que determina un comentario Javadoc es /**..*/, es decir,
empiezan por /** y terminan por */.

● Un comentario Javadoc está compuesto de una definición seguida de un bloque de

etiquetas relacionadas.

A continuación se ofrece una tabla con las etiquetas principales que se usan en Javadoc
con su descripción funcional:

Etiqueta Descripción

@author Autor del elemento a documentar

@version Versión del elemento de la clase

@return Indica los parámetros de salida

@exception Indica la excepción que puede generar (equivalente @thorws con

matices)

@param Código para documentar cada uno de los parámetros

@see Una referencia a otra clase o utilidad

@deprecated El método ha sido reemplazado por otro

@throw

Nota:

● En la documentación Javadoc de Java, "@throws" y "@exception" se utilizan para

documentar las excepciones que pueden ser lanzadas por un método. Sin embargo,
hay algunas diferencias entre ambos:

1. Propósito: "@throws" se utiliza para indicar que el método puede lanzar una
excepción específica, mientras que "@exception" se utiliza para documentar
excepciones generales o no específicas.
2. Sintaxis: "@throws" se utiliza seguido del nombre de la excepción específica
que se puede lanzar, mientras que "@exception" se utiliza para documentar
una excepción general o no específica y no requiere un nombre de excepción
específico.
 3. Ubicación: En general, "@throws" se coloca después de la documentación
del método, mientras que "@exception" se coloca antes de la documentación
del método.

Por lo tanto, la principal diferencia entre "@throws" y "@exception" es que "@throws" se

utiliza para documentar excepciones específicas que pueden ser lanzadas por un método,
mientras que "@exception" se utiliza para documentar excepciones generales o no
específicas. En cualquier caso, ambos se utilizan para documentar las excepciones que
pueden ser lanzadas por un método con el fin de ayudar a los desarrolladores a entender el
comportamiento del método y cómo manejar esas excepciones si es necesario.

● {@link package.class # member label}: La sintaxis Javadoc {@link} se utiliza

para crear un enlace dentro de la documentación Javadoc a otra parte del código,
como una clase, un método, un campo, etc. Es una forma útil de permitir que los
desarrolladores naveguen fácilmente a través del código para encontrar más detalles
sobre una clase, método, campo, etc. que se está documentando en la
documentación Javadoc.

Comentarios de clases

A continuación se presenta un ejemplo que muestra cómo se indican, en los comentarios de

una clase, la descripción, el autor, la versión y la fecha.
Ejemplo:

/**
* Frase corta descriptiva
* Descripción de la clase
* @author Nombre Apellido / Empresa
* @version 0.1, 2023/02/17
*/

Comentarios de Métodos

Podemos ver cómo se incluyen los comentarios de los métodos en el siguiente ejemplo. En
él vemos la manera de especificar la descripción, los parámetros, el tipo de retorno y las
excepciones que se lanzan. También vemos cómo se referenciaría la llamada a otro
método.
Ejemplo:
/**
* Frase corta descriptiva
* Descripción del método.
* Mención al uso{@link es.loquesea.$app.util.Otra#unMetodo
unMetodo}.
* @param param1 descripción del parámetro.
* @return qué devuelve el método.
* @exception tipo de excepción que lanza el método y en qué
caso
* @see paquete.Clase#metodo Código al que se hace referencia
* @throws IllegalArgumentException el param1 no tiene el
formato deseado
*/

{@link es.loquesea.$app.util.Otra#unMetodo unMetodo}: esta línea crea un enlace a un

método llamado "unMetodo" en la clase "Otra", que se encuentra en el paquete
"es.loquesea.$app.util". El texto "unMetodo" es el texto que se mostrará en la
documentación Javadoc como un hipervínculo que llevará al usuario a la definición de ese
método.

Comentarios de Variables

La manera de incluir los comentarios a las variables es la que se muestra a continuación.

En ella podemos ver cómo se especifican su descripción, su modificador (private, public), si
procede, y cuáles son los valores válidos o qué ocurre si su valor es null.
Ejemplo:
/**
* Frase corta descriptiva
* Descripción de la variable.
* Valores válidos (si aplica)
* Comportamiento en caso de que sea null(si aplica)
*/

Aqui os dejo en enlace oficial de la herramienta:

http://www.oracle.com/technetwork/java/javase/documentation/index-jsp-135444.html

3. Refactorización

¿Qué es la refactorización?

Programar software conlleva un proceso largo que suele involucrar, al menos parcialmente,
a varios desarrolladores, por lo que durante el desarrollo el código fuente a menudo se
amplía y modifica. Si además de estos cambios, tenemos en cuenta que se trabaja a
contrarreloj y utilizan ciertas prácticas anticuadas, observamos como resultado una
acumulación de elementos defectuosos en el código fuente, los llamados code smells.
Estos puntos débiles, que van aumentando a medida que avanza el proceso, ponen en
peligro la funcionalidad y la compatibilidad del software en cuestión. Para evitar esta erosión
continua del programa, se utiliza la refactorización o refactoring.

La refactorización es una disciplina técnica, que consiste en realizar pequeñas

transformaciones en el código de un programa, para mejorar la estructura sin que cambie el
comportamiento ni la funcionalidad del mismo. Su objetivo es mejorar la estructura interna
del código. Es una tarea que pretender limpiar el código minimizando la posibilidad de
introducir errores.

La refactorización podría compararse con la corrección de un libro: el producto final de la

corrección no es un nuevo libro, sino el mismo texto, pero más comprensible. Así, al igual
que en la corrección de un libro se usan procedimientos como la reformulación y la
reestructuración o eliminación de frases, en la refactorización de código se aplican métodos
como la encapsulación, el reformateo o la extracción para optimizar el código sin cambiar
su contenido.

Este proceso resulta mucho más económico que reescribir la estructura del código desde
cero. La refactorización desempeña un papel especialmente importante en el desarrollo
iterativo e incremental, así como en el desarrollo ágil de software, ya que este modelo
cíclico lleva a los programadores a modificar el software una y otra vez. En este proceso, la
refactorización es un paso clave.
Debemos tener en cuenta que un código puede degenerar a lo largo del tiempo y
convertirse en un llamado código espagueti. Ya sea por falta de tiempo, por falta de
experiencia o por directrices poco claras, las órdenes innecesariamente complejas en la
programación del código acaban obstaculizando su funcionalidad. Cuanto más rápido y
complejo sea el ámbito de aplicación de un código, más se erosionará.

El término código espagueti hace referencia a códigos fuente confusos y de difícil lectura,
cuya estructura es difícil de comprender para los programadores. Algunos ejemplos típicos
de elementos que complican el código son las órdenes de salto (GOTO) redundantes, que
indican al programa que vaya saltando de un sitio a otro en el código; los bucles for/while y
los comandos if.

Concretamente, los proyectos en los que trabajan muchos desarrolladores suelen generar
un código poco legible. Si un código que ya de por sí presentaba ciertas imperfecciones
pasa por muchas manos, es difícil evitar que se encadenen modificaciones a modo de
parche y que, finalmente, se requiera una revisión del código para corregirlo.

En el peor de los casos, el código espagueti puede poner en peligro todo el proceso de
desarrollo del software, llegando a un punto en el que ni siquiera la refactorización puede
resolver el problema. Los llamados code smells y el code rot (es decir, los defectos y la
erosión del software) no tienen por qué ser tan preocupantes si se realiza un refactoring en
cuanto aparezcan los primeros signos de code smells, ya que si no el código seguirá
erosionándose y perderá su funcionalidad a causa del code rot (el proceso de putrefacción,
¿Cuál es el objetivo de la refactorización?

La refactorización siempre tiene el sencillo y claro propósito de mejorar el código. Con un

código más efectivo, puede facilitarse la integración de nuevos elementos sin incurrir en
errores nuevos. Además, cuanto más fácil les resulte a los programadores leer el código,
más rápido se familiarizarán con él y podrán identificar y evitar los bugs de forma más
eficiente. Otro objetivo de la refactorización es mejorar el análisis de errores y la necesidad
de mantenimiento del software. Poner a prueba el código ahorra esfuerzo a los
programadores.

¿Qué fuentes de error corrige la refactorización?

Los métodos aplicados en la refactorización son tan variados como los errores que tratan de
corregir. De manera general, la refactorización del código se guía por sus errores y va
mostrando los pasos necesarios para acortar o eliminar procesos de corrección. Algunas de
las fuentes de error que pueden corregirse mediante refactoring son las siguientes:

● Estructuras complicadas o demasiado largas: cadenas y bloques de comandos tan

largos que la lógica interna del software se vuelve incomprensible para lectores
externos.
● Redundancias en el código: los códigos poco claros suelen contener repeticiones
que han de corregirse una a una durante el mantenimiento, por lo que consumen
mucho tiempo y recursos.
 ● Listas de parámetros demasiado largas: los objetos no se asignan directamente a un
método, sino que se indican sus atributos en una lista de parámetros.
● Clases con demasiadas funciones: clases con demasiadas funciones definidas como
método, también llamadas god objects, que hacen que adaptar el software se vuelva
casi imposible.
● Clases con funciones insuficientes: clases con tan pocas funciones definidas como
método que se vuelven innecesarias.
● Código demasiado general con casos especiales: funciones con casos especiales
demasiado específicos que apenas se usan y que, por lo tanto, dificultan la
incorporación de ampliaciones necesarias.
● Middle man: una clase separada actúa como intermediaria entre los métodos y las
distintas clases, en lugar de direccionar las solicitudes de los métodos directamente
a una clase.

¿Cómo se aplica la refactorización?

La refactorización debe llevarse a cabo antes de modificar una función del programa. En el
mejor de los casos, debe realizarse en muy pocos pasos y comprobando cada modificación
del código mediante procesos de desarrollo de software como el desarrollo guiado por
pruebas (TDD, por sus siglas en inglés) y la integración continua (CI). En pocas palabras, el
TDD y la CI se encargan de poner a prueba los nuevos segmentos de código creados por
los programadores, que luego son integrados y cuya funcionalidad es evaluada mediante
procesos de prueba, a menudo automatizados.

Por regla general, un programa ha de ser modificado en pocos pasos y desde dentro, sin
que su función externa se vea afectada. Tras cada cambio, debe realizarse un test que esté
automatizado en la medida de lo posible.

Nota:

El Desarrollo Guiado por Pruebas (TDD, por sus siglas en inglés "Test Driven
Development") es una técnica de desarrollo de software que consiste en escribir pruebas
automatizadas antes de escribir el código que implementa la funcionalidad.

En TDD, el ciclo de desarrollo se compone de tres pasos:

● Escribir una prueba automatizada que falle.

● Escribir la cantidad mínima de código necesaria para que la prueba pase.
● Refactorizar el código escrito para mejorar su calidad sin cambiar su
comportamiento.

Este ciclo se repite varias veces durante el proceso de desarrollo, y cada iteración mejora la
calidad del código y la confianza en su comportamiento.
La Integración Continua (CI, por sus siglas en inglés "Continuous Integration") es una
práctica de desarrollo de software que consiste en la integración regular y automática del
código escrito por los miembros de un equipo de desarrollo.

En CI, cada vez que un desarrollador hace cambios en el código, estos cambios se integran
automáticamente con el resto del sistema. Se ejecutan pruebas automatizadas para
asegurar que el código nuevo no rompa el sistema existente y se generan informes de
calidad del código.

Esta técnica ayuda a reducir el riesgo de errores y conflictos en el proceso de integración,

ya que se integran pequeñas cantidades de código con frecuencia en lugar de grandes
cantidades de código con poca frecuencia.

¿Qué técnicas existen?

Hay muchísimas técnicas concretas de refactorización. Para conocerlas todas, se puede

consultar la exhaustiva obra sobre este tema de Martin Fowler y Kent Beck: Refactoring:
Improving the Design of Existing Code. A continuación, presentamos un resumen: