{"id":12275,"date":"2022-07-08T00:00:00","date_gmt":"2022-07-07T22:00:00","guid":{"rendered":"https:\/\/www.kurago.software\/blog\/sin-categorizar\/the-technical-debt-in-software-a-present-issue-with-future-implications\/"},"modified":"2023-10-16T10:03:38","modified_gmt":"2023-10-16T08:03:38","slug":"la-deuda-tecnica-en-software-una-cuestion-de-presente-para-abordar-el-futuro","status":"publish","type":"post","link":"https:\/\/kurago.software\/es\/blog\/make-digital-happen\/la-deuda-tecnica-en-software-una-cuestion-de-presente-para-abordar-el-futuro\/","title":{"rendered":"La deuda t\u00e9cnica en software: una cuesti\u00f3n de presente para abordar el futuro"},"content":{"rendered":"<style>.wp-block-kadence-advancedheading.kt-adv-heading12275_eba057-01, .wp-block-kadence-advancedheading.kt-adv-heading12275_eba057-01[data-kb-block=\"kb-adv-heading12275_eba057-01\"]{font-style:normal;}.wp-block-kadence-advancedheading.kt-adv-heading12275_eba057-01 mark, .wp-block-kadence-advancedheading.kt-adv-heading12275_eba057-01[data-kb-block=\"kb-adv-heading12275_eba057-01\"] mark{font-style:normal;color:#f76a0c;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;}<\/style>\n<h2 class=\"kt-adv-heading12275_eba057-01 post-intro wp-block-kadence-advancedheading\" data-kb-block=\"kb-adv-heading12275_eba057-01\">El objetivo fundamental cuando comenzamos la fase de ideaci\u00f3n de software es aportar soluciones a cuestiones que plantean los usuarios del producto software. Pero la forma en la que se desarrolla ese software influir\u00e1 en su capacidad de adaptaci\u00f3n a nuevas necesidades y, con ello, a la generaci\u00f3n de futuras versiones. Para lograr un software sostenible a largo plazo ser\u00e1 clave que nuevos desarrolladores puedan entender c\u00f3mo est\u00e1 codificado el sistema y sean capaces de ampliarlo, evolucionarlo o actualizarlo. Es aqu\u00ed donde aparecen dos conceptos: el c\u00f3digo legado y la deuda t\u00e9cnica.<\/h2>\n\n\n\n<p>La definici\u00f3n estricta de c\u00f3digo legado es un c\u00f3digo que ha sido creado por alguien y posteriormente debe ser mantenido por otros desarrolladores. Esto en s\u00ed no tiene por qu\u00e9 suponer un problema, siempre que el c\u00f3digo cumpla con ciertas reglas para que, si un tercero tiene que hacerse cargo, pueda entenderlo y adaptarlo a las necesidades sin que suponga un enorme lastre en cuanto a inversi\u00f3n de tiempo.<\/p>\n\n\n\n<p>El c\u00f3digo legado es, sin duda, un asunto importante que puede preocupar a un ingeniero de software, pero la verdadera preocupaci\u00f3n a la hora de asumir el mantenimiento o desarrollo de un software preexistente viene dada por la deuda t\u00e9cnica.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"que-es-la-deuda-tecnica\">\u00bfQu\u00e9 es la deuda t\u00e9cnica?<\/h2>\n\n\n\n<p>En 1992, Ward Cunningham, programador y coautor del Manifiesto por el desarrollo \u00e1gil de software, introdujo el concepto de la deuda t\u00e9cnica. Cunningham quer\u00eda ilustrar la importancia que la refactorizaci\u00f3n, es decir la correcci\u00f3n regular del c\u00f3digo, tiene para el software. Solo de esta forma es posible evitar que un software genere m\u00e1s deuda con el tiempo debido a las crecientes deficiencias operativas y estructurales. La deuda t\u00e9cnica se da cuando se dise\u00f1a una soluci\u00f3n con mentalidad cortoplacista, o economizando en exceso los recursos, pudiendo responder a los requerimientos, pero sin pensar en contar con una estructura de c\u00f3digo que sea legible para los futuros desarrolladores o que lo sea sin requerir un gran mantenimiento. Desarrollar software bajo esta premisa supone a la larga un gran lastre, ya que, para evolucionar ese software, primero habr\u00e1 que resolver aquellas partes que no se optimizaron o se resolvieron de forma \u201cchapucera\u201d.<\/p>\n\n\n\n<p>Es por eso que es fundamental contar con una ingenier\u00eda de software que se responsabilice no solo de resolver los requerimientos establecidos, si no de hacerlo de manera sostenible. Todo software debe evolucionarse y algunas de estas evoluciones afectar\u00e1n a la parte que ya est\u00e1 construida, lo importante es que, si llega ese punto, quien tenga que acometer estos cambios, sea capaz de hacerlo a partir de lo que tiene de la forma m\u00e1s sencilla posible, porque quien lo dise\u00f1o ya pens\u00f3 en esa posibilidad. Si no es as\u00ed, quien venga tendr\u00e1 que encontrar un parche para solucionar determinada cuesti\u00f3n y esto ir\u00e1 lastrando el sistema. Afrontar la creaci\u00f3n de sistemas desde esta perspectiva requiere disciplina y una mayor inversi\u00f3n de horas, pero a larga ser\u00e1 m\u00e1s rentable.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>Es fundamental tener en cuenta los diferentes escenarios en los que el software deber\u00e1 ser capaz de operar, intentando evitar ser restrictivos en la resoluci\u00f3n concreta de los requerimientos de los usuarios.<\/p>\n<\/blockquote>\n\n\n\n<p>Lo importante cuando nos enfrentamos a la creaci\u00f3n de un nuevo sistema software es intentar que, a lo largo del tiempo, seg\u00fan el producto evoluciona y crece, la deuda t\u00e9cnica tienda a cero. Para ello es fundamental tener en cuenta los diferentes escenarios en los que el software deber\u00e1 ser capaz de operar, intentando evitar ser restrictivos en la resoluci\u00f3n concreta de los requerimientos de los usuarios.<\/p>\n\n\n\n<p>Podemos resolver una funcionalidad para un entorno muy acotado y previamente descrito, pero en ese caso, lo que probablemente suceda es que, si posteriormente el \u00e1mbito de aplicaci\u00f3n de ese sistema var\u00eda, el sistema no ser\u00e1 capaz de operar en ese nuevo entorno. Por ejemplo, para resolver un problema de conectividad entre m\u00e1quina y taller, decidimos dise\u00f1ar un sistema que comunique ese modelo de m\u00e1quina espec\u00edfica con el sistema operativo del ordenador que utilizan en taller \u00bfqu\u00e9 pasar\u00e1 cuando cambien de ordenador o de modelo de m\u00e1quina? \u00bfY cu\u00e1ndo incluyan m\u00e1s maquinaria o m\u00e1s ordenadores? Probablemente haya que cambiar de software, hacer un trabajo extra de desarrollo\u2026con lo que el ingeniero de software se encuentra en un constante dilema, entre la priorizaci\u00f3n de los esfuerzos necesarios para preparar los sistemas para que sean capaces de adaptarse a cualquier situaci\u00f3n futura y los costes que esto tiene aparejados.<\/p>\n\n\n\n<p>El objetivo es tener en cuenta aquellas cuestiones que previsiblemente pueden plantearse en la mayor\u00eda de los casos. A la larga, esto supondr\u00e1 una dr\u00e1stica reducci\u00f3n de las horas dedicadas a mejorar funcionalidades o implementar nuevas.<\/p>\n\n\n\n<p>La cuesti\u00f3n que nos planteamos es si la deuda t\u00e9cnica (que se mide en t\u00e9rminos de esfuerzo, y por lo tanto de costes financieros del producto) puede tender a cero y la respuesta es s\u00ed. Lo que es complicado que no exista legacy code, es decir la cantidad de c\u00f3digo utilizado para un software que se va heredando al seguir trabajando en ese sistema. Es bastante com\u00fan que ese c\u00f3digo tenga que ir cambiando, se tengan que ir produciendo mejoras de todo tipo. Pero s\u00ed la soluci\u00f3n, y por tanto el c\u00f3digo, est\u00e1 dise\u00f1ado para ser sostenible estos cambios ser\u00e1n relativamente f\u00e1ciles y no supondr\u00e1n grandes esfuerzos mantener la deuda t\u00e9cnica al m\u00ednimo, ser\u00e1 una inversi\u00f3n de tiempo y dinero acorde al \u00e9xito del producto o sistemas que mantenemos y evolucionamos.&nbsp; Sin embargo, la deuda crece cada vez que se cambia el c\u00f3digo de forma no sostenible.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>Para un ingeniero de software, el cuidado y mantenibilidad del c\u00f3digo fuente debe ser su mayor obsesi\u00f3n<\/p>\n<\/blockquote>\n\n\n\n<p>La clave est\u00e1 en dedicar el tiempo necesario no solo para plantear las necesidades que a futuro este software deber\u00e1 resolver, sino tambi\u00e9n a desarrollar ese software asegurando la integridad t\u00e9cnica, que el software siempre parezca dise\u00f1ado y desarrollado por la misma mano, y la integridad conceptual que todas las partes del sistema se comporten de una manera similar, es decir que la experiencia del usuario sea igual impedientemente que use las partes m\u00e1s antiguas, o las partes m\u00e1s recientes. Dado que el sistema est\u00e1 evolucionando y adopt\u00e1ndose continuamente, provocar\u00e1 que se restrinjan las posibles soluciones de los nuevos desarrollos a orientaciones t\u00e9cnicas que puedan ser\u00e1 aplicados tanto para el nuevo c\u00f3digo como para la parte m\u00e1s legacy del sistema.<\/p>\n\n\n\n<p>Por lo tanto, para un ingeniero de software, el cuidado y mantenibilidad del c\u00f3digo fuente debe ser su mayor obsesi\u00f3n, aplicando las buenas pr\u00e1cticas de la ingeniera de software har\u00e1n que en el futuro sea m\u00e1s sencillo de entender y extender para un tercero. Si este trabajo se hace de manera ortodoxa nuca ser\u00e1 problema heredar c\u00f3digo, ya que habremos reducido la deuda t\u00e9cnica al m\u00e1ximo.<\/p>\n\n\n\n<p>En cualquier caso, esto no significa que la vida del c\u00f3digo de un sistema puede llegar a ser infinita, probablemente lleguemos a un momento en el que haya que empezar casi de cero. La clave es intentar que retrasar ese momento lo m\u00e1ximo posible. Cuanto m\u00e1s se alargue ese ciclo de vida, m\u00e1s exitoso habr\u00e1 sido el producto, tanto para stakeholders, usuarios e ingenieros de software.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Para lograr un software sostenible a largo plazo ser\u00e1 clave que nuevos desarrolladores puedan entender c\u00f3mo est\u00e1 codificado el sistema y sean capaces de ampliarlo, evolucionarlo o actualizarlo.<\/p>\n","protected":false},"author":3,"featured_media":14239,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_eb_attr":"","_gspb_post_css":"","_kad_blocks_custom_css":"","_kad_blocks_head_custom_js":"","_kad_blocks_body_custom_js":"","_kad_blocks_footer_custom_js":"","_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"footnotes":""},"categories":[207],"tags":[250,263,320,345,354,361,364],"taxonomy_info":{"category":[{"value":207,"label":"Make Digital Happen"}],"post_tag":[{"value":250,"label":"agile manifesto"},{"value":263,"label":"code"},{"value":320,"label":"legacy code"},{"value":345,"label":"software"},{"value":354,"label":"software engineer"},{"value":361,"label":"sustainability"},{"value":364,"label":"technical debt"}]},"featured_image_src_large":["https:\/\/kurago.software\/wp-content\/uploads\/2023\/07\/iStock-1319526080-1-2-1200x1063.jpg",1200,1063,true],"author_info":{"display_name":"Asier Ortiz","author_link":"https:\/\/kurago.software\/es\/blog\/author\/asier-ortiz\/"},"comment_info":0,"category_info":[{"term_id":207,"name":"Make Digital Happen","slug":"make-digital-happen","term_group":0,"term_taxonomy_id":207,"taxonomy":"category","description":"","parent":0,"count":15,"filter":"raw","cat_ID":207,"category_count":15,"category_description":"","cat_name":"Make Digital Happen","category_nicename":"make-digital-happen","category_parent":0}],"tag_info":[{"term_id":250,"name":"agile manifesto","slug":"agile-manifesto-es","term_group":0,"term_taxonomy_id":250,"taxonomy":"post_tag","description":"","parent":0,"count":1,"filter":"raw"},{"term_id":263,"name":"code","slug":"code-es","term_group":0,"term_taxonomy_id":263,"taxonomy":"post_tag","description":"","parent":0,"count":1,"filter":"raw"},{"term_id":320,"name":"legacy code","slug":"legacy-code-es","term_group":0,"term_taxonomy_id":320,"taxonomy":"post_tag","description":"","parent":0,"count":1,"filter":"raw"},{"term_id":345,"name":"software","slug":"software-es","term_group":0,"term_taxonomy_id":345,"taxonomy":"post_tag","description":"","parent":0,"count":12,"filter":"raw"},{"term_id":354,"name":"software engineer","slug":"software-engineer-es","term_group":0,"term_taxonomy_id":354,"taxonomy":"post_tag","description":"","parent":0,"count":5,"filter":"raw"},{"term_id":361,"name":"sustainability","slug":"sustainability-es","term_group":0,"term_taxonomy_id":361,"taxonomy":"post_tag","description":"","parent":0,"count":1,"filter":"raw"},{"term_id":364,"name":"technical debt","slug":"technical-debt-es","term_group":0,"term_taxonomy_id":364,"taxonomy":"post_tag","description":"","parent":0,"count":1,"filter":"raw"}],"_links":{"self":[{"href":"https:\/\/kurago.software\/es\/wp-json\/wp\/v2\/posts\/12275"}],"collection":[{"href":"https:\/\/kurago.software\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kurago.software\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kurago.software\/es\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/kurago.software\/es\/wp-json\/wp\/v2\/comments?post=12275"}],"version-history":[{"count":0,"href":"https:\/\/kurago.software\/es\/wp-json\/wp\/v2\/posts\/12275\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/kurago.software\/es\/wp-json\/wp\/v2\/media\/14239"}],"wp:attachment":[{"href":"https:\/\/kurago.software\/es\/wp-json\/wp\/v2\/media?parent=12275"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kurago.software\/es\/wp-json\/wp\/v2\/categories?post=12275"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kurago.software\/es\/wp-json\/wp\/v2\/tags?post=12275"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}