All posts by Jersson

C√≥digo Muerto ūüíÄ

Una de las an√©cdotas m√°s comunes de un proyecto de software es que siempre hay una clase o una funci√≥n que ser√° recordada por el n√ļmero de l√≠neas que esta tuvo. Estoy seguro de que al menos una vez hemos escuchado:

“No toques esa clase, tiene como 1000 l√≠neas de c√≥digo”

Developer anónimo

Este es un dato particular de acuerdo a los proyectos en los que estuve y conversaciones entre amigos. Lo que es menos com√ļn, es saber cu√°ntas l√≠neas de c√≥digo tiene el proyecto en el que estamos trabajando.

Si en este momento nos hacemos esa pregunta o se la hacemos a otro miembro del equipo, es posible de que no consigan una respuesta concreta. Si bien es cierto no considero necesario ser 100% precisos, he notado que pocas personas se preocupan de esa m√©trica, a menos claro, de que haya alg√ļn costo asociado.

Si no les ha pasado, les comento que casos como este se dan desde hace mucho en proyectos donde se audita c√≥digo. Sin ir muy lejos, Amazon liber√≥ [CodeGuru], un servicio (a√ļn en preview) que analiza el c√≥digo fuente. Como es de esperar, el costo est√° asociado al n√ļmero de l√≠neas y no es el √ļnico producto o servicio que hace este [tipo de trabajos]

Fuente: [Amazon CodeGuru]

¬ŅQu√© es lo que regularmente encontraremos?

He participado en proyectos donde el an√°lisis o auditor√≠a de calidad de software era uno de los objetivos m√°s importantes. Muchas veces el costo de servicios adquiridos ‚Äďu ofrecidos‚Äď estaba relacionado al n√ļmero de l√≠neas de c√≥digo (o LoC por [Lines of Code]).

En cada trabajo era com√ļn confirmar lo encontrado en proyectos anteriores:

  1. Pocas personas conoc√≠an el n√ļmero de LoC o la importancia de este indicador
  1. Una pr√°ctica conocida ‚Äďy en algunos casos, aceptada‚Äď era “agregar c√≥digo de ejemplo, ir cambiando y probando pero guardar la versi√≥n original por si algo se malograba”
  1. Muchas veces se mantenían las carpetas de plantillas y ejemplos de las librerías y componentes de terceros que en algunos casos ya no se utilizaban

Ya en un caso concreto, estuve en un proyecto donde el desarrollo tenía más de un millón de LoC y estaba seguro de que eso no podía ser posible pues las funcionalidades del sistema no reflejaban dicha realidad.

Sabía que estaba frente a un caso de Código Muerto, pero tenía que demostrarlo.

¬ŅQu√© es C√≥digo Muerto?

Sin entrar en detalles (pues es posible que encuentren discrepancias y hasta [una canci√≥n]), el c√≥digo muerto o “Dead Code” es aquel que no aporta valor al negocio.

El código muerto se puede clasificar de la siguiente manera:

  • C√≥digo que no se usa: Muy usual en los proyectos de software, algunas veces no se recuerda su objetivo inicial y por lo general ocurre pues las necesidades van cambiando y el c√≥digo no se depura adecuadamente luego de cada cambio (mucho cuidado con las frases “es que no hay tiempo” o “lo vemos despu√©s”)
  • C√≥digo que se ejecuta pero que no se usa: Aqu√≠ entran los casos como los de variables asignadas o llamadas a funciones cuyo resultado no es utilizado. Esto es nocivo pues adem√°s ser c√≥digo in√ļtil, consume recursos del sistema.

¬ŅC√≥mo identificar C√≥digo Muerto?

Con el paso del tiempo prepar√© una secuencia de an√°lisis que me sirvi√≥ para encontrar casos de c√≥digo muerto bajo la premisa de que si algo se define en el programa, este debe ser utilizado de manera efectiva. La lista puede parecer obvia, pero ya est√° demostrado que en tecnolog√≠a no debemos confiar en las obviedades ūüôā

  • Variables
  • Funciones
  • Clases
  • Comentarios (sean redundantes o c√≥digo que fue comentado para ser utilizado “m√°s adelante”)
  • Elementos de archivos de configuraci√≥n (por ejemplo, secciones comentads o que ya no se utilizan)
  • Archivos de configuraci√≥n
  • Librer√≠as (componentes de terceros)
  • Elementos id√©nticos (funciones, clases archivos, librer√≠as o carpetas distribuidos en ubicaciones distintas)
  • Elementos parecidos (librer√≠as con versiones diferentes, funciones o clases que inicialmente eran una copia de la otra)
  • Carpetas y archivos varios que poco a poco quedan relegados hasta el olvido

Un hecho com√ļn en todos los casos, es que el c√≥digo muerto existe debido al temor a perder c√≥digo o a malograr el sistema construido. Esto tiene relaci√≥n directa con el desconocimiento de que los gestores de versiones permiten volver al pasado si es que se necesita ver algo que ha sido borrado.

Otra consecuencia es que a más código muerto, más complejo será el entendimiento de nuestro sistema, la mantenibilidad será afectada y a su vez generará dependencias con un programador en particular (a veces pueden ser más personas). Recuerden, el código es de todos los miembros del equipo y mientras menos dependencias, mejor.

¬ŅQu√© herramientas debemos usar?

Puede que parezca una broma, pero un elemento muy importante es la inspecci√≥n visual. A pesar de ello, esta debe pasar a segundo plano pues debemos evitar confiar totalmente de los presentimientos o “literalmente” de puntos de vista.

De acuerdo a esta premisa, lo primero que debemos hacer es trabajar con [herramientas de an√°lisis est√°tico] que nos brinden un enfoque acertado de lo que est√° ocurriendo.

A pesar de ello, hasta el momento no he encontrado una herramienta que brinde un indicador de código muerto bajo un enfoque holístico. Es así que utilizo principalmente [SonarQube] como base del trabajo a realizar.

Regresando al caso del millón de LoC, encontré pistas que me ayudaron a confirmar la existencia del temible código muerto.

Si queremos empezar con estas prácticas, algo que nos podría ayudar está incluido en las herramientas del navegador web. Una de las que ha llamado mi atención es la utilizada para analizar la cobertura de los archivos JavaScript y CSS. Esta viene en [Chrome] y no es complicado de usar/entender.

¬ŅQu√© consegu√≠ luego de presentar lo encontrado?

El objetivo de mi trabajo en dicho proyecto, fue preparar un informe sobre lo que se estaba construyendo y sobre eso un plan de trabajo para implementar una nueva arquitectura. No me parec√≠a adecuado llegar con una presentaci√≥n llena de indicadores ni menos se√Īalar responsables (aunque en algunos casos ese ha sido mi trabajo), as√≠ que gracias al apoyo y explicaciones que el equipo dio cuando estaba analizando el c√≥digo, ten√≠a el conocimiento necesario para “limpiarlo”, al menos en casos que parec√≠an obvios o donde ve√≠a que complejidad baja o media.

Como este tipo de trabajos me gustan, no par√© hasta eliminar 95% del c√≥digo del sistema. No esperaba llegar a ese n√ļmero pero m√°s de un mill√≥n l√≠neas era c√≥digo muerto que se pod√≠a limpiar f√°cilmente.

Nada mejor que llegar con un informe que tenga un entregable como ese ūüôā

La buena noticias es que el equipo quedó sorprendido. Cuándo me preguntaron cómo lo hice, les comenté que empecé por las obviedades (y ya saben lo que pienso de ellas :)) creo que eso los animó a seguir limpiando (luego de una segunda limpieza el código no superaba las 30 mil LoC)

¬ŅQu√© es lo que aprend√≠?

  • Es posible que este tipo de trabajos sea incomprendido al principio, pero se consigue mucho ense√Īando con el ejemplo. En dicho proyecto ten√≠a que preparar una arquitectura que aproveche lo que ya estaba construido, pero ante las sospechas de c√≥digo muerto, decid√≠ detenerme un momento y evaluar c√≥mo eliminarlo, primero por mi cuenta y luego con el equipo.
  • Lo que he encontrado en muchos casos, es que hay pocas intenciones de refactorizaci√≥n que a veces no se dan por el uso desmedido de frameworks y herramientas. Lo que creo que se debe hacer es sentar una base medible de lo que est√° sucediendo sin olvidar que lo m√°s se hace en un proyecto de software es la construcci√≥n del mismo. Si es as√≠ ¬Ņpor qu√© no saber c√≥mo va creciendo nuestro c√≥digo?
  • La automatizaci√≥n de pruebas es muy importante pero esta se debe postergar si hay casos obvios de c√≥digo muerto, he comprobado que a veces resulta m√°s r√°pido borrar (sin miedo) que ponermos a programar un caso de prueba.
  • Siempre debemos utilizar un gestor de versiones (personalmente prefiero Git sobre GitHub) y tenerlo enlazado a un motor de automatizaci√≥n (como [Jenkins] o [Azure DevOps], ambos me parecen buenos y Azure DevOps es m√°s sencillo de configurar) que ayude a tener visibilidad de la integraci√≥n continua.
  • El equipo de desarrollo pasa a otro nivel de conocimiento, pues adem√°s de entender la importancia de pr√°cticas de limpieza de c√≥digo muerto se abre una nueva puerta hacia la calidad del producto.
  • Si la confianza y comunicaci√≥n son las adecuadas, este tipo de situaciones se convierten en an√©cdotas del equipo.

¬ŅCu√°l fue mi reflexi√≥n final?

Antes de refactorizar o hacer lo que sea en el sistema, eliminen el Código Muerto, no teman.

Un abrazo,

Fuente imagen cabecera: [Finding Dead Code]

Mi aventura en 42 Silicon Valley

Hace unos meses me animé a postular a [42 Silicon Valley] y creo que tuve suerte para ser aceptado (pues no tuve que dar examen de ingreso) o para conseguir un dormitorio gratis (aquí si tuve que esperar confirmación luego de casi dos meses)

El punto de inicio era participar en [The Piscine], el bootcamp para demostrar luego de un mes que tienes las habilidades necesarias para ingresar [al programa] que adem√°s de ser gratuito, tiene una duraci√≥n de cinco a√Īos.

¬ŅEn qu√© consisti√≥ el bootcamp?

  • Estudiar todos los d√≠as de la semana, la mayor cantidad de horas posibles. Pod√≠as usar el material disponible o buscar en internet el material de estudio requerido para cada d√≠a.
  • Resolver las asignaciones diarias respetando el orden de cada pregunta (es decir, no puedes continuar si no terminas con una pregunta)
  • Respetar reglas de programaci√≥n sobre el uso de librer√≠as (muchas no se pod√≠an usar, te ped√≠an construir tus propias librer√≠as), n√ļmero de l√≠neas (25 l√≠neas por programa), n√ļmero de variables (4 por programa), sentencias (el “for” estaba prohibido) y as√≠…
  • Terminar de programar antes de la hora l√≠mite (11.42 de la noche)
  • Tener en cuenta que cada l√≠nea de c√≥digo escrita deber√≠a ser f√°cil de entender
  • Recibir diariamente 2 evaluaciones aleatorias que se hac√≠an de manera presencial, lo cual te obligaba entre otras cosas a defender tu c√≥digo en ingl√©s (s√≠ o s√≠ ten√≠as que hablar)
  • Realizar diariamente 2 evaluaciones (como dije, s√≠ o s√≠ ten√≠as que hablar)
  • Participar en los trabajos grupales, que si bien es cierto no eran aleatorios, requer√≠an mucha coordinaci√≥n.
  • Participar en los ex√°menes semanales, en los que cada viernes te asignaban una computadora que no ten√≠a acceso a internet ni a herramientas como Visual Studio Code, as√≠ que si no sab√≠as como usar vim o comandos en Linux, estabas muerto ūüôā
  • Tener en cuenta que los tres primeros ex√°menes durar√≠an 4 horas y el √ļltimo ser√≠a de 8 horas
  • Programar en C
  • No hacer trampa, pues si bien es cierto los problemas se pueden conseguir f√°cilmente, si no puedes explicarlos o se descubre que ese no es tu c√≥digo, cosas malas pueden ocurrir (adem√°s de que queda en tu registro y te podr√≠an invitarte a salir del programa)

Pues bien, fueron cuatro semanas en las que además de compartir dormitorio con dos amigos de China y uno de Kazajistán, conocí amigos de Rusia, Francia, Argentina, Brasil, China, Korea y USA. Además, en todo ese tiempo aprendí de todo un poco, inclusive como ahorrar tiempo y dinero pues a pesar de vivir gratis en el campus, necesitabas dinero para comer y allá todo era caro :O

S√≠, hay una bandera de Per√ļ ūüėÄ y como datos anecd√≥ticos, era el √ļnico peruano y la foto muestra a los que quedamos hasta el final pues m√°s del 50% se retir√≥

¬ŅQu√© aprend√≠?

Además de respirar programación, encontré cosas muy interesantes:

  1. Resiliencia: Si hay una palabra para definir a las personas que conocí en el bootcamp, esa es la primera que podría decir. Muchos amigos tenían unas ganas de superación increibles, algunos trabajaban por las tardes o noches. Otros no lograron conseguir dormitorio, así que viajaban una o dos horas (algunos manejando) para llegar diariamente al campus. Todo por estudiar.
  1. Colaboración: Si bien es cierto encontré casos de segregación de acuerdo al país de origen o similitud de conocimientos, cuando había problemas nadie dudaba en ayudar si te acercabas a preguntar. Algunos lo hacían con muchas más ganas que otros, pero todos terminaban respondiendo al pedido de ayuda.
  1. Empatía: Algunas veces mi evaluador no sabía como decirme que me había equivocado pues le daba pena que eso afectara a mi promedio. Esto lo supe pues me puse a conversar con ellos pidiendo más detalle ya que al igual que todos, quería aprender.
  1. Humildad: Algunas personas sabían lo suficiente como para terminar el trabajo en la mitad del tiempo o menos, pero a pesar de ello ni alardeaban, ni lo demostraban cuando te tocaba evaluar su código o cuando ellos evaluaban el tuyo. Me pasó más de una vez que hubo personas que me para preguntaban como había resuelto un problema y a veces descubrían un error en su lógica o algo por mejorar en ella. Nunca se molestaban, siempre agradecían.
  1. Optimismo: Una frase con la que siempre me encontraba cuando comet√≠a un error era “no te preocupes, es solo un test, ma√Īana lo haremos mejor” Lo genial es que a veces ocurr√≠a con personas que acababa de conocer.
  1. Competencia sana: Si bien es cierto todos sab√≠amos que cada examen semanal era determinante para ser aceptado en el programa oficial y que no todos ser√≠amos aceptados, todos nos anim√°bamos antes de empezar cada evaluaci√≥n. Al finalizar nos pregunt√°bamos comos fue y hubo casos en los que compar√°bamos soluciones. En mi caso prefer√≠a ir a dormir ‚Äďpues terminaba muy cansado‚Äď pero al d√≠a siguiente la conversaci√≥n segu√≠a ūüôā
  1. Comunicaci√≥n: Si me preguntan cu√°l es diferenciador con respecto a lo que he visto en el medio local (es decir, Per√ļ), este es un elemento muy importante. Teniendo en cuenta de que los programadores no hablamos mucho, eso tambi√©n ocurre fuera del pa√≠s, pero la diferencia es que estando all√°, me encontr√© con personas que adem√°s de escribir buen c√≥digo, explicaban muy bien lo que hac√≠an o en todo caso, sab√≠an vender muy bien sus ideas. Cosa que humildemente tenemos que seguir mejorando.

¬ŅQu√© pas√≥ despu√©s?

Como mencion√© anteriormente, el examen final fue un viernes y ten√≠a una duraci√≥n de 8 horas, en mi caso termin√© de programar en la s√©ptima hora. No recuerdo el n√ļmero de problemas que resolv√≠ pero s√≠ que hab√≠a programado sin descanso alguno, as√≠ que cuando sent√≠ que necesitaba salir de ah√≠, fue lo que hice. La verdad es que, cuando tu cabeza no da para m√°s, lo mejor es dejar de programar.

A las dos semanas de dar el examen estaba de viaje y con poco acceso a internet, recuerdo que cuando pude conectarme, recib√≠ con mucha sorpresa el correo de aceptaci√≥n al programa, pod√≠a irme a estudiar por tres a√Īos y si no ten√≠a donde vivir, pod√≠a postular nuevamente para conseguir un dormitorio.

¬ŅQu√© es lo que har√©?

En esta √©poca de mi vida me gustar√≠a volver a ense√Īar, mientras tanto estoy retomando mi pr√°ctica de escribir y reforzar mis conocimientos en [arquitectura] (es por eso que mi blog ha renacido), adem√°s estoy presentando una tesis para conseguir mi maestr√≠a en administraci√≥n y en paralelo a esto, me puse a estudiar mi segunda maestr√≠a mientras busco un nuevo empleo.

Creo que estoy algo ocupado por el momento (o quiz√° algo loco), pero bueno, nunca se sabe ūüôā

Un abrazo,

Microservicios y código de ejemplo

Estaba preparando una propuesta de charla de [microservicios] y mientras buscaba informaci√≥n para el c√≥digo de ejemplo, me di con la sorpresa de que lo que encontraba en la web era de complejidad media/alta (o no se entend√≠a) o peor a√ļn, a pesar de que muchos (podr√≠a afirmar que m√°s del 50%) indicaban que se trataban de microservicios, pues no lo eran.

Fuente: [microservices]

¬ŅC√≥mo confirmas si est√°s viendo un microservicio?

Siendo concretos, un microservicio debe:

  1. Responder a un solo trabajo, es decir, una sola funcionalidad
  2. Ser autónomo incluso en su instalación

Okey, hay [otras consideraciones] a tomar en cuenta, pero a mi entender si no pasamos los dos primeros filtros, no tiene sentido seguir avanzando.

¬ŅQu√© hice al respecto?

Sin ir en muchos detalles, se me ocurrió detener lo que estaba haciendo para ponerme a escribir códigos de ejemplo de microservicios.

Ojo, no me considero un experto pero creo que mi idea es sencilla, crear un proyecto para compartir lo que voy aprendiendo.

¬ŅEn qu√© consiste el proyecto?

El requitisto principal es que el código sea fácil de entender y que además permita aprender a construir microservicios. Es así que lo que tengo en mente hasta ahora es:

  • Una plantilla de c√≥digo (incluye soporte de HTTP GET)
  • C√≥digo de ejemplos para:
    1. Soporte de HTTP GET
    2. Soporte de HTTP GET y par√°metros
    3. Soporte de HTTP POST y par√°metros
    4. Soporte de HTTP GET y Docker para desplegar el microservicio

Inicialmente pens√© en escribir todo en NodeJS pero luego dije ¬ŅPor qu√© no m√°s lenguajes?

¬ŅQu√© he avanzado hasta ahora?

Pues como dije l√≠neas arriba, me anim√© a escribir algo de c√≥digo ūüôā El proyecto se llama microservices-templates y ya est√° en GitHub, aqu√≠ la url: https://github.com/jersson/microservices-templates

Si bien es cierto tengo en mente programar en al menos cinco lenguajes, decidí que no podía esperar tanto para liberar algo, así que aquí va la versión en NodeJS: https://github.com/jersson/microservices-templates/tree/master/00-node

Como podrán notar en el código, este incluye descripciones sobre como probar cada microservicio. Además, cada archivo tiene pocas líneas de código y cada una de ellas la he escrito de manera que busqué facilitar su lectura.

Este proyecto me gusta bastante y estoy seguro de que si consigo ayuda podr√© avanzar m√°s r√°pido, as√≠ que si les interesa aprender o ya saben como escribir o mejorar lo que estoy construyendo, an√≠mense, estar√© aqu√≠ o en GitHub ūüôā

Sin m√°s que decirles me despido esperando que tengan un excelente nuevo a√Īo.

Un abrazo.

Fuente imagen cabecera:[what are microservices?]

¬ŅC√≥mo practicas programaci√≥n?

Les cuento que casi todo este a√Īo tuve el tiempo necesario para programar al menos dos horas al d√≠a. En t√©rminos simples, programar es uno de los hobbies que he ido desarrollando a lo largo de mi vida ūüôā

En fin, como algunos saben, hace unos meses estuve en el bootcamp de [42 Silicon Valley] y si bien es cierto no he tenido la oportunidad de escribir al respecto, puedo adelantar que mi afición por la programación se reforzó de tal manera que ahora veo de forma diferente cualquier lenguaje de programación, estudio mucho más al respecto y si fuera necesario, reviso cómo hacer las cosas con la menor cantidad de librerías y/o frameworks (pues ahora casi todo se resuelve así)

Bueno, para hacer la historia corta, mi inter√©s ‚Äďy cari√Īo‚Äď por el [lenguaje C] ha vuelto, as√≠ que he propuesto cuatro problemas que parecen simples, pero si intentas resolverlos con la menor cantidad de c√≥digo, librer√≠as y adem√°s buscas hacerlo entendible, pues ah√≠ llega la complejidad. De estos problemas ya he resuelto dos y los he dejado en un repositorio esperando que alguien quiera unirse para al menos proponer nuevos problemas. Por mi parte ya tengo algunos en mente, pero tengo que ponerlos en limpio.

En fin, si les interesa este es el repositorio que siempre voy actualizando: https://github.com/jersson/c-problems/tree/dev

Ahora, si quieren ver cómo funciona el código y no quieren clonarlo, aquí un espacio para jugar usando el navegador https://repl.it/@jersson1/c-problems. De ser así, tengan especial atención en el archivo .replit

Como ya deben haber notado, la documentaci√≥n la estoy escribiendo en ingl√©s pues adem√°s me pareci√≥ buena oportunidad para practicar el idioma ūüôā

Espero que puedan unirse y que adem√°s pasen unas excelentes fiestas navide√Īas.

Un abrazo,

Fuente imagen cabecera: http://offeman.com/safe-casting-pointers-in-object-pascal/

¬ŅQu√© tanto le debes a tu sistema?

En términos simples, la deuda técnica tiene que ver con el tiempo que tendrías que invertir para solucionar problemas que estás dejando de lado a nombre de generar un resultado en el menor tiempo posible.

S√≠, con esto me refiero a las consecuencias del “d√©jalo ah√≠, luego lo arreglamos”

Lo que me he encontrado es que esa es una frase que es aceptada hasta que los problemas se empiezan a poner serios. Por otro lado, hay que considerar que si queremos mejorar “algo”, pues tenemos que saber c√≥mo medir ese “algo” antes y despu√©s de los cambios realizados.

¬ŅC√≥mo mido un sistema?

Estoy seguro de que hay muchas formas para eso, pero aquí los pasos que sigo regularmente:

  1. Perspectiva del usuario final
  2. Comportamiento en tiempo real (análisis dinámico de código)
  3. Perspectiva del desarrollador (análisis estático de código)

1. Perspectiva del usuario final

Asumiendo de que el usuario está contento con las funcionalidades existentes y de que no hay errores en producción (Sí, es un gran supuesto), lo que normalmente sugiero es tomar nota del comportamiento de la aplicación.

¬ŅQu√© se hace ah√≠? Pues se mide lo que llega al usuario ¬ŅC√≥mo medimos la aplicaci√≥n? Para nuestra suerte, si estamos trabajando con una aplicaci√≥n web, existen herramientas gratuitas que nos permiten tener reportes como el que nos genera [GTmetrix]

Fuente: [An√°lisis del blog personal]

Parece obvio, pero les cuento que he estado en proyectos en los que no se hab√≠a considerado una revisi√≥n bajo esa perspectiva y ya se ten√≠an quejas de que “el sistema estaba lento”

Lo bueno de herramientas como GTmetrix, es que brindan una mirada objetiva de lo que le entregas al consumidor final. Aqu√≠ es donde encontrar√°s aspectos como el tiempo de carga de la p√°gina (Fully Loaded Time) o incluso el tama√Īo de lo que se descarga al navegador (Total Page Size)

Por otro lado, GTmetrix incluye una serie de an√°lisis usando herramientas como [PageSpeed] o [YSlow]. Para ambos casos se genera un score que puede mejorarse si sigues las recomendaciones que, para tener una idea, se crearon bajo est√°ndares de Google (para el caso de PageSpeed) o Yahoo! (para el caso de YSlow)

Otra opci√≥n interesante viene con Google Chrome y se puede usar desde la opci√≥n Developer Tools/Audits, lo cual, en resumen, hace uso de [Lighthouse], que tambi√©n es usado por Google PageSpeed ūüôā

Fuente: Archivo personal

Los que me conocen saben del cari√Īo que le tengo a YSlow y que me apena que ya no haya una extensi√≥n de navegador para hacer un an√°lisis a ese nivel de detalle. Tiempos aquellos ūüôā

Update: Si pueden denle una oportunidad a https://yellowlab.tools/ Se ve muy interesante!

2. Comportamiento en tiempo real (an√°lisis din√°mico)

Una vía rápida para reaccionar a lo que le ocurre al sistema, es saber lo que le pasa a este mientras va funcionando. No soy partidario de esta forma de trabajo, pero en sistemas que ya se están ejecutando en producción es importante contar con al menos una herramienta que permita tener una vista de ese tipo.

Aquí es donde hablamos del análisis dinámico del código con herramientas del tipo APM (Application Performance Monitor). Una que hace muy bien ese trabajo es [New Relic]

Fuente: [New Relic]

La importancia de este tipo de herramientas radica que no son invasivas. Es decir, no tienes que tocar tu código y la performance de la aplicación no se ve afectada. Antes de New Relic probé otros analizadores que degradaban la aplicación al punto que decidíamos desactivar el analizador.

3. Perspectiva del desarrollador (an√°lisis est√°tico)

Tal como mencioné en la sección anterior, no soy partidario de ir reaccionando acorde a lo que le ocurra al sistema pues creo firmemente que la mejor forma de solucionar un problema es evitándolo.

Bajo esa premisa estamos en la obligación de encontrar mecanismos que permitan controlar lo que se está construyendo o modificando. Aquí es donde entran herramientas como [SonarQube]

Fuente: Archivo personal

Lo bueno de esta herramienta (entre muchas cosas) es que te ayuda a clasificar los posibles problemas de programación y te da una estimación base de lo que necesitarías para cubrir esa deuda técnica.

¬ŅQu√© ocurre normalmente?

Lo que he encontrado en algunos proyectos es:

  1. No se mide lo que se est√° construyendo
  2. Se mide lo que se construye pero en términos de deuda técnica convencional (análisis estático con SonarQube)

No pondré en duda si se toma acción sobre la deuda técnica pero lo que regularmete encuentro es que se pierde la perspectiva de lo que ocurre en producción o se hace a consecuencia de un problema.

¬ŅQu√© estamos perdiendo?

No soy un experto en el tema pero les puedo asegurar que poco a poco iremos perdiendo el control de nuestra aplicación analizada. No he encontrado un estudio detallado del impacto financiero al respecto, pero valgan verdades hay situaciones en las que el equipo de desarrollo sugerirá rehacer un componente/servicio/módulo/aplicación a consecuencia de que lo encontrado es inmantenible.

¬ŅSe imaginan eso en t√©rminos financieros? Pues ah√≠ un primer vistazo al dinero perdido a consecuencia de una deuda t√©cnica mal gestionada.

¬ŅQu√© tenemos que hacer?

La primera respuesta es obvia, “tenemos que medir nuestra aplicaci√≥n” pero en realidad, adem√°s de invertir para lograrlo, hay mucho por hacer al respecto pues lamentablemente no he encontrado una herramienta que nos muestre lo que es realmente la deuda t√©cnica. Si bien es cierto SonarQube nos da una idea al respecto, pero no podemos confiar en ese √ļnico indicador (Resumen, SonarQube te ayuda pero no es la soluci√≥n definitiva ‚ėĻÔłŹ)

La segunda respuesta tiene que ver con lo que algunos llamamos el dise√Īo y ejecuci√≥n de nuestro plan de pagos. Es decir ¬Ņc√≥mo vamos a ir pagando nuestra deuda t√©cnica?

Es aqu√≠ donde tenermos una [gran responsabilidad], pues adem√°s de englobar esta serie de issues/riesgos/problemas/bugs tenemos que darle forma al indicador y a su impacto t√©cnico/financiero. Por otro lado, debemos aceptar que siempre estar√° ah√≠ pues estoy seguro de que no hay proyecto que elimine la deuda por completo. Es decir, siempre habr√°n issues con los que tendremos que convivir, pero si es as√≠, tiene que ser una convivencia sana ūüôā

Un abrazo,