Menú

Refactorización de código: lo que necesita saber al respecto

code refactoring what you need know about it

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Comprensión de la refactorización de código: la perspectiva de un evaluador

El término 'Refactorización' se utiliza principalmente para indicar la limpieza / rediseño del código requerido.

En este tutorial, comprenderemos la definición de refactorización, discutiremos la necesidad de refactorizar el código y revisaremos el impacto de la refactorización en varios miembros del equipo del proyecto. También discutiremos la respuesta a la pregunta más importante: Como tester, ¿por qué necesita saber sobre refactorización?

Además, también discutiremos algunos estudios de caso para aclarar el concepto.

Código de refactorización

Lo que vas a aprender:

Introducción a la refactorización

Para empezar, primero entendamos qué es realmente la refactorización.

La refactorización es esencialmente una práctica o proceso para mejorar el código y / o la base de datos mientras se mantiene la funcionalidad existente. La idea es transformar el código ineficiente y demasiado complicado en un código más eficiente, preferiblemente más simple y más fácil.

La refactorización del código también ha cobrado impulso con más equipos ahora siguiendo el enfoque de desarrollo de software ágil. Los equipos de proyectos a menudo tienen un tiempo limitado para implementar nuevas o ampliar la funcionalidad de las características existentes y el código que está limpio. El código, que es fácil de entender y mantener, ciertamente ayuda mucho a cumplir con la fecha límite de iteración.

Necesidad de refactorización de código

Si mantenemos la funcionalidad original de la aplicación o módulo, surge una pregunta como ¿Por qué nos molestamos en refactorizar? Bueno, existen numerosas razones por las cuales un módulo en particular o un fragmento de código puede necesitar ser refactorizado, como:

  1. El código huele
  2. Deuda técnica
  3. Enfoque de desarrollo de software ágil, etc.

Discutiremos estos puntos en detalle en las siguientes secciones.

# 1) Código huele:

Todos podemos entender que cuando la comida comienza a oler, indica que lo más probable es que se esté echando a perder; ¡esto también es cierto para el código! Los olores de código son indicaciones de que puede existir un problema muy serio en el código.

A continuación se muestran algunos olores de código comunes:

  • Presencia de código idéntico o redundante.
  • Una variable declarada que no se usa en ninguna parte del resto del código.
  • Diseño de código demasiado complicado.
  • Clase de código que hace muy poco y no justifica la existencia de la clase definida. Estas clases se conocen como clase perezosa o aprovechador.
  • La existencia de demasiadas condiciones y bucles que tienen el potencial de romperse y simplificarse.
  • El código se construye de tal manera que un cambio en una parte del código requiere que el cambio se implemente también en los otros lugares.

Los olores de código se vuelven más evidentes con el paso del tiempo. A medida que la aplicación o el sistema crece, eventualmente estos olores de código comienzan a afectar el desarrollo del código, el mantenimiento e incluso el rendimiento del sistema en escenarios extremos.

# 2) Deuda técnica:

Al desarrollar un software, durante el tiempo y los recursos limitados disponibles, a menudo podemos tomar atajos para lograr los resultados deseados.

Considere una función que debe agregarse a un módulo existente. Después de la discusión, el equipo reduce 2 enfoques para agregar esta característica. El enfoque A, que requiere 2 sprints para entregarlo, será el enfoque aprobado a largo plazo. El enfoque B tarda solo 5 días en entregarse y es un truco codificado y desordenado que está diseñado para dar servicio al módulo a corto plazo.

Si el equipo está bajo presión para entregar la función en un tiempo limitado, entonces pueden acordar seguir el Método B por ahora y agregar el Método A en el trabajo pendiente para el futuro. Al hacer esto, este equipo acaba de crear la deuda técnica por sí mismos.

En términos simples, la deuda técnica en el desarrollo de software se refiere a la reelaboración adicional o los gastos generales necesarios para implementar las correcciones adecuadas o hacer las cosas de la 'manera correcta'.

Los sistemas heredados tienden a adquirir una enorme deuda técnica con el tiempo, lo que a su vez puede hacer que la aplicación sea susceptible a fallas y difícil de brindar soporte y mantenimiento.

Leer más=> ¿Qué es el departamento técnico?

# 3) Siguiendo el enfoque de desarrollo de software ágil:

El enfoque de desarrollo de software ágil aboga por el desarrollo incremental. Sin un código limpio, bien estructurado y fácil de mantener, los equipos no podrían extender el código existente con cada iteración. Si el código se cambia sin una refactorización adecuada, puede contribuir a los malos olores del código o la deuda técnica.

Esta relación se muestra en el siguiente diagrama.

Enfoque de desarrollo de software ágil

Lectura recomendada => Principales herramientas de análisis de código

¿Por qué un QA necesita saber sobre la refactorización?

Todo lo que discutimos hasta ahora en este tutorial parece estar relacionado con la codificación y parece el tipo de cosas por las que un desarrollador debería preocuparse.

Entonces, ¿por qué estamos discutiendo este concepto no relacionado en la Comunidad de ayuda de pruebas de software? Continúe leyendo el resto de este tutorial para obtener la respuesta a esta pregunta.

# 1) Para probadores / desarrolladores unitarios

Mientras se refactoriza el código, a medida que se inserta un nuevo código, se actualizan las clases antiguas, se agregan nuevas clases y las pruebas unitarias existentes ahora pueden fallar. Además, para los sistemas heredados, es posible que no se implementen pruebas unitarias. Estas nuevas pruebas unitarias deberán crearse y configurarse desde cero en la mayoría de los casos.

# 2) Para probadores

Cuando se está refactorizando una característica (considerando que no estamos agregando ninguna funcionalidad nueva), se entiende que después de que se realizan los cambios requeridos, la mayoría de la funcionalidad para el usuario final debe permanecer igual.

  • Como evaluador, la refactorización del código se traduce aproximadamente en = pruebas en profundidad + pruebas de regresión. Las pruebas en profundidad deben incluir todos los flujos de usuarios existentes para garantizar que todas las funcionalidades funcionen como antes. Pruebas de regresión de toda la aplicación (o áreas afectadas) es necesario para garantizar que la actualización de un módulo no interrumpa involuntariamente la funcionalidad de los otros módulos.
  • Las pruebas de aceptación del usuario serán importantes y estas pruebas deben pasar antes de que la compilación pueda declararse lista para su lanzamiento.
  • Además, cualquier otra prueba requerida como pruebas de carga, prueba de seguridad etc. también deberán implementarse según sea necesario.

# 3) Ingenieros de pruebas de automatización

La refactorización del código puede hacer que fallen los scripts de automatización funcionales y no funcionales.

Esto puede ocurrir por las siguientes razones:

  • Si los objetos de la página cambian como parte del esfuerzo de refactorización y si sus scripts de automatización de Selenium se basan en los objetos de la página, entonces los scripts fallarán y deberán actualizarse.
  • Si hay cambios menores, redirige los que se agregaron o eliminaron durante la refactorización, y los scripts de automatización existentes fallarían y deberían actualizarse

Se recomienda que las pruebas de automatización funcional solo se configuren una vez que una característica sea estable, de lo contrario resultará en una gran cantidad de reelaboración a medida que la característica evoluciona.

Al ser un desarrollador de pruebas de automatización, los ingenieros de pruebas de automatización también deben pensar como un desarrollador y apuntar a crear un código limpio y fácil de mantener. La mayoría de los IDE como IntelliJ IDEA, Eclipse, etc., incluyen un menú de refactorización incorporado con métodos de refactorización de uso común para una fácil referencia.

A continuación se muestra una captura de pantalla del menú de refactorización en IntelliJ IDEA (Community Edition).

Angular js preguntas y respuestas de la entrevista

menú de refactorización

# 4) Para cables de prueba / cables de control de calidad

  • Es posible que se requiera que los clientes potenciales de prueba o de control de calidad trabajen junto con el resto del equipo, incluidos los desarrolladores, el analista de productos y tal vez incluso las partes interesadas, para garantizar que la planificación de las pruebas para dichos proyectos se realice con cuidado.
  • Es importante comprender la funcionalidad existente. En función de la funcionalidad existente, es necesario documentar los casos de negocio, los flujos de usuarios y las pruebas de aceptación de usuarios. Cuando se prueba un código refactorizado, todos estos escenarios deben validarse, junto con las pruebas de regresión de las áreas afectadas.
  • Sea proactivo al planificar el enfoque de prueba y planes de prueba . Si prevé el requisito de varios entornos de prueba o nuevas herramientas de prueba, envíe la solicitud con anticipación para evitar retrasos una vez que comience la fase de prueba.
  • No dude en involucrar a miembros del equipo que no pertenecen al proyecto o usuarios finales para que contribuyan a las pruebas.

Estudios de caso

Ahora discutiremos algunos estudios de casos de la vida real en los que tuve la oportunidad de trabajar directamente o contribuir indirectamente.

Estudio de caso # 1

Tarea: Refactorice un módulo para reemplazar los valores codificados con variables y agregue comentarios para la nueva herramienta automatizada de generación de documentación técnica.

Desafíos :Sin grandes desafíos. El módulo era nuevo, había documentado requisitos funcionales y de aceptación de usuarios, flujos de usuarios y casos de prueba. Las pruebas unitarias se establecieron durante el lanzamiento inicial.

Enfoque de prueba :Se ejecutaron los casos de prueba para el módulo que se está refactorizando y las áreas impactadas relativamente conocidas. Cualquier defecto fue informado y resuelto antes del lanzamiento.

Estudio de caso n. ° 2

Tarea :Refactorice el procedimiento almacenado existente para facilitar la ampliación de la aplicación.

El procedimiento almacenado en este escenario era un procedimiento almacenado más antiguo que se diseñó hace unos años, teniendo en cuenta el requisito de que la aplicación usaba su procedimiento almacenado como una aplicación interna con menos de 10 sesiones simultáneas.

Ahora la empresa quería comercializar esta aplicación como Software como Servicio (SaaS), con el volumen esperado de 300 sesiones simultáneas inicialmente.

El equipo hizo algunas pruebas de carga iniciales y concluyó que el sistema se rompe con una carga de 25 sesiones simultáneas. El equipo revisó el código y recomendó refactorizar un procedimiento almacenado central existente que permitiría que la aplicación escale y admita hasta 500 sesiones simultáneas sin interrupciones.

Algunos problemas identificados con este procedimiento almacenado fueron múltiples subconsultas dentro de una sola consulta, uniones pesadas con vistas en lugar de tablas, uso de select * en lugar de seleccionar una columna específica, etc. Debido a estos problemas de codificación, la aplicación estaba obteniendo más datos que eso era realmente necesario, lo que hacía que la aplicación se ralentizara y finalmente se bloqueara.

Desafíos:

# 1) Gerente de proyectos / Analista de productos

  • Reunión de requisitos - Dado que este procedimiento almacenado era un código heredado, no había requisitos documentados para él cuando se diseñó el módulo por primera vez. Además, para las iteraciones realizadas en los últimos años, no hubo un registro de cambios para indicar las reglas comerciales y la lógica agregada o eliminada del módulo.
  • Cronograma del proyecto - Dado que los requisitos no estaban claramente definidos y las dependencias de los códigos aún no estaban completamente identificadas, fue difícil comunicar el cronograma tentativo.

# 2) Para desarrolladores

  • Falta de requisitos claros y reglas comerciales.
  • Limpiar el código sin perder su funcionalidad.
  • Áreas impactadas desconocidas y / o dependencias de código.
  • No se pueden proporcionar estimaciones concretas del tiempo de desarrollo.
  • Necesidad de crear nuevas pruebas unitarias.

# 3) Para probadores

  • La falta de requisitos claros y reglas comerciales afecta la planificación de las pruebas.
  • Las áreas impactadas desconocidas impactan la planificación de las pruebas, específicamente para las pruebas de regresión.
  • No se pudo proporcionar estimaciones de pruebas concretas.

# 4) Partes interesadas

  • Falta de requisitos claramente documentados y / o flujos de usuarios + plazos ajustados = Mayor riesgo de falla.

El enfoque seguido por el equipo para mitigar los riesgos y solucionar los desafíos :

(i) El equipo siguió un enfoque colaborativo para recopilar requisitos : Project Manager / Product Analyst y Testers trabajaron en estrecha colaboración con los usuarios finales internos para comprender y documentar la funcionalidad principal y el flujo de usuarios.

Los desarrolladores también revisaron el código y agregaron información relevante al documento de requisitos. Esto se hizo antes del día de inicio del sprint.

(ii) El entorno de prueba alternativo se creó para probar el cambio que se está implementando : Llamemos a estos entornos como Gamma y Phi. Gamma tendría el código antiguo y Phi tendría implementado el último procedimiento almacenado refactorizado en todo momento.

Tener 2 entornos de prueba en paralelo, casi recreando el enfoque de antes y después, permitió al equipo hacer pruebas más profundas y exploratorias al comparar el comportamiento en estos 2 entornos de prueba, pudieron identificar los errores probables.

El equipo proporcionó los requisitos para un entorno de prueba alternativo que se proporcionó antes de la fecha de inicio del sprint.

(iii) Usuarios finales y partes interesadas involucradas en las pruebas desde el principio : Todos los problemas obvios se detectaron e informaron al principio, lo que permitió que el equipo tuviera más tiempo para implementar y probar la solución requerida.

(iv) Definir los criterios de salida y adherirse a ellos: Los criterios de salida se definieron en las etapas iniciales de planificación: 80% de los flujos de usuarios probados, ningún error crítico sin resolver, demostración y firma de las partes interesadas antes del lanzamiento.

(v) Establecer una fecha de lanzamiento tentativa: Establecer una fecha de lanzamiento alineada y motivando al equipo a trabajar hacia un punto final común. Con base en el alcance del proyecto, el equipo recomendó que se siguiera un sprint de 3 semanas en lugar de un sprint regular de 2 semanas para permitir el tiempo suficiente para que el equipo ejecute el proyecto.

Conclusión

En resumen, la refactorización de código es un proceso para limpiar / simplificar el diseño de un módulo sin cambiar su funcionalidad. El proceso de refactorización puede ser simple, como agregar comentarios, agregar sangría correcta, eliminar una variable estática, etc. o puede ser complicado para sistemas heredados complejos.

Es posible que sea necesario refactorizar un módulo en particular o un fragmento de código debido a olores de código, deudas técnicas o siguiendo un enfoque de desarrollo de software ágil.

Para los probadores, la refactorización del código se traduce aproximadamente en = pruebas en profundidad + pruebas de regresión.

Se requieren pruebas en profundidad para probar todos los flujos de usuarios existentes y asegurarse de que todas las funcionalidades estén funcionando como antes. Se requieren pruebas de regresión de toda la aplicación (o áreas impactadas) para garantizar que la actualización de un módulo no rompa involuntariamente la funcionalidad de los otros módulos.

Es posible que se requiera que los clientes potenciales de prueba / clientes potenciales de control de calidad trabajen junto con el resto del equipo, incluidos los desarrolladores y el analista de productos, especialmente para proyectos heredados. Sea proactivo al planificar el enfoque de prueba y los planes de prueba. Si prevé el requisito de varios entornos de prueba o nuevas herramientas de prueba, envíe la solicitud con anticipación para evitar retrasos una vez que comience la fase de prueba.

Sobre el Autor: Este tutorial informativo está escrito por Neha B. Actualmente trabaja como Gerente de Garantía de Calidad y se especializa en liderar y administrar equipos de control de calidad internos y externos.

¿Ha trabajado en un proyecto desafiante que implicó la refactorización de código o un módulo / aplicación? En caso afirmativo, no dude en compartir sus experiencias en la sección de comentarios para que nuestros compañeros de prueba aprendan.

Lectura recomendada

^