{"id":1256,"date":"2014-08-31T10:50:00","date_gmt":"2014-08-31T09:50:00","guid":{"rendered":"http:\/\/qualilogy.com\/es\/?p=1256"},"modified":"2014-09-01T08:44:08","modified_gmt":"2014-09-01T07:44:08","slug":"aplicacion-legacy-refactorizacion-reingenieria-4","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/es\/aplicacion-legacy-refactorizacion-reingenieria-4\/","title":{"rendered":"Aplicaci\u00f3n Legacy \u2013 \u00bfRefactorizaci\u00f3n o reingenier\u00eda? (IV)"},"content":{"rendered":"<p><a href=\"http:\/\/500px.com\/Vicken\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-full wp-image-1971\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/08\/Qualilogy_Legacy_EditAndPray2.jpg\" alt=\"Qualilogy-Legacy-Reengineering-Refactoring\" width=\"239\" height=\"360\" \/><\/a>La vuelta de las vacaciones del verano nos permite reanudar esta serie de posts sobre el uso de SonarQube con aplicaciones de tipo Legacy, en este caso la primera versi\u00f3n de Word publicado por Microsoft en 1990.<\/p>\n<p class=\"wp-more-tag mce-wp-more\" title=\"Read More...\">Nos planteamos la siguiente hip\u00f3tesis: Microsoft acaba de ser comprada y su nuevo propietario le pide, como consultor de calidad, recomendar una estrategia para esta versi\u00f3n de Word.<\/p>\n<p class=\"wp-more-tag mce-wp-more\" title=\"Read More...\">No creas que esto nunca sucede: empresas de software cambian de manos todos los d\u00edas, y la I+D y el c\u00f3digo del software est\u00e1n en el coraz\u00f3n de esas adquisiciones.<\/p>\n<p class=\"wp-more-tag mce-wp-more\" title=\"Read More...\"><!--more--><\/p>\n<p class=\"wp-more-tag mce-wp-more\" title=\"Read More...\">En concreto, es necesario responder a las siguientes tres preguntas:<\/p>\n<ul>\n<li>\u00bfCu\u00e1l es el coste de transferir la aplicaci\u00f3n a un nuevo equipo de I+D? Esta es la pregunta que surge cada vez que se quiere externalizar una aplicaci\u00f3n Legacy a una empresa de servicios.<\/li>\n<li>\u00a0\u00bfCu\u00e1nto le costar\u00eda a refactorizar la aplicaci\u00f3n para mejorar la calidad y reducir los costes de mantenimiento? Cualquier software Legacy se caracteriza por su deuda t\u00e9cnica elevada. Un refactoring reducir\u00eda los intereses de esta deuda, y por lo tanto los costes de la transferencia de conocimientos a un proveedor externo y \/ o los costes de mantenimiento.<\/li>\n<li>\u00bfCu\u00e1l ser\u00eda el coste de reingenier\u00eda de esta aplicaci\u00f3n? Refactoring a menudo significa replantear el dise\u00f1o o la arquitectura de la aplicaci\u00f3n. \u00bfPor qu\u00e9 no aprovechar esta oportunidad para hacer una migraci\u00f3n a otro lenguaje, m\u00e1s reciente, menos dif\u00edcil de mantener?<\/li>\n<\/ul>\n<p class=\"wp-more-tag mce-wp-more\" title=\"Read More...\">Obviamente, no s\u00f3lo debes tratar de responder a estas tres preguntas, pero tambi\u00e9n proponer un plan de acci\u00f3n para cada una de estas estrategias.<\/p>\n<p class=\"wp-more-tag mce-wp-more\" title=\"Read More...\">En posts anteriores, hemos visto <a title=\"Auditor\u00eda de una aplicaci\u00f3n Legacy en C \u2013 Microsoft Word 1.1a (I)\" href=\"http:\/\/qualilogy.com\/es\/auditoria-aplicacion-legacy-c-microsoft-word-1-1a-1\/\" target=\"_blank\">c\u00f3mo analizar este c\u00f3digo Legacy con SonarQube<\/a> y los resultados obtenidos en t\u00e9rminos de m\u00e9tricas &#8211; tama\u00f1o (LOC), complejidad (CC), comentarios y duplicaciones, as\u00ed como <a title=\"Auditor\u00eda de una aplicaci\u00f3n Legacy en C \u2013 Microsoft Word 1.1a (II)\" href=\"http:\/\/qualilogy.com\/es\/auditoria-aplicacion-legacy-c-microsoft-word-1-1a-2\/\" target=\"_blank\">varios defectos<\/a> Blocker, Critical, Major et Minor.<\/p>\n<p class=\"wp-more-tag mce-wp-more\" title=\"Read More...\">Tambi\u00e9n se verific\u00f3 la existencia de <a title=\"Aplicaci\u00f3n Legacy C \u2013 \u00bfRefactorizaci\u00f3n o reingenier\u00eda? (II)\" href=\"http:\/\/qualilogy.com\/es\/aplicacion-legacy-c-refactorizacion-reingenieria-2\/\" target=\"_blank\">componentes &#8216;monstruos&#8217;<\/a>: funciones y programas grandes y complejos, con un alto n\u00famero de violaci\u00f3nes de las buenas pr\u00e1cticas de programaci\u00f3n, particularmente en t\u00e9rminos de legibilidad y comprensi\u00f3n del c\u00f3digo.<\/p>\n<h2 class=\"wp-more-tag mce-wp-more\" title=\"Read More...\">C\u00f3digo Legacy<\/h2>\n<p class=\"wp-more-tag mce-wp-more\" title=\"Read More...\">\u00bfQu\u00e9 es c\u00f3digo Legacy ?<\/p>\n<p class=\"wp-more-tag mce-wp-more\" title=\"Read More...\">Originalmente, es una aplicaci\u00f3n heredada de una generaci\u00f3n anterior de programadores,\u00a0 desarrollada en un lenguaje de una generaci\u00f3n anterior y que se ejecuta en una plataforma (hardware, sistema operativo, &#8230;) tambi\u00e9n vieja o no m\u00e1s soportada. Se refer\u00eda a c\u00f3digo Cobol Mainframe principalmente.<\/p>\n<p class=\"wp-more-tag mce-wp-more\" title=\"Read More...\">Hoy en d\u00eda, las generaciones de programadores m\u00e1s j\u00f3venes utilizan esta expresi\u00f3n m\u00e1s a menudo para aplicaciones antiguas (m\u00e1s de 5 a 10 a\u00f1os) y \/ o sin interfaz web y \/ o escrita en lenguajes no orientados a objeto (C, Forms, PowerBuilder, Visual Basic, etc.)<\/p>\n<p>En todos los casos, el t\u00e9rmino &#8216;Legacy&#8217; evoca un c\u00f3digo dif\u00edcil de entender, con una deuda t\u00e9cnica grande y escasa y anticuada documentaci\u00f3n .<\/p>\n<h2 class=\"wp-more-tag mce-wp-more\" title=\"Read More...\">Modificar y Rezar<\/h2>\n<p class=\"wp-more-tag mce-wp-more\" title=\"Read More...\">De acuerdo con Michael Feathers, autor famoso de un libro muy recomendado \u2013 \u00abWorking Effectively with Legacy Code\u00bb \u2013 el c\u00f3digo Legacy se caracteriza por la ausencia de pruebas.<\/p>\n<p class=\"wp-more-tag mce-wp-more\" title=\"Read More...\">En el cap\u00edtulo \u20182 \u2013 Working with Feedback\u2019 de su libro, describe un proceso muy com\u00fan, especialmente en los departamentos de I+D de las empresas de software: \u00abModificar y Rezar\u00bb (para que sigue funcionando). Cuando tiene que realizar una evoluci\u00f3n, el desarrollador planifica cuidadosamente su trabajo, primero se asegura de que entiende completamente el c\u00f3digo que modificar y los posibles impactos, el implementa los cambios, compila y luego comprueba que funciona correctamente, y realiza algunas pruebas adicionales aqu\u00ed y all\u00e1 en las \u00e1reas potencialmente afectadas para asegurarse de que no se ha roto nada. Luego trasladar\u00e1 su evoluci\u00f3n a un equipo de testers que realizar\u00e1n una serie de pruebas de regresi\u00f3n y otras pruebas m\u00e1s o menos automatizadas, para garantizar el comportamiento correcto de la aplicaci\u00f3n.<\/p>\n<p class=\"wp-more-tag mce-wp-more\" title=\"Read More...\">En el mejor de los casos, estas pruebas se realizar\u00e1n durante la noche, y los desarrolladores conocer\u00e1n los resultados al d\u00eda siguiente, as\u00ed que si el c\u00f3digo es v\u00e1lido, o al menos validado. En la mayor\u00eda de los casos, todos los cambios de la semana se pondr\u00e1n a prueba en el fin de la semana, con un poco de prueba manual adicional, y la validaci\u00f3n del c\u00f3digo nuevo s\u00f3lo se realizar\u00e1 la semana siguiente.<\/p>\n<p class=\"wp-more-tag mce-wp-more\" title=\"Read More...\">Otra pr\u00e1ctica que sigue siendo com\u00fan hoy en d\u00eda entre los proveedores de software es definir:<\/p>\n<ul>\n<li>una fecha de lanzamiento de una nueva versi\u00f3n del software, por ejemplo, el 15 de octubre;<\/li>\n<li>un per\u00edodo de desarrollo en el que se implementan los cambios, por ejemplo, hasta el 20 de septiembre;<\/li>\n<li>un per\u00edodo de control de calidad (entre el 20\/09 y el 15\/10) durante el cual todas las solicitudes de cambio se congelan, la nueva versi\u00f3n va a las manos del equipo de QA, ning\u00fan nuevo desarrollo se pone en marcha y los desarrolladores se dedican exclusivamente a la correcci\u00f3n de los problemas descubiertos por QA.<\/li>\n<\/ul>\n<h2 class=\"wp-more-tag mce-wp-more\" title=\"Read More...\">Encubrir y Modificar<\/h2>\n<p>Otra forma de trabajar seg\u00fan Michael Feathers es realizar una cobertura de pruebas unitarias para proteger nuestro c\u00f3digo de las consecuencias de los cambios, como una red de seguridad. \u00bfCu\u00e1les son los beneficios de una buena cobertura de pruebas?<\/p>\n<ul>\n<li>Tienes una serie de pruebas que se ejecutan cada vez que realizas un cambio, con \u00e9xito la mayor\u00eda de las veces. A veces te equivocas, por ejemplo cambiando la l\u00f3gica de una condici\u00f3n, y una o m\u00e1s de las pruebas fallan. Corriges el error en un minuto: el feedback es instant\u00e1neo, sin necesidad de esperar hasta ma\u00f1ana, la semana o la fecha de la fase de control de calidad para ver si los cambios realizados en el c\u00f3digo han introducido un bug o una regresi\u00f3n.<\/li>\n<li>Debes cambiar este m\u00e9todo o una funci\u00f3n muy grande y compleja. Esta es una oportunidad para hacer una refactorizaci\u00f3n y hacer un &#8216;split&#8217; (dividir) este m\u00e9todo en varios otros m\u00e1s simples. Pero temes que un cambio rompa lo que funcion\u00f3 antes. \u00abNo lo arregles si no est\u00e1 roto\u00bb se dice a menudo (\u201cDon\u2019t fix it if it ain\u2019t broke\u201d): que es por desgracia la mejor manera de desarrollar nuevo c\u00f3digo Legacy encima del c\u00f3digo Legacy existente. Si tienes pruebas unitarias, no solamente t\u00fa mismo pero tambi\u00e9n todo el equipo tendran una mayor confianza en los cambios. Puedes mejorar el c\u00f3digo existente como evitar la inflaci\u00f3n de la deuda t\u00e9cnica, y sobre todo trabajar con la agradable sensaci\u00f3n de desarrollar c\u00f3digo de calidad en lugar de a\u00f1adir nuevo peso a la carga ya bastante pesada sobre tus hombros.<\/li>\n<li>Realizas algunas nuevas pruebas unitarias para cubrir tu desarrollo y probarlo. Cualquier modificaci\u00f3n futura que har\u00eda un otro miembro de tu equipo ser\u00e1 m\u00e1s f\u00e1cil, m\u00e1s r\u00e1pida y m\u00e1s segura.<\/li>\n<\/ul>\n<p>Contrariamente a lo que pudiera pensarse, el desarrollo de las pruebas unitarias no significa el doble de trabajo o desarrollar m\u00e1s lentamente. El c\u00f3digo para estas pruebas suele ser muy sencilla, y si representa una carga de trabajo adicional, en realidad no es tan importante en comparaci\u00f3n con los beneficios. Tambi\u00e9n es una pr\u00e1ctica cada vez m\u00e1s com\u00fan, hasta el punto de que la ausencia de pruebas se considera uno de los\u00a0<a title=\"Les 7 p\u00e9ch\u00e9s capitaux\" href=\"http:\/\/docs.codehaus.org\/display\/SONAR\/Lack+of+Unit+Tests\" target=\"_blank\">siete pecados capitales del desarrollo<\/a>.<\/p>\n<p>De todos modos, la escritura de c\u00f3digo no es el coste m\u00e1s importante: un desarrollador pasa m\u00e1s tiempo tratando de entender el c\u00f3digo que tiene que cambiar en lugar de desarrollar este cambio. De hecho, ni siquiera se puede estimar el tiempo requerido para implementar un cambio si ya no conoces el c\u00f3digo existente y lo que hace.<\/p>\n<p>La raz\u00f3n por qu\u00e9 la legibilidad y la comprensibilidad del c\u00f3digo son una de las fuentes m\u00e1s importantes de los altos costes de mantenimiento es el hecho de que el tiempo dedicado a la programaci\u00f3n es insignificante en comparaci\u00f3n con el tiempo necesario para entender lo que el c\u00f3digo hace y c\u00f3mo implementar los cambios sin introducir un defecto.<br \/>\nPero si ya tiene las pruebas unitarias, usualmente muy simples, muy legibles, puedes reducir enormemente estas cargas.<\/p>\n<p>Pero \u00bfqu\u00e9 pasa en nuestro caso, cuando nuestra aplicaci\u00f3n Legacy ya no tiene esas pruebas unitarias? Esto es lo que veremos en el pr\u00f3ximo post.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>La vuelta de las vacaciones del verano nos permite reanudar esta serie de posts sobre el uso de SonarQube con aplicaciones de tipo Legacy, en este caso la primera versi\u00f3n de Word publicado por Microsoft en 1990. Nos planteamos la siguiente hip\u00f3tesis: Microsoft acaba de ser comprada y su nuevo propietario le pide, como consultor [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-1256","post","type-post","status-publish","format-standard","hentry","category-calidad-de-aplicaciones"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/1256"}],"collection":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/comments?post=1256"}],"version-history":[{"count":19,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/1256\/revisions"}],"predecessor-version":[{"id":1277,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/1256\/revisions\/1277"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/media?parent=1256"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/categories?post=1256"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/tags?post=1256"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}