Refactoreo; Pasado, Presente y Futuro

Presentación del Editor Invitado: • Emerson Murphy-Hill • Diciembre 2015

Read the Guest Editors’ Introduction in
English  |  Chinese

Translations by Osvaldo Perez and Tiejun Huang


Listen to the Guest Editor' Introduction

securing the internet of things

El software, como se dice, está engullendo al mundo. Desde las computadoras personales a los teléfonos celulares, los automóviles, y las aspiradoras, el software está creciendo incesantemente en termino tanto de lo lugares en donde se lo puede encontrar como de las funcionalidades que esperamos del él. Desafortunadamente, como muchos de nosotros, el software madura y se trasforma en más capaz, pero también se deteriora. Aun el software que comienza con un diseño limpio y claro, finaliza como una mezcla revuelta en la medida en que los usuarios demandan más características que deben ser añadidas y bugs que deben ser reparados con mayor rapidez. Esta mezcla se transforma en algo cada más complejo y costoso de mantener para los desarrolladores.

Una de las formas primarias en que los desarrolladores han lidiado con tal deterioro durante el transcurso del tiempo es por medio del refactoreo, que implica la práctica de cambiar el diseño del código existente sin cambiar la forma en que se comporta. Cuando un diseño de software deja de ajustarse a su propósito el refactoreo le permite a los diseñadores cambiarlo. El refactoreo puede involucrar una restructuración de muy pequeña escala, tal como cambiar la firma de un método que acepta a un nuevo parámetro, o puede involucrar una restructuración mucho más amplia, tal como reemplazar un algoritmo por otro equivalente o restructurar la jerarquía de herencia. Sin embargo la palabra refactoreo ha ganado popularidad en forma reciente, el software ha necesitado ser restructurado desde que se lo ha estructurado. Ya que, nadie obtiene un diseño correcto la primera vez. 

Herramientas y Técnicas

El refactoreo manual puede ser tedioso y propenso a errores, pero los avances en los ambientes de desarrollo integrados ha hecho que sean posibles las herramientas de refactoreo. Ciertamente, el indicio de un ambiente de desarrollo maduro es que posee herramientas de refactoreo, tales ambientes incluyen actualmente a IntelliJ, Eclipse, Visual Studio y Xcode. Cuando un desarrollador de software genera una entrada sobre una porción de código a refactorear estas herramientas validan automáticamente el refactoreo así como automatizan el cambio del código por sí mismas. Por ejemplo. La herramienta más popular para el refactoreo entre ambientes de desarrollo renombra los elementos del programa. Con esta herramienta de refactoreo de cambio de nombres, un desarrollador selecciona, por ejemplo, un nombre de clase y elige un nombre nuevo, luego la herramienta se asegura que las clases existentes no incluyan ese nombre antes de realizar el cambio y actualizar las referencias correspondientemente. En realidad es un poco más complicado de lo que se ha descripto, pero esta es la idea principal.

Originalmente la idea del refactoreo nació en la comunidad de programación orientada a objetos y se desarrolló para acompañar diferentes paradigmas de programación. Desde la programación lógica a la programación funcional y las bases de datos por eventos, haciendo que la práctica de refactoreo sea aplicable a cada tipo de software imaginable. De la misma forma en que pueden verse patrones en todas partes, si se mira cuidadosamente, también pueden verse patrones de cambio en forma de refactoreo en todas partes.

A pesar de los avances recientes en la práctica del refactoreo, dos grandes desafíos continúan confrontando a los investigadores. El primero relacionado con que las herramientas de refactoreo deben soportar mejor los tipos de cambios que los desarrolladores desean realizar. El segundo, ¿en cómo podemos estar seguros que el refactoreo realizado preserva el comportamiento del programa?

Artículos temáticos

Para la edición de Diciembre de 2015 de Computing Now presentamos cinco artículos que exploran el estado de la práctica del refactoreo.

En el artículo “El Nacimiento del Refactoreo: Una visión en Retrospectiva en la Naturaleza del Alto Impacto de la Investigación en Ingeniería de Software”, Bill Grisworld y Bill Opdyke reflexionan sobre sus experiencias como pioneros en el campo, tanto porque colaboraron en la generación del termino y construyeron las primeras herramientas de refactoreo como parte de sus investigaciones de doctorado. Reflexionando en sus experiencias, los autores les recomiendan a los jóvenes investigadores que no deben estar demasiados preocupados sobre ideas que compitan con este enfoque y que la suerte y las circunstancias juegan un rol significativo en la innovación y que uno debe aprender de los fracasos.

Munawar Hafiz y Jeff Overbey examinan las nociones populares sobre las herramientas que automatizan el refactoreo en el artículo “Mitos del Refactoreo”. Consideran que las ideas de que las herramientas de refactoreo son útiles porque ayudan a automatizar la tediosa tarea de realizar cambios en el diseño y que el beneficio clave de las herramientas de refactoreo es su habilidad de garantizar la preservación del comportamiento y que las herramientas de refactoreo son robustas. Todos estos mitos contienen algo de verdad, pero como Hafiz y Overbey explican, no son totalmente precisas.

El artículo “Como y porque su código Comienza a Oler Mal”, de Michele Tufano y sus colegas; es la ponencia ganadora de la edición 2015 de la Conferencia Internacional en Ingeniería de Software. En él se investigan las ideas del “olor del código”. El cual es un síntoma de un pobre diseño que puede ser aliviado por el refactoreo. Al analizar más de 200 proyectos de código abierto, Tufano y sus colaboradores encuentran evidencia que la mayoría del olor del código no se produce en las tareas del desarrollo evolutivo del software, como la sabiduría convencional sugiere.

Miryung Kim, Thomas Zimmermann y Nachiappan Nagappan realizan una profunda inmersión en el refactoreo en Microsoft al encuestar y entrevistar a los desarrolladores, así como en analizar sus códigos, en el artículo “Un Estudio Empírico de los Desafíos del Refactoreo en Microsoft”. Entre otros detalles, Kim y sus colegas encuentran que los practicantes a menudo distorsionan la definición de refactoreo y que los módulos refactoreados en Windows 7 presentan una reducción relativa de su complejidad.

El articulo final en este tema es “¿Que podemos Refactorear, y Como lo Sabemos?”, un estudio amplio del refactoreo en el cual Chris Parnin, Andrew P Black y yo, construimos sobre nuestra ponencia ganadora. Estudiamos el refactoreo utilizando técnicas múltiples, en algunos casos confirmando y en otros rechazando resultados previos sobre como los desarrolladores refactorean. Por ejemplo, en lugar de refactorear en forma aislada, los desarrolladores, a menudo, entrelazan el refactoreo con otros tipos de cambios, que hacen que las herramientas tradicionales de refactoreo sean de alguna forma tramposas de aplicar.  

Conclusión

El refactoreo continúa siendo una práctica frecuente y necesaria, y concurrentemente un tópico de investigación multiplicador. En la medida que que lee estos artículos y explora material adicional, le ruego colabore conmigo en la construcción del futuro que permita que los desarrolladores puedan refactorear efectivamente, eficientemente y correctamente.

 

Guest Editor

Emerson Murphy-Hill is an associate professor in North Carolina State University’s Department of Computer Science. His research interests include the intersection between human–computer interaction and software engineering. Murphy-Hill received a PhD in computer science from Portland State University. Contact him at emurph3@ncsu.eduhttp://people.engr.ncsu.edu/ermurph3.


Average (0 Votes)
The average rating is 0.0 stars out of 5.

Article Comments

Please log in to comment.