Agile 101 – Refactoring de Código


3459996373_ef882db52f_z

Code + aimee rivers

Por Method123

En los proyectos de desarrollo tradicional, hay una tendencia a que una persona escriba programas completos para implementar determinadas funciones. Es probable que una vez que el programa o componente haya sido escrito y probado, nunca tendrá que ser actualizado una vez más durante el proyecto. Este no es el caso con los proyectos Agile. Los proyectos Agile construyen soluciones incrementales a través del tiempo. Es muy posible, y tal vez probable, que un componente que se ha escrito para apoyar una pieza específica de funcionalidad pueda ser necesario actualizarlo más tarde con la introducción de algún otro caso de uso con funcionalidad relacionada.

En un proyecto Agile cuando el segundo desarrollador trabaja en un módulo o componente en el que otro desarrollador trabajó anteriormente, un par de cosas tienen que suceder. En primer lugar, el segundo desarrollador necesita revisar y entender el trabajo del desarrollador anterior. En segundo lugar, el segundo desarrollador tiene que insertar el código nuevo y revisarlo para apoyar la nueva funcionalidad.

Cuando el segundo desarrollador revisa el código, es posible que pueda tener algunas ideas para hacer el código más eficiente o más fácil de soportar. En un proyecto tradicional, hay una tendencia a dejar el código ineficiente en su lugar. La idea es que “si no está roto el código no lo arregles”. Esto se considera un enfoque más rentable. Por lo tanto, el código anterior que parece estar funcionando tiende a aislarse de manera que los nuevos cambios no afecten al mismo. Este enfoque general resulta en código que se vuelve muy “frágil” en el tiempo. “Brittle” significa que el código tiende a romperse o que los errores se introducen cada vez que se toca este código antiguo.

Los proyectos Agile toman una vía contraria. Si un desarrollador posterior tiene preocupaciones acerca de la forma en que se ha codificado un componente, o si piensa que el código no es tan eficiente como tiene que ser, el segundo desarrollador toma el tiempo para actualizar el código. Esta revisión y modificación del código constante se llama “refactoring”.

Refactoring es la práctica esperada de actualizar continuamente el código anterior si el desarrollador actual piensa que el código se puede mejorar, documentar mejor, o optimizarlo.

Refactoring puede o no tomar un poco más de tiempo para escribir y probar durante la iteración actual. El mayor peligro de tocar el código antiguo es que va a romper algo que funciona en la actualidad. Sin embargo, este riesgo se reduce al mínimo en proyectos Agile con la introducción de pruebas automatizadas y rigurosas para que cualquier nuevo error pueda ser descubierto y corregido rápidamente. Cualquier impacto a corto plazo se compensa mediante la entrega continua de código mejorando durante la vida del proyecto. El código será más limpio, más eficiente, más flexible, más documentado y mucho más fácil para apoyar a más largo plazo.

Resumen

Refactoring es una de las filosofías que son exclusivas de Agile. No es sólo algo que se hace si usted ve un problema importante. Es un modo de pensar que usted tiene cuando se realizan cambios en un componente existente. Cuando los equipos tradicionales de proyectos pueden alejarse de la práctica, los equipos ágiles la abrazan o asumen. El resultado es la capacidad de los equipos ágiles para mantener las soluciones más flexibles y eficaces durante todo el camino a través del proyecto Agile.


Si quieres seguir desarrollando tu carrera profesional y recibir interesantes artículos

Introduce tu dirección de correo electrónico para seguir este Blog y recibir las notificaciones de las nuevas publicaciones en tu buzón de correo electrónico.

Únete a otros 1.090 seguidores

Anuncios
Acerca de

Profesional de la Gestión de Proyectos, PMP, con estudios en Ingeniería Civil y vasta experiencia en el área de servicios tecnológicos al sector financiero y comercial. Experiencia en Liderazgo Organizacional, Agile Project Management, Re-ingeniería de Procesos y Business Process Modeling.

Tagged with: ,
Publicado en Agile Project Management

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

Síguenos en las redes sociales

Introduce tu e-mail para recibir notificaciones de las nuevas publicaciones en tu buzón de correo electrónico.

Síguenos en Twitter
Post archivados

Introduce tu e-mail para recibir notificaciones de las nuevas publicaciones en tu buzón de correo electrónico.

How to Manage a Camel - Project Management Blog

Project Management Recruitment, Careers and News from Arras People

Girl's Guide to Project Management

Guía práctica de Gestión de Proyectos y Desarrollo Profesional

Proyectum

El boletin quincenal de TenStep

Técnicas de Organización

Guía práctica de Gestión de Proyectos y Desarrollo Profesional

Guia Practica del PMP

Guía práctica de Gestión de Proyectos y Desarrollo Profesional

A %d blogueros les gusta esto: