{"id":263292,"date":"2023-03-02T06:48:00","date_gmt":"2023-03-02T03:48:00","guid":{"rendered":"https:\/\/inform.click\/como-evaluar-administrar-y-evitar-deudas-tecnicas\/"},"modified":"2023-03-02T06:59:00","modified_gmt":"2023-03-02T03:59:00","slug":"como-evaluar-administrar-y-evitar-deudas-tecnicas","status":"publish","type":"post","link":"https:\/\/inform.click\/es\/como-evaluar-administrar-y-evitar-deudas-tecnicas\/","title":{"rendered":"C\u00f3mo evaluar, administrar y evitar deudas t\u00e9cnicas"},"content":{"rendered":"

\n Si la deuda t\u00e9cnica suena como sacada de un manual de finanzas es porque el t\u00e9rmino est\u00e1 relacionado con las finanzas. Sin embargo, en el sentido real de la misma, la deuda t\u00e9cnica est\u00e1 relacionada con la programaci\u00f3n. Es la idea de que durante el desarrollo de un proyecto de software, se omiten ciertos pasos necesarios, o simplemente se descartan por completo en un intento por cumplir con un plazo.\n<\/p>\n

\n En un intento por desarrollar la aplicaci\u00f3n o el software perfecto, los desarrolladores a menudo tienen poco tiempo, al igual que cualquier persona al azar que realiza cualquier tarea arbitraria de todos modos. Por lo tanto, por lo general tiene sentido tener alg\u00fan tipo de compromiso entre entregar un producto perfecto con c\u00f3digo perfecto y maximizar el tiempo.\n<\/p>\n

\n La pregunta entonces es: \u00bfhay un l\u00edmite para estas compensaciones? \u00bfHay da\u00f1os inherentes que podr\u00edan resultar de esta compensaci\u00f3n? Finalmente, \u00bfel desarrollador est\u00e1 realmente mejor a largo plazo? En este art\u00edculo sobre deudas t\u00e9cnicas, intentar\u00e9 responder a todas estas preguntas.\n<\/p>\n

\n \u00bfQu\u00e9 es la deuda t\u00e9cnica?
\n<\/h5>\n

\n Al definir la deuda t\u00e9cnica, tendremos que referirnos al hombre al que se atribuye haber generado el t\u00e9rmino en primer lugar: Ward Cunningham. Seg\u00fan Cunningham, la deuda t\u00e9cnica se refiere al trabajo de desarrollo adicional que se debe realizar para programar un c\u00f3digo para compensar el d\u00e9ficit que surge de programarlo en un per\u00edodo corto.\n<\/p>\n

\n Para hacerlo m\u00e1s gr\u00e1fico, imagina que tienes la tarea de limpiar una habitaci\u00f3n desordenada y llegas tarde a una clase. En un intento por asegurarse de llevar a cabo las instrucciones y llegar a tiempo a su clase, hace una limpieza r\u00e1pida y barre la mayor parte de los escombros debajo del sof\u00e1. La consecuencia de esto es que eventualmente tendr\u00e1 que tomarse el tiempo para ordenar el desorden. Para el desarrollo de software, cuando se salta los pasos necesarios y sigue una ruta m\u00e1s f\u00e1cil, con c\u00f3digos ‘no tan limpios', ser\u00e1 m\u00e1s dif\u00edcil limpiar el c\u00f3digo m\u00e1s adelante en el futuro. Hay m\u00faltiples fases encontradas en el domin\u00f3 del proyecto de software, y cuanto m\u00e1s tiempo ignore un problema existente, m\u00e1s tiempo llevar\u00e1 resolverlo.\n<\/p>\n

\n Tipos de Deudas T\u00e9cnicas\n<\/p>\n

\n Las deudas t\u00e9cnicas son de diferentes tipos, entre ellas:\n<\/p>\n

\n Deudas T\u00e9cnicas Previstas
\n<\/h5>\n

\n Esto ocurre en situaciones en las que las organizaciones deciden deliberadamente contraer deudas t\u00e9cnicas. Esto, como se discuti\u00f3 anteriormente, generalmente es para superar los plazos establecidos y llegar a una meta espec\u00edfica. Al comprometerse con deudas t\u00e9cnicas planificadas, la organizaci\u00f3n debe tener claro a qu\u00e9 est\u00e1 dispuesta a ceder y a qu\u00e9 no. Debe mantener registros precisos, teniendo en cuenta que eventualmente tendr\u00e1 que regresar y corregir los errores que salt\u00f3 al principio.\n<\/p>\n

\n Deudas t\u00e9cnicas no intencionales
\n<\/h5>\n

\n Este tipo de deuda t\u00e9cnica es directamente opuesta a la primera. Surge cuando una organizaci\u00f3n no prev\u00e9 ni planifica la deuda t\u00e9cnica. La raz\u00f3n de esto suele ser una falla en la comunicaci\u00f3n entre las distintas unidades de la organizaci\u00f3n, o malas pr\u00e1cticas de trabajo entre las unidades.\n<\/p>\n

\n Deudas T\u00e9cnicas Ineludibles
\n<\/h5>\n

\n Este es el tipo de deuda t\u00e9cnica que ninguna acci\u00f3n por parte de la organizaci\u00f3n podr\u00eda haber evitado. Por ejemplo, con los r\u00e1pidos cambios experimentados en la tecnolog\u00eda, tiene sentido que algunos c\u00f3digos escritos en el pasado no alcancen los est\u00e1ndares actuales proyectados.\n<\/p>\n

\n Adem\u00e1s, este tipo de deuda t\u00e9cnica puede surgir cuando se solicitan cambios cuando el c\u00f3digo ya se est\u00e1 escribiendo. Si a mitad de camino en el dise\u00f1o del software, se introducen ciertos cambios, podr\u00eda estropear la din\u00e1mica, haciendo que el c\u00f3digo antiguo se vuelva obsoleto o innecesario.\n<\/p>\n

\n Causas de la Deuda T\u00e9cnica
\n<\/h3>\n

\"\"<\/a><\/p>\n

\n Algunas de las razones de la deuda t\u00e9cnica se han discutido anteriormente, pero las seleccionar\u00e9 una tras otra para aclararlas.\n<\/p>\n

\n Prisa
\n<\/h5>\n

\n La causa m\u00e1s frecuente de la deuda t\u00e9cnica es la prisa. Los desarrolladores a menudo tienen plazos estrictos, algunos de los cuales incluyen plazos para lanzar cierto software. A menudo es comprensible (y esperado) en este tipo de situaciones que el desarrollador pueda incurrir en deudas t\u00e9cnicas en el camino. Este tipo de deuda t\u00e9cnica a menudo es intencional y puede dar lugar a problemas que pueden ir desde errores en el c\u00f3digo o la aparici\u00f3n de c\u00f3digos spaghetti.\n<\/p>\n

\n Descuido\/Error
\n<\/h5>\n

\n A veces, los programadores simplemente escriben c\u00f3digos incorrectos, lo que eventualmente genera deudas t\u00e9cnicas. Independientemente de si el c\u00f3digo incorrecto existe como resultado del error del codificador o no, el hecho es que los errores generan deudas t\u00e9cnicas y, debido a que no son escalables, eventualmente tendr\u00e1n que corregirse.\n<\/p>\n

\n Falta de conocimiento de los efectos
\n<\/h5>\n

\n A veces, las deudas t\u00e9cnicas surgen porque el codificador no se da cuenta o no reconoce cu\u00e1n da\u00f1inas son las deudas t\u00e9cnicas a largo plazo. Esto podr\u00eda provenir de una ignorancia leg\u00edtima de los efectos da\u00f1inos de tomar atajos durante la programaci\u00f3n, o podr\u00eda ser una indiferencia deliberada de las consecuencias.\n<\/p>\n

\n Intenci\u00f3n
\n<\/h5>\n

\n Las deudas t\u00e9cnicas pueden surgir intencionalmente por las acciones deliberadas del codificador o la organizaci\u00f3n.\n<\/p>\n

\n Falta de modularidad
\n<\/h5>\n

\n Esto surge principalmente porque un c\u00f3digo puede servir para diferentes l\u00f3gicas comerciales al mismo tiempo. Este tipo de situaci\u00f3n hace que el manejo del software sea mucho m\u00e1s dif\u00edcil. Con cada c\u00f3digo que escribe un desarrollador, hay m\u00e1s posibilidades de que experimenten desaf\u00edos con la modularidad.\n<\/p>\n

\n Evaluaci\u00f3n de Deuda T\u00e9cnica
\n<\/h3>\n

\"\"<\/a><\/p>\n

\n Las deudas t\u00e9cnicas nunca deben calcularse manualmente porque ser\u00eda bastante arduo. Supondr\u00eda tener que introducir manualmente el c\u00f3digo para determinar los problemas actuales y los posibles futuros. Aparte de la p\u00e9rdida de tiempo que supone el proceso manual, existe la posibilidad de que los c\u00f3digos hayan cambiado de forma al final del proceso manual.\n<\/p>\n

\n Una forma de llevar a cabo la evaluaci\u00f3n es mediante la realizaci\u00f3n de un an\u00e1lisis est\u00e1tico utilizando algunas herramientas que lo soporten. Algunas de las herramientas que se pueden usar incluyen Coverity, SonarQube, Check Style y Closure Compiler.\n<\/p>\n

\n Generalmente, existen dos formas de calcular las deudas t\u00e9cnicas. En el primer enfoque, podr\u00eda obtenerse calculando el \u00edndice de deuda t\u00e9cnica seg\u00fan el \u00edndice de c\u00f3digo. En este caso, la estimaci\u00f3n inicial o el tiempo total necesario para desarrollar la aplicaci\u00f3n se utilizar\u00eda para determinar el tiempo necesario para solucionar la deuda t\u00e9cnica.\n<\/p>\n

\n En el segundo enfoque, podr\u00eda utilizar directamente las estimaciones proporcionadas por las diversas herramientas, como SonarQube. Esto se combinar\u00e1 con las listas de las deudas t\u00e9cnicas, as\u00ed como sus c\u00f3digos de referencia. A partir de las herramientas, puede obtener una estimaci\u00f3n precisa del tiempo necesario para solucionarlo.\n<\/p>\n

\n La evaluaci\u00f3n de la deuda t\u00e9cnica le dar\u00e1 una idea de cu\u00e1ntos d\u00edas llevar\u00e1 arreglar la deuda t\u00e9cnica. Cuantas m\u00e1s deudas haya, m\u00e1s tiempo te llevar\u00e1 arreglarla.\n<\/p>\n

\n Resoluci\u00f3n de deudas t\u00e9cnicas
\n<\/h3>\n

\n \u00bfQu\u00e9 sucede si se han producido deudas t\u00e9cnicas y no sabe qu\u00e9 hacer? Hay ciertos pasos que puede seguir para administrar las deudas t\u00e9cnicas.\n<\/p>\n

\n En primer lugar, debe reconocer que las deudas t\u00e9cnicas existen y comunicarlas a su equipo. Al comunicarse, debe tener claro lo que ha sucedido y lo que debe hacerse para corregirlo. Debe asegurarse de comunicar claramente la necesidad de hacerse cargo de la deuda t\u00e9cnica lo antes posible.\n<\/p>\n

\n Despu\u00e9s de informar a su equipo de las deudas t\u00e9cnicas, hay tres enfoques que podr\u00eda tomar. En el primer enfoque, podr\u00eda decidir continuar con el sistema tal como est\u00e1. En este escenario, la aplicaci\u00f3n se utilizar\u00e1 tal cual.\n<\/p>\n

\n Alternativamente, podr\u00eda decidir refactorizar la aplicaci\u00f3n. La refactorizaci\u00f3n se realiza con el objetivo de reducir la complejidad de la aplicaci\u00f3n y limpiar la estructura de la aplicaci\u00f3n. Con la refactorizaci\u00f3n, el comportamiento del software no cambiar\u00e1; la \u00fanica parte afectada ser\u00e1 la estructura interna.\n<\/p>\n

\n Finalmente, si las dos opciones discutidas anteriormente no funcionan, deber\u00e1 reemplazar el c\u00f3digo por completo. Un problema con esto es que podr\u00eda conducir a nuevas deudas t\u00e9cnicas, pero eso podr\u00eda ser una mejor compensaci\u00f3n a largo plazo.\n<\/p>\n

\n Evitar deudas t\u00e9cnicas en el futuro
\n<\/h3>\n

\"\"<\/a><\/p>\n

\n Por supuesto, es una obviedad que evitar las deudas t\u00e9cnicas es definitivamente m\u00e1s inteligente que tratar de arreglarlas cuando surgen. Aparte del hecho de que le ahorra tiempo y estr\u00e9s, tambi\u00e9n asegura que las consecuencias residuales que se derivan de tener deudas t\u00e9cnicas desde el principio est\u00e9n ausentes.\n<\/p>\n

\n Se podr\u00eda argumentar que las deudas t\u00e9cnicas, en s\u00ed mismas, no son malas. Generalmente son problem\u00e1ticos porque son deudas que hay que pagar, y los humanos no son la especie m\u00e1s responsable de la tierra. Elegir constantemente una opci\u00f3n m\u00e1s d\u00e9bil generalmente debilitar\u00e1 la fortaleza de su software y har\u00e1 que sea m\u00e1s dif\u00edcil mejorar las funcionalidades m\u00e1s adelante. En definitiva, evitar las deudas t\u00e9cnicas es la mejor apuesta para cualquiera.\n<\/p>\n

\n Entonces, \u00bfc\u00f3mo evitar que surjan deudas t\u00e9cnicas?\n<\/p>\n

\n Crear una cartera de proyectos\n<\/p>\n

\n La idea aqu\u00ed es mantener a todos al tanto del proceso y ponerlos al d\u00eda con los requisitos para cualquier tarea que se lleve a cabo. La creaci\u00f3n de un backlog permite que todos vean las tareas que quedaron sin hacer y los caminos a seguir para lograrlas.\n<\/p>\n

\n Priorice la calidad sobre la velocidad\n<\/p>\n

\n Si usted mismo es un programador, debe aprender a priorizar la realizaci\u00f3n de un trabajo de calidad sobre mucho trabajo. Aseg\u00farese de que sus c\u00f3digos est\u00e9n limpios y que sus aplicaciones u otro software est\u00e9n desarrollados a la perfecci\u00f3n. Comprenda que la tentaci\u00f3n de tomar atajos no valdr\u00e1 la pena porque eventualmente, a\u00fan tendr\u00e1 que llevar a cabo las tareas que descart\u00f3.\n<\/p>\n

\n Si dirige un equipo, debe comunicar estos mismos valores a los miembros del equipo. Se debe ense\u00f1ar a los miembros a crear soluciones orientadas a los resultados y evitar los atajos.\n<\/p>\n

\n Crear conciencia\n<\/p>\n

\n Generalmente, un conocimiento profundo de qu\u00e9 es la deuda t\u00e9cnica y c\u00f3mo evitarla puede ser \u00fatil para evitar que surjan en primer lugar. Cuando proporcione a sus desarrolladores los conocimientos necesarios, ser\u00e1 mejor que eviten las trampas que plantean las deudas t\u00e9cnicas.\n<\/p>\n

\n Introducir buenas pr\u00e1cticas de codificaci\u00f3n\n<\/p>\n

\n Algunas pr\u00e1cticas de codificaci\u00f3n hacen que sea m\u00e1s probable que caiga en una deuda t\u00e9cnica. Por lo tanto, ser\u00eda genial evitar el acoplamiento estrecho, emplear la abstracci\u00f3n y la refactorizaci\u00f3n.\n<\/p>\n

\n Introducir tecnolog\u00eda actualizada\n<\/p>\n

\n Las actualizaciones peri\u00f3dicas de la tecnolog\u00eda pueden ser un medio excelente para anticiparse a las deudas t\u00e9cnicas. Al actualizar, debe asegurarse de que lo que se est\u00e1 utilizando es el marco, las bases de datos y el software de aplicaci\u00f3n m\u00e1s recientes.\n<\/p>\n

\n Conclusi\u00f3n
\n<\/h5>\n

\n Las deudas t\u00e9cnicas, en la gran mayor\u00eda de los casos, son inevitables mientras contin\u00faes desarrollando programas y escribiendo c\u00f3digos. Sin embargo, las posibilidades de que ocurran pueden reducirse considerablemente si se siguen los pasos enumerados anteriormente. Adem\u00e1s, ante la eventualidad de deudas t\u00e9cnicas, no se pierde toda esperanza. Mant\u00e9n la calma, ten confianza, act\u00faa en consecuencia.\n<\/p>\n<\/p>\n

\n Fuente de grabaci\u00f3n: instantshift.com<\/a>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Si la deuda t\u00e9cnica suena como sacada de un manual de finanzas es porque el t\u00e9rmino est\u00e1 relacionado con las finanzas. Sin embargo, en el sentido real de la misma, la deuda t\u00e9cnica est\u00e1 relacionada con la programaci\u00f3n. Es la idea de que durante el desarrollo de un proyecto de software, se omiten ciertos pasos necesarios, o simplemente se descartan por completo en un intento por cumplir con un plazo. En un intento por desarrollar la aplicaci\u00f3n o el software perfecto, los desarrolladores a menudo tienen poco tiempo, al igual que cualquier persona al azar que realiza cualquier tarea arbitraria de todos modos. Por lo tanto, por lo general tiene sentido tener alg\u00fan tipo de…<\/p>\n","protected":false},"author":1,"featured_media":209172,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_wp_rev_ctl_limit":""},"categories":[216,99,268,60],"tags":[],"class_list":["post-263292","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-codificacion","category-posicionamiento-web-y-marketing","category-psicologia-2-2","category-web-y-wordpress"],"_links":{"self":[{"href":"https:\/\/inform.click\/es\/wp-json\/wp\/v2\/posts\/263292","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/inform.click\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/inform.click\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/inform.click\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/inform.click\/es\/wp-json\/wp\/v2\/comments?post=263292"}],"version-history":[{"count":0,"href":"https:\/\/inform.click\/es\/wp-json\/wp\/v2\/posts\/263292\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/inform.click\/es\/wp-json\/wp\/v2\/media\/209172"}],"wp:attachment":[{"href":"https:\/\/inform.click\/es\/wp-json\/wp\/v2\/media?parent=263292"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/inform.click\/es\/wp-json\/wp\/v2\/categories?post=263292"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/inform.click\/es\/wp-json\/wp\/v2\/tags?post=263292"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}