{"id":1400,"date":"2014-10-15T18:45:27","date_gmt":"2014-10-15T17:45:27","guid":{"rendered":"http:\/\/qualilogy.com\/es\/?p=1400"},"modified":"2014-10-20T09:22:03","modified_gmt":"2014-10-20T08:22:03","slug":"aplicacion-legacy-refactoring-plugin-sqale-2","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/es\/aplicacion-legacy-refactoring-plugin-sqale-2\/","title":{"rendered":"Aplicaci\u00f3n Legacy \u2013 Refactoring con el plugin SQALE (II)"},"content":{"rendered":"<p><a href=\"http:\/\/500px.com\/Vicken\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-full wp-image-2126\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtRefactoring3.jpg\" alt=\"LegacyTechDebtRefactoring3\" width=\"367\" height=\"543\" \/><\/a>Como le hemos visto <a title=\"Aplicaci\u00f3n Legacy \u2013 Refactoring con el plugin SQALE (I)\" href=\"http:\/\/qualilogy.com\/es\/aplicacion-legacy-refactoring-plugin-sqale-1\/\" target=\"_blank\">en el post anterior<\/a>, no he personalizado el Quality Profile de SonarQube ni el modelo SQALE, para nuestra aplicaci\u00f3n Legacy,\u00a0 seg\u00fan nuestro contexto y\u00a0 la orientaci\u00f3n que queremos para la evaluaci\u00f3n du su deuda t\u00e9cnica.<\/p>\n<p>De hecho, hemos utilizado los resultados &#8216;out of the box&#8217; para ilustrar un posible enfoque en la valoraci\u00f3n del coste de refactorizaci\u00f3n, y presentar al equipo del proyecto y a los managers algunas ideas y \u00e1reas de mejora.<\/p>\n<p>En otras palabras,\u00a0nos interesa m\u00e1s el proceso que los resultados, por lo menos en el contexto de estos art\u00edculos.<\/p>\n<p>Veamos ahora unas propuestas de plan de acci\u00f3n. <!--more--><\/p>\n<h2>Corregir los defectos m\u00e1s cr\u00edticos<\/h2>\n<p>La primera cosa que puedo hacer con el widget que me he configurado (ver <a title=\"Aplicaci\u00f3n Legacy \u2013 Refactoring con el plugin SQALE (I)\" href=\"http:\/\/qualilogy.com\/es\/aplicacion-legacy-refactoring-plugin-sqale-1\/\" target=\"_blank\">Figura 1 &#8211; Los datos <\/a><a title=\"Aplicaci\u00f3n Legacy \u2013 Refactoring con el plugin SQALE (I)\" href=\"http:\/\/qualilogy.com\/es\/aplicacion-legacy-refactoring-plugin-sqale-1\/\" target=\"_blank\">SQALE <\/a><a title=\"Aplicaci\u00f3n Legacy \u2013 Refactoring con el plugin SQALE (I)\" href=\"http:\/\/qualilogy.com\/es\/aplicacion-legacy-refactoring-plugin-sqale-1\/\" target=\"_blank\">de la deuda t\u00e9cnica<\/a>) es que nos cuesta:<\/p>\n<ul>\n<li>59.6 d\u00edas para remediar las &#8216;Issues&#8217; de tipo &#8216;Critical&#8217; y m\u00e1s all\u00e1, es decir\u00a0&#8216;Critical&#8217; y &#8216;Blocker&#8217;.<\/li>\n<li>1 115.6 d\u00edas para las &#8216;Issues&#8217; &#8216;Major&#8217;, &#8216;Critical&#8217; y &#8216;Blocker&#8217;.<\/li>\n<\/ul>\n<p>Tengo la misma informaci\u00f3n en el siguiente widget:<\/p>\n<p style=\"text-align: center\"><em><strong>Figura 1 \u2013 SQALE Remediation Cost por criticidad<br \/>\n<\/strong><\/em><\/p>\n<p><a href=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtCriticity.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-2132\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtCriticity.jpg\" alt=\"Legacy Technical Debt Criticity\" width=\"583\" height=\"179\" \/><\/a><\/p>\n<p>El \u00e1rea azul oscuro en cada una de las barras horizontales en este gr\u00e1fico corresponde a la barra anterior, para calcular un coste por cada criticidad y el coste total, como se muestra en las dos columnas de la derecha.<\/p>\n<p><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\">Hab\u00edamos visto<\/a> que no ten\u00edamos defectos de tipo\u00a0&#8216;Blocker&#8217; pero s\u00ed 753 de tipo &#8216;Critical&#8217;, la mayor\u00eda de ellos concentrados en dos reglas.<\/p>\n<p style=\"text-align: center\"><em><strong>Figura 2 &#8211; Violaci\u00f3nes a reglas &#8216;Critical&#8217;<\/strong><\/em><\/p>\n<p><a href=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/04\/C_World_Crticals.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-1797\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/04\/C_World_Crticals.jpg\" alt=\"C_World_Crticals\" width=\"583\" height=\"207\" \/><\/a><\/p>\n<p>La siguiente figura lista los archivos que contienen estos defectos y los costes de remediaci\u00f3n:<\/p>\n<p style=\"text-align: center\"><em><strong>Figura 3 \u2013 SQALE Remediation Cost \u2013 Critical y Blockers<\/strong><\/em><\/p>\n<p><a href=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtFilesCriticalIssues.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-2134\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtFilesCriticalIssues.jpg\" alt=\"Legacy Technical Debt Files Critical Issues\" width=\"352\" height=\"327\" \/><\/a><\/p>\n<p>Puedo abrir cada archivo en SonarQube, y elegir ver solo ciertas &#8216;Issues&#8217;. La siguiente figura muestra el programa &#8216;fltexp.c&#8217; y unos defectos &#8216;Critical&#8217;.<\/p>\n<p><a href=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechfltexpCritical.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-2137\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechfltexpCritical.jpg\" alt=\"LegacyTechfltexpCritical\" width=\"833\" height=\"342\" \/><\/a><\/p>\n<p>Para cada uno de los 16 defectos de tipo cr\u00edtico en este programa, puedo ver:<\/p>\n<ul>\n<li>La l\u00ednea de c\u00f3digo.<\/li>\n<li>El coste de remediaci\u00f3n de este defecto, tal como est\u00e1 configurado en el plugin SQALE: 1 hora en el primer caso (MISRA C++ 6-6-1) y 15 minutos en el segundo (MISRA C++ 5-14-1).<\/li>\n<\/ul>\n<p>Basandonos en estos n\u00fameros, podemos proponer una primera acci\u00f3n de refactorizaci\u00f3n de los componentes con defectos cr\u00edticos para un total de aproximadamente 60 d\u00edas, o 12 d\u00edas para un equipo de 5 personas.<\/p>\n<p>En realidad, voy a trabajar con el equipo de proyecto para estimar los defectos que ellos ven o no cr\u00edticos (o &#8216;Blocker&#8217;), el tiempo que consideran necesario para resolver cada uno, y as\u00ed establecer un Quality Profile (conjunto de reglas SonarQube) personalizado.<\/p>\n<h2>Restablecer el SQALE Rating al nivel A<\/h2>\n<p>Con el widget que me he configurado (ver <a title=\"Aplicaci\u00f3n Legacy \u2013 Refactoring con el plugin SQALE (I)\" href=\"http:\/\/qualilogy.com\/es\/aplicacion-legacy-refactoring-plugin-sqale-1\/\" target=\"_blank\">Figura 1 &#8211; Los datos de la deuda t\u00e9cnica <\/a><a title=\"Aplicaci\u00f3n Legacy \u2013 Refactoring con el plugin SQALE (I)\" href=\"http:\/\/qualilogy.com\/es\/aplicacion-legacy-refactoring-plugin-sqale-1\/\" target=\"_blank\">SQALE<\/a>), tambi\u00e9n puedo ver que nos cuesta 291.9 d\u00edas para llevar el SQALE Rating desde B, el nivel actual hacia una clasificaci\u00f3n de nivel A. El SQALE Rating mide\u00a0<a href=\"http:\/\/www.sonarsource.com\/products\/plugins\/governance\/sqale\/installation-and-usage\/#understandingSqaleRatings\" target=\"_blank\">la carga de la deuda en la aplicaci\u00f3n<\/a>, de la siguiente manera en nuestro caso:<\/p>\n<ul>\n<li>B: entre 10% y 20%.<\/li>\n<li>A: menos o igual a 10%.<\/li>\n<\/ul>\n<p>Con <a title=\"Aplicaci\u00f3n Legacy \u2013 \u00bfRefactorizaci\u00f3n o reingenier\u00eda? (VII)\" href=\"http:\/\/qualilogy.com\/es\/aplicacion-legacy-refactorizacion-reingenieria-7\/\" target=\"_blank\">18.5 d\u00edas de trabajo al mes<\/a>, estos 291.9 d\u00edas representan 15.8 meses en total, o 3 meses y 3 d\u00edas por desarrollador para un equipo de 5 personas. Si a\u00f1ado una carga de gesti\u00f3n de proyectos de 20%, que es la cifra por defecto para toda planificaci\u00f3n, pasamos a 3 meses y 15 d\u00edas por desarrollador.<\/p>\n<p>Hemos visto que <a title=\"Aplicaci\u00f3n Legacy \u2013 \u00bfRefactorizaci\u00f3n o reingenier\u00eda? (VII)\" href=\"http:\/\/qualilogy.com\/es\/aplicacion-legacy-refactorizacion-reingenieria-7\/\" target=\"_blank\">la realizaci\u00f3n de las pruebas de caracterizaci\u00f3n<\/a> necesitan unos tres meses, con un poco de margen para la gesti\u00f3n de proyecto, lo que es aceptable en un contexto de transferencia de conocimientos. Si a\u00f1adimos otros 3 meses y algunos d\u00edas, nuestro proyecto de refactorizaci\u00f3n pasa a seis o siete meses, que creo aceptable para fiabilizar nuestra aplicaci\u00f3n con pruebas unitarias y llevarla a un nivel muy decente de deuda t\u00e9cnica.<\/p>\n<p>En realidad, es muy dif\u00edcil para los directivos de justificar a los usuarios paralizar el desarrollo \u2013 especialmente toda correcci\u00f3n \u2013 durante ese per\u00edodo. No s\u00e9 nada del backlog en t\u00e9rminos de &#8216;Change Requests&#8217; de los usuarios, as\u00ed como las cargas promedio de correcci\u00f3n por mes que debemos tomar en cuenta en la planificaci\u00f3n de la refactorizaci\u00f3n: as\u00ed que voy a satisfecerme de s\u00f3lo estos 292 d\u00edas y voy a tratar optimizarlos con el fin de construir un plan de mejoras, admisible o al menos posible para los directivos.<\/p>\n<p>La pir\u00e1mide SQALE nos ayudar\u00e1 a elegir entre las diferentes categor\u00edas de violaci\u00f3nes de &#8216;best practices&#8217;.<\/p>\n<p style=\"text-align: center\"><em><strong>Figura 4 \u2013 SQALE Tecnical Debt Pyramid<\/strong><\/em><\/p>\n<p><a href=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtPyramid.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-2139\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtPyramid.jpg\" alt=\"Legacy Technical Debt SQALE Pyramid\" width=\"583\" height=\"250\" \/><\/a><\/p>\n<p>Cada factor de nivel superior tiene una serie de &#8216;caracter\u00edsticas&#8217; que recoger\u00e1n cada una sus propias m\u00e9tricas. La siguiente figura muestra la pantalla de configuraci\u00f3n SQALE en SonarQube, que se utiliza para establecer el coste de remediaci\u00f3n para cada violaci\u00f3n a una &#8216;best practice&#8217; de programaci\u00f3n dentro de cada categor\u00eda, en el siguiente ejemplo, las \u2018Characteristics\u2019 de \u2018Testability\u2019.<\/p>\n<p style=\"text-align: center\"><strong><em>Figura 5 &#8211; Configuraci\u00f3n de reglas en el modelo SQALE<\/em><\/strong><\/p>\n<p><a href=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtSQALEQualityProfile.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-2140\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtSQALEQualityProfile.jpg\" alt=\"Legacy Technical Debt SQALE Quality Profile Configuration\" width=\"552\" height=\"384\" \/><\/a><\/p>\n<p>No tengo reglas para la\u00a0\u2018Reusability\u2019 en este perfil para los lenguajes C\/C++, lo que explica la deuda t\u00e9cnica a 0 en este factor (ver la Figura 4 anterior).<\/p>\n<p>La\u00a0\u2018Portability\u2019 ve una \u00fanica regla infringida, con una deuda t\u00e9cnica de 3.5 d\u00edas, pero es importante solamente en el caso de volver a escribir la aplicaci\u00f3n en C++. Entonces esto debe tenerse en cuenta como parte de una reingenier\u00eda, pero no una refactorizaci\u00f3n.<\/p>\n<p style=\"text-align: center\"><em><strong>Figura 6 &#8211; Regla de \u2018Portability\u2019<\/strong><\/em><\/p>\n<p><a href=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtPortability.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-2141\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtPortability.jpg\" alt=\"Legacy Technical Debt SQALE Characteristic Portability\" width=\"764\" height=\"81\" \/><\/a><\/p>\n<p>Es lo mismo para las reglas relativas a la &#8216;Testability&#8217; (ver la figura 5 anterior como &#8216;Avoid too complex file\u2019, \u2018Avoid too complex function\u2019, el n\u00famero de par\u00e1metros de una funci\u00f3n o el uso de &#8216;Goto&#8217; y &#8216;Continue&#8217;: refactorizar este tipo de defecto requiere un redise\u00f1o de la aplicaci\u00f3n, por lo que una vez m\u00e1s, se debe considerar en una reingenier\u00eda. Porque si necesitamos pensar de nuevo el dise\u00f1o y la arquitectura de la aplicaci\u00f3n con el fin de distribuir mejor la complejidad, entonces podemos tomar la oportunidad de volver a escribirla en un lenguaje orientado a objetos como C++, y beneficiarse de la herencia, la encapsulaci\u00f3n y el polimorfismo.<\/p>\n<p>Lo mismo para la &#8216;Changeability&#8217;. La siguiente figura muestra el\u00a0SQALE Sunburst con:<\/p>\n<ul>\n<li>En el nivel 1, los diferentes factores de Maintainability, Testability, Reliability, etc.<\/li>\n<li>En el Nivel 2, las &#8216;caracter\u00edsticas&#8217; dentro de estos factores, como Undestandibility et Readibility pour la Maintainability.<\/li>\n<li>En el Nivel 3, las reglas dentro de cada caracter\u00edstica.<\/li>\n<\/ul>\n<p style=\"text-align: center\"><em><strong>Figura 7 &#8211; Reglas de \u2018Changeability\u2019 en el SQALE Sunburst<br \/>\n<\/strong><\/em><\/p>\n<p><a href=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtSQALESunburstChangeability.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-2142\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtSQALESunburstChangeability.jpg\" alt=\"Legacy Technical Debt SQALE Sunburst Changeability\" width=\"579\" height=\"598\" \/><\/a><\/p>\n<p>Podemos ver en esta figura que los 13.7 d\u00edas de deuda t\u00e9cnica para la &#8216;Changeability&#8217; cubre una sola regla de &#8216;if&#8217; anidado. Lo m\u00e1s tenemos &#8216;if&#8217; dentro de &#8216;if&#8217;, lo m\u00e1s dif\u00edcil es entender el c\u00f3digo, y m\u00e1s alto el riesgo de introducir un error en relaci\u00f3n con un cambio en el c\u00f3digo.<\/p>\n<p>Una regla de este tipo podr\u00eda encontrarse tambi\u00e9n en la &#8216;caracter\u00edstica&#8217; de &#8216;Understandibility&#8217;. De hecho, muchas de las reglas de &#8216;Maintainability&#8217; suelen ser candidatas para el grupo &#8216;Changeability&#8217;. Raz\u00f3n por la cual se recomienda de nuevo personalizar el modelo SQALE de acuerdo con su propio caso de uso, y no usarlo &#8216;out of the box&#8217; como lo he hecho para este art\u00edculo.<\/p>\n<p>En cualquier caso, estos defectos de &#8216;if&#8217; anidados est\u00e1n bien dentro del objetivo de una refactorizaci\u00f3n, y podemos incluir estos 13.7 d\u00edas en nuestro plan de acci\u00f3n.<br \/>\nEn la figura siguiente, insert\u00e9 (copiando y pegando) diferentes medidas:<\/p>\n<ul>\n<li>La &#8216;Maintainability&#8217; : 738 d\u00edas refactorizaci\u00f3n en total, que se dividen en &#8230;<\/li>\n<li>505.6 d\u00edas para la &#8216;Understandibility&#8217; y 232.3 d\u00edas para la &#8216;Readability&#8217;.<\/li>\n<\/ul>\n<p style=\"text-align: center\"><em><strong>Figura 8 \u2013 SQALE Sunburst para la Maintainability<\/strong><\/em><\/p>\n<p><a href=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtSQALESunburstMaintainability2.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-2144\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtSQALESunburstMaintainability2.jpg\" alt=\"Legacy Technical Debt SQALE Sunburst Maintainability\" width=\"808\" height=\"562\" \/><\/a><\/p>\n<p>Podemos observar que los costes de remedi\u00e1ci\u00f3n m\u00e1s altos se encuentran en reglas que no son necesariamente cr\u00edticas. Que Microsoft no utiliz\u00f3 hace 20 a\u00f1os las convenciones de nomenclatura habitual hoy en d\u00eda para las macros, no es ni sorprendente ni realmente muy importante, y la resoluci\u00f3n de estos defectos a un coste de 128.1 d\u00edas de refactorizaci\u00f3n no representa verdaderamente una ganancia lo suficiente importante como para considerar dicha acci\u00f3n.<\/p>\n<p>Es lo mismo para el uso de &#8216;braces&#8217; con &#8216;if..else&#8217; que enumera una gran cantidad de &#8216;if&#8217; en una \u00fanica l\u00ednea, de manera muy legible y muy comprensible sin necesidad de llaves\u00a0en el principio y el final de esta instrucci\u00f3n. Poco beneficio pero un coste muy alto.<\/p>\n<p>No, hay mejor que los defectos de &#8216;Maintainability&#8217; para optimizar los 291 d\u00edas necesarios para llevar la deuda t\u00e9cnica al nivel A. Podemos ver en la pir\u00e1mide SQALE (Figura 4) que los defectos de &#8216;Reliability&#8217; requieren 291.8 d\u00edas de refactorizaci\u00f3n, lo que conviene a la perfecci\u00f3n con nuestra cantidad de d\u00edas disponibles (m\u00e1s o menos 3 meses para nuestro equipo de 5 personas).<\/p>\n<p>Adem\u00e1s, son defectos que afectan a la fiabilidad y la robustez de la aplicaci\u00f3n, y por lo tanto presentan un riesgo para el cliente o el usuario final, cuando los defectos en la mantenibilidad sin duda pesan sobre los costes de mantenimiento, pero nunca causar\u00e1n errores y bugs. Obviamente, esto depende de nuevo de la orientaci\u00f3n que deseamos para el modelo SQALE, personalizando hacia la satisfacci\u00f3n del usuario o bien a favor de la preservaci\u00f3n del presupuesto.<\/p>\n<p>Primero veo que los 59.6 d\u00edas que se necesitan para arreglar violaci\u00f3nes de tipo &#8216;Critical&#8217; (ver Figura 2 anterior) se refieren a las reglas dentro de la &#8216;Reliability&#8217;. La siguiente tabla muestra las diferentes normas y los costes de remediaci\u00f3n.<\/p>\n<p style=\"text-align: center\"><em><strong>Tabla 1 &#8211; Los costes de remediaci\u00f3n de defectos en\u00a0Reliability<br \/>\n<\/strong><\/em><\/p>\n<p><a href=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtReliabilityCost.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-2146\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtReliabilityCost.jpg\" alt=\"Legacy Technical Debt Reliability Cost\" width=\"586\" height=\"305\" \/><\/a><\/p>\n<p>Todas estas reglas mejoran la robustez de la aplicaci\u00f3n y reducen el riesgo de error. Si a\u00f1ado los 13.7 d\u00edas de &#8216;Changeability&#8217; para eliminar los &#8216;if&#8217; anidados, pasamos a 305.5 d\u00edas, o 16.5 meses o 3 meses y 6 d\u00edas por desarrollador (sin incluir los costes de gesti\u00f3n del proyecto).<\/p>\n<p>Dicho esto, el peso de gesti\u00f3n del proyecto no debe ser enorme, ya que el plan de acci\u00f3n, desde un punto de vista operativo, est\u00e1 en el plugin SQALE. Hemos visto (<a title=\"Aplicaci\u00f3n Legacy \u2013 Refactoring con el plugin SQALE (I)\" href=\"http:\/\/qualilogy.com\/es\/aplicacion-legacy-refactoring-plugin-sqale-1\/\" target=\"_blank\">Figura 2 del post anterior<\/a>) que tenemos la distribuci\u00f3n de programas en la escala del Rating SQALE. En la siguiente figura, puedo ver la lista de los archivos con la calificaci\u00f3n m\u00e1s baja.<\/p>\n<p style=\"text-align: center\"><em><strong>Figura 9 \u2013 SQALE Rating de los ficheros<a href=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtRateBFiles.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-2147\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtRateBFiles.jpg\" alt=\"Legacy Technical Debt Rate Files\" width=\"469\" height=\"203\" \/><\/a> <\/strong><\/em><\/p>\n<p style=\"text-align: left\">Cabe se\u00f1alar que son archivos .h, de hecho con la nota muy baja debido al gran n\u00famero de violaci\u00f3nes a la regla\u00a0\u2018Macro names should comply with a naming convention\u2019. De ah\u00ed la importancia de nuevo de personalizar el perfil de calidad y el modelo SQALE.<\/p>\n<h2 style=\"text-align: left\">Gesti\u00f3n de la deuda t\u00e9cnica\u00a0sobre la marcha<\/h2>\n<p style=\"text-align: left\">Corregir los defectos m\u00e1s cr\u00edticos nos cuesta 59.5 d\u00edas, cerca de 12 d\u00edas para un equipo de 5 desarrolladores.<\/p>\n<p style=\"text-align: left\">Reducir la deuda t\u00e9cnica de nuestra aplicaci\u00f3n hacia un Rating SQALE de nivel A requiere aproximadamente 300 d\u00edas, un poco m\u00e1s de tres meses para nuestro equipo, que los directivos o los stakeholders podr\u00edan considerar un esfuerzo demasiado alto.<\/p>\n<p style=\"text-align: left\">Una soluci\u00f3n intermedia ser\u00eda una gesti\u00f3n de la deuda t\u00e9cnica sobre la marcha, es decir, en paralelo a las acciones de mantenimiento de la aplicaci\u00f3n. Cada vez que un desarrollador tendr\u00e1 que hacer un cambio o una correcci\u00f3n en un programa, tambi\u00e9n utilizar\u00e1 el plugin SQALE para verificar:<\/p>\n<ul>\n<li style=\"text-align: left\">Si la deuda t\u00e9cnica aumenta. Este es el principal uso del plugin SQALE para un desarrollador, como ya comentamos en el post anterior: evitar la inflaci\u00f3n de la deuda t\u00e9cnica y encontrarnos en unos a\u00f1os con una aplicaci\u00f3n imposible de mantener.<\/li>\n<li style=\"text-align: left\">Si es posible reducirla con los cambios que se deben alcanzar, centr\u00e1ndose en las reglas que hemos definido como cr\u00edticas en el plugin SQALE.<\/li>\n<li style=\"text-align: left\">Si no se ha incrementado la deuda t\u00e9cnica despu\u00e9s de la aplicaci\u00f3n de esos cambios.<\/li>\n<\/ul>\n<p>No hay necesidad de pedir al desarrollador de cumplir con m\u00e1s de 10 buenas pr\u00e1cticas: m\u00e1s all\u00e1 de eso, se vuelve demasiado complicado de recordar todo. Tambi\u00e9n depende de la experiencia de los desarrolladores y su nivel de conocimiento, si no de madurez en las mejores pr\u00e1cticas. Pero incluso los desarrolladores m\u00e1s experimentados cometen errores porque no se puede evitar toda falta de atenci\u00f3n y todo defecto. De ah\u00ed la importancia de un seguimiento regular de la deuda t\u00e9cnica.<\/p>\n<p>Obviamente, la elecci\u00f3n entre estas diferentes propuestas de planes de acci\u00f3n depender\u00e1, no s\u00f3lo del esfuerzo, sino tambi\u00e9n de los beneficios. \u00bfPodemos proponer una hip\u00f3tesis para el retorno de inversi\u00f3n (ROI)?<\/p>\n<p>Como este post ya es muy largo, voy a terminar este tema de refactorizaci\u00f3n con SQALE con una s\u00edntesis de nuestras propuestas y un intento de calcular el ROI. En el pr\u00f3ximo post.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Como le hemos visto en el post anterior, no he personalizado el Quality Profile de SonarQube ni el modelo SQALE, para nuestra aplicaci\u00f3n Legacy,\u00a0 seg\u00fan nuestro contexto y\u00a0 la orientaci\u00f3n que queremos para la evaluaci\u00f3n du su deuda t\u00e9cnica. De hecho, hemos utilizado los resultados &#8216;out of the box&#8217; para ilustrar un posible enfoque en [&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-1400","post","type-post","status-publish","format-standard","hentry","category-calidad-de-aplicaciones"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/1400"}],"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=1400"}],"version-history":[{"count":34,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/1400\/revisions"}],"predecessor-version":[{"id":1437,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/1400\/revisions\/1437"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/media?parent=1400"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/categories?post=1400"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/tags?post=1400"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}