¿Estamos jugando Jenga con nuestros sistemas?

Si trabajamos en el mundo de la tecnología, ya nos debe haber pasado –o escuchado– de que el sistema se cayó por un cambio mal realizado. A veces nos pasa que mientras arreglamos una cosa malogramos otras. Mucho cuidado con los círculos viciosos.

Estas situaciones me recuerdan las veces que juego [Jenga] con mis amigos. Y es que, de empezar con una mala estrategia, llegado un punto, cada turno se vuelve emocionante pues nadie quiere tumbar la torre de madera.

Fuente: [Wikimedia]

Si en los proyectos de tecnología empezamos sin una estrategia técnica adecuada, muchas veces tendremos dolores de cabeza en el futuro. Sin ir muy lejos, muchas decisiones técnicas son pasadas por alto a consecuencia de “ahorrar”, “lo arreglamos después”, “las cosas siempre fueron así” o la necesidad de solucionar problemas rápidamente sin entender por completo las implicancias del mismo o incluso sin entender la solución.

Sinceramente creo que pasar por este tipo de situaciones nos hacen crecer profesionalmente. Sin ir muy lejos, con el paso del tiempo he descubierto que ya no me gustan algunas soluciones que hice en proyectos anteriores, la idea es ir descubriendo nuevas formas y cuestionar nuestro trabajo. Creo que deberíamos ser los primeros en hacerlo.

Regresando a la analogía, les cuento que conversando con muchos amigos o con las personas que me entrevistaban mientras buscaba trabajo, he confirmado mi teoría; todos hemos tenido una torre de Jenga que se ha derrumbado al menos una vez en nuestros sistemas. A veces nos reímos de eso y otras nos avergüenza, pero lo más importante es que hemos tenido la capacidad de aprender y jugar sabiamente.

¿Qué síntomas tienen los sistemas Jenga?

  1. Los pases a producción tienen correcciones de última hora. O bueno, las correcciones del día siguiente.
  1. Es común hacer rollback pues las correcciones tardarán demasiado.
  1. Es común escuchar el [por favor, no toques ese código]
  1. Hay una persona que puede resolver los problemas “difíciles” y algunas veces ese es su trabajo principal. En algunos casos su rol o título es “el especialista”
  1. La gestión de versiones es pobre o nula.
  1. Los pases a producción se ejecutan manualmente.
  1. Las pruebas se hacen “a mano”
  1. La documentación no está actualizada o bueno, no existe.

Tal como dije al empezar con este post, puede que nos hayan pasado estas cosas y no hay problema con ello. Lo que sí creo es que sería irresponsable no hacer algo al respecto para que esto no nos vuelva a ocurrir.

¿Qué es lo que podemos hacer?

Puede que este sea –o suene– un trabajo complicado pero no es imposible. Los factores de éxito más importante tienen que ver con la determinación para resolver los problemas y el tiempo necesario para empezar con este tipo de trabajos.

A pesar de ello, he dividido esta estrategia en tres etapas.

#1: Orden

  1. Si no cuentan con una gestión de versiones adecuada o no han explorado ese camino, pues Git sobre GitHub es un excelente punto de partida. No se compliquen la vida pensando en qué archivos agregar al gestor de versiones, la depuración será parte del trabajo a realizar. Si no están familiarizados, aquí algunas referencias a tener en cuenta:
  1. Identifiquen el código innecesario, para no perder mucho tiempo en este paso, tienen que trabajar con herramientas como [SonarQube]. En mi publicación de [código muerto] encontrarán más detalle al respecto.
  1. Limpien su código fuente aprovechando la información encontrada en el paso anterior. Como mencioné en [código muerto], un buen calentamiento es comenzar por esas carpetas y archivos que nadie usa. Descubrirán que es un trabajo divertido y que en el tiempo resulta motivador ver cómo el código se va limpiando de a pocos y claro, los indicadores de SonarQube van reflejando el resultado de nuestro esfuerzo.
  1. Busquen que los especialistas en resolver problemas sean los primeros candidatos a ser referentes técnicos. Estoy seguro de que encontrarán de que hay experiencia que no está correctamente enfocada. Los especialistas podrán ayudar a identificar y/o eliminar esos elementos muertos y mejor aún, cumplir con labores más interesantes.
    • Ojo que esta actividad también nos servirá para confirmar si nuestros especialistas están preparados para dar el próximo paso o quizá es que no están interesados en hacerlo.
  1. Hablemos de automatizando. Un paso muy importante es engranar el desarrollo con un servidor de automatización y uno de los más populares es [Jenkins]. Lo mínimo necesario es implementar un flujo de [Integración Continua] y si todo marcha bien, ir pensando en la [Entrega Continua]. No se apuren en cumplir todas las recomendaciones que puedan encontrar en la web, con el paso de cada de actividad descubrirán qué paso agregar u omitir en el flujo de automatización.
  1. Identifiquen el código de las funcionalidades más importantes para el negocio. Aquí es donde los referentes técnicos nos darán una mano o en el peor de los casos, confirmarán que alguno de ellos solo se había orientado a resolver problema sin entender las causas o impacto en el negocio. Si esto ocurre no se preocupen, siempre habrán cosas por mejorar pero dependeremos mucho de la actitud de los involucrados.
  1. Automaticen sus pruebas. Es posible que hayan escuchado que es un trabajo interminable o que pone en riesgo las fechas comprometidas pero hay que sincerar las cosas, en un primer intento no podremos automatizar todo. Aquí es donde veremos la importancia de haber identificado las funcionalidades más importantes. La primera versión de esta automatización no tiene que ser perfecta pero debe existir alguna forma sencilla de validar las más importantes. Lo más importante radica en que el equipo decida el número mínimo de pruebas a automatizar. Aquí dos consideraciones a tener en cuenta:
    • Si no tienen el tiempo necesario, pueden empezar con [pruebas unitarias], cuya tecnología dependerá del stack tecnológico con el que cuenten.
    • Si quieren dar un paso más adelante y están trabajando sobre una plataforma web o servicios REST, pueden realizar pruebas usando [cypress]
  1. Refactoricen, sigan limpiando, midan el avance. Herramientas como [SonarQube] o [New Relic] les darán una serie de pistas que los ayudarán a seguir limpiando el código. No tienen que seguir todas las recomendaciones, la idea es ir mejorando la calidad del código mientras van construyendo nuevas funcionalidades, siempre recordando que las pruebas automatizadas nos indicarán si estamos rompiendo algo que ya funcionaba.

#2: Equipo

  1. Busquen alinear los conocimientos del equipo. Si bien es cierto este es un ideal, lo mínimo esperado es que los especialistas compartan lo necesario para ir cortando dependencias. Lo que necesitamos es tener más jugadores de equipo y de paso confirmar si los especialistas se pueden afirmar como referentes técnicos (una forma de hacerlo es creando espacios donde puedan compartir lo que saben)
  1. Promuevan más reuniones técnicas. La temática puede estar relacionada a un problema, una solución, una técnica de programación, un sistema o una tecnología en particular. Consideren que también podrían invitar a personas de otros equipos o empresas (para compartir algún tema como los mencionados)
  1. Promuevan la capacitación del equipo. Ser autodidactas es bueno, pero si está a nuestro alcance gestionar o solicitar ese capacitaciones para el equipo, es nuestra responsabilidad hacerlo. Estas sesiones deben considerar aspectos prácticos. Para ser claros, toda teoría debe complementarse con un ejemplo que empuje al equipo a escribir código. Aquí unos tópicos que sugiero regularmente:
    • Programación orientada a objetos
    • Algoritmos de búsqueda
    • Teoría de complejidad
    • Pruebas unitarias
    • Refactorización
    • Test Driven Development
    • Automatización de pruebas
    • Servidores o servicios de automatización
  1. Evalúen. Esto se debe realizar de manera continua mientras se vaya realizando la capacitación y debe confirmarse con una evaluación final, la cual debe ser con computadora en mano. Con esto confirmarán si el objetivo de la capacitación se ha cumplido.
  1. Definan con el equipo las nuevas reglas del juego. El equipo seguirá desarrollando las funcionalidades requeridas por el negocio pero en adelante debería haber apertura para:
    • Refactorizar el código existente sin romper las pruebas unitarias ya construidas
    • Implementar nuevas pruebas unitarias, además de la relacionada a la nueva funcionalidad a construir
    • Eliminar código muerto
    • Gestionar la deuda técnica sin ser perfeccionistas

#3: Visión

Hay que tener en cuenta de que estamos trabajando sobre la practica de ir mejorando lo existente mientras seguimos atendiendo la misión del negocio. Esto es lo que ocurre normalmente, no debemos olvidar la visión del negocio y que además esta nos sirve como referencia principal de nuestra visión tecnológica. Lo que he encontrado en algunas situaciones es que también hay mucho trabajo por realizar, aquí algunas consideraciones:

  1. ¿Tenemos un diagrama de situación actual? No se preocupen, lo normal es que ese diagrama no exista. La buena noticia dependerá de qué tan bien hayamos seguido la práctica de realizar reuniones técnicas. Si la respuesta es positiva, lo que debe hacer el equipo es dibujar el primer diagrama AS-IS de los sistemas de la empresa. Estas sesiones también servirán para crear una lista de aquellas cosas por refactorizar/mejorar, la cual debe estar relacionada con cada elemento identificado en el diagrama.
  1. Es momento de definir nuestros compromisos técnicos. Lo normal es tener objetivos técnicos (p.e. reducir los errores en 25%) mientras que los compromisos muchas veces se omiten o se consideran implícitos. Lo mejor es aclarar en conjunto aquellos compromisos que en adelante se respetarán por la salud técnica de nuestros sistemas. Aquí una propuesta:
    • Funcional: Fácil de usar (perspectiva del usuario)
    • Flexible: Fácil de entender y modificar (perspectiva del desarrollador)
    • Extensible: Fácil de conectar con otros sistemas (perspectiva del desarrollador y del sistema)
    • Automatizable: Lo necesario para poder compilar, probar, desplegar y diagnosticar fácilmente.
  1. ¿A dónde queremos llegar? El objetivo de esta actividad es obtener un diagrama TO-BE teniendo en cuenta lo siguiente:
    • Podemos soñar
    • Debemos considerar que tenemos al menos dos inputs técnicos, el diagrama AS-IS y la lista de cosas por refactorizar/mejorar
    • Un input adicional –y que no es técnico– es la visión del negocio ¿qué es lo que se está buscando en 3, 5, 10 años? Mientras más información tengamos, mucho mejor
    • ¿Podemos soñar? Claro que sí pero tampoco creamos que de un día a otro conseguiremos arquitecturas como las que promueven Amazon, Netflix, Uber o tantas grandes empresas.
    • Debemos considerar que en el tiempo nuestra torre se debe transformar en una fortaleza. Lo ideal es derrumbar todo y empezar de nuevo pero eso sí sería soñar en grande.
  1. Seamos realistas. No me malinterpreten, lo que quiero decir es que debemos hacer una comparación entre lo que tenemos y lo que buscamos y sobre eso hagamos un plan que busque eliminar ese gap poco a poco.
    • Tengamos en cuenta de que cada paso se debe convertir en al menos una meta a cumplir y que cada meta debe ser fácil de medir en un tiempo determinado.
    • Por otro lado si es que no tenemos opción a reemplazar todo un sistema. Lo que podemos hacer es hacer el reemplazo de aquellos componentes que a veces vale la pena reemplazar por un nuevo desarrollo o por algo que podríamos comprar y modificar. Si esto se puede hacer para varios elementos de un sistema, es un proceso que le he llamado “reemplazo silencioso del sistema”
    • La deuda siempre existirá y sigamos trabajando con eso. No tenemos que ser perfeccionistas, [la regla del 80-20] siempre ayuda.

Comentarios finales

Lo que he encontrado en algunos equipos es que con el paso del tiempo nos volvemos jugadores expertos de Jenga y la verdad es que eso es algo que no deberíamos buscar. No es saludable.

Lo que también he encontrado es que una definición incorrecta del trabajo a realizar –para atacar la torre de Jenga– hará que no se encuentre o vea el valor de lo que estamos buscando. Parte de esto lo menciono en [la importancia de la arquitectura de un sistema]

Algo muy importante –y obvio para algunos– es que necesitarán más jugadores de equipo y menos jugadores de Jenga.

Un abrazo,

El futuro que le debemos a Alan Kay

Cuando [Alan Kay] fue a la entrevista de trabajo en [Xerox PARC], una de las preguntas tenía que ver con sus sueños ¿cuál crees que será tu mayor logro? le preguntaron. “Una computadora personal”, respondió.

Como parecía que no le entendían lo qué estaba hablando, cogió una cartera del tamaño de un cuaderno, la abrió y dijo: “Esto será una pantalla plana. Aquí abajo habrá un teclado, y tendrá la potencia suficiente para almacenar correo, archivos, música, imágenes y libros. No pesará más de un kilogramo. De eso estoy hablando”.

El entrevistador se rascó la cabeza, murmuró: “Sí, claro” y lo contrató. Era el año de 1970.

Esa historia la descubrí mientras leía [Los Innovadores] de [Walter Isaacson]. Había escuchado un poco de Alan Kay, pero no tenía idea del genio que me estaba perdiendo.

No quiero entrar en más detalles pues este sería un post interminable. Me queda agregar que este pionero de la computación ha hecho más de lo que conocemos y posiblemente estemos usando algo que haya sido uno de sus sueños (sin ir muy lejos, la programación orientada a objetos, la interfaz de usuario y claro ¡las tablets!). Los dejo con un video que resume rápidamente los aportes del gran –y quizá único– Alan Kay.

Un abrazo (y gracias, Alan)

Fuente cabecera: [Extracts from Alan Kay’s AMA on Hacker News]

¿Cómo construir un microservicio?

Para escribir esta publicación decidí revisar mis anotaciones, experiencias, leer algunas referencias e incluso volver a leer algún libro que me permitiera confirmar –o reforzar– mis puntos de vista al respecto. La finalidad es compartir algo distinto y que además sea fácil de entender. Espero cumplir con ese objetivo 🙂

¿Qué no es un microservicio?

  1. Un servicio pequeño: Esta confusión se genera al creer que el tamaño tiene que ver con el número de líneas de código del programa a exponer como microservicio. No hay que confundir tamaño con nivel de [granularidad]
  1. Un API: Las [Application Program Interfaces] son una puerta para consumir o comunicarnos con un microservicio expuesto. Existe una dependencia muy marcada entre ambos elementos, pero un [API] no necesariamente involucrará el uso de microservicios.
  1. La evolución de SOA: A veces se habla de migrar arquitecturas a “algo nuevo”, cuando en realidad lo que se debe buscar es la convivencia de las mismas. Si no les ha ocurrido, encontrarán situaciones en las que será más barato (y efectivo) implementar un servicio en vez de un microservicio.

¿Cómo describiría un microservicio?

  1. Una necesidad específica de negocio: Una componentización adecuada sugiere que las funcionalidades se agrupen por [afinidad de objetivos en el negocio]. Posterior a esto, debemos dar un paso adicional y subdividir dicho componente en funcionalidades particulares que podrían generar valor al negocio. Un ejemplo aquí sería, aislar la funcionalidad de obtención de ranking financiero de un usuario, del resto de funcionalidades –o cálculos o servicios– financieros.
  1. Independiente: No se debería involucrar a otro microservicio para cumplir el objetivo del microservicio diseñado inicialmente. De acuerdo al ejemplo anterior, la obtención del ranking financiero tendría que ser resuelta de manera efectiva sin apoyo de otros elementos.
  1. Autónomo: Un microservicio debe utilizar sus propios recursos, esto implica fuentes de información e incluso el espacio donde será instalado fisicamente. Esto algunas veces no se cumple a nivel de datos y ya hace un tiempo se habla de [servicios stateless]

En términos sencillos, un microservicio es un programa que responde a una sola necesidad de negocio y que además puede instalarse y ejecutarse sin depender de la existencia de otros microservicios.

¿Qué tengo que hacer si quiero construir un microservicio?

Lo que normalmente hacemos es [buscar en la web]. Allí encontraremos muchas plantillas que, en algunos casos, brindan erroneamente el concepto de microservicio. Esto principalmente porque reflejan servicios que exponen (y soportan) más de una funcionalidad.

Creo que un diseño adecuado se puede conseguir si respetamos los principios propuestos por [Sam Newman], autor de [Building Microservices], el cual por cierto es un excelente libro. Aquí un gráfico que la propuesta y claro, un enlace a [un video] donde se explican cada uno de los principios.

¿Cómo construyo un microservicio?

Hay que tener en cuenta que lo ideal es respetar principios de diseño (en mi caso me pareció que Sam Newman lo explicaba de manera más sencilla). Ahora, si estan aprendiendo o experimentando, podrían seguir las consideraciones que definí mientras iba aprendiendo (las cuales respetan de alguna forma la propuesta del buen Sam)

  1. Requisitos de negocio: Creo que independiente a la estrategia de arquitectura, lo primero que debemos respetar es la funcionalidad a cubrir. Si esta no está cubriendo las expectativas del negocio (lo cual en algunas situaciones se relaciona con el core del negocio), no tiene sentido continuar con el diseño.
  1. Exposición: Otro elemento importante es responder ¿cómo vamos a exponer el microservicio? Aquí entrará a tallar la API que complementará el diseño que estamos realizando.
  1. Requisitos técnicos: Si se tienen cubiertos las dos primeros consideraciones, se puede continuar con el diseño de otras necesidades, como por ejemplo ¿cómo vamos a probar el microservicio? ¿cómo vamos a desplegarlo? ¿cómo vamos a manejar los errores? Aquí es donde entra la sección de herramientas complementarias.

Un diseño que estoy construyendo es el siguiente:

Como mencioné en una [publicación anterior], hace poco empecé un proyecto open source en el cual comparto plantillas y ejemplos de microservicios. Todo el [código fuente] que verán en dicho repositorio responde a las consideraciones de diseño que comento en esta publicación.

Hay que recordar que este diseño responde a un microservicio como unidad de trabajo. Esta acotación es importante pues queda pendiente conversar sobre la interacción con otros elementos del ecosistema. Aquí es donde se entiende que se necesitará estudiar conceptos de [orquestación y coreografía]

¿Cuáles son los próximos pasos?

No debemos olvidar que los microservicios son una técnica más dentro de las posibilidades para atender las necesidades del negocio. Esto significa de que no necesariamente serán la primera –ni la única– respuesta a los problemas a cubrir.

Habiendo dicho esto, sugiero que descarguen el [código de ejemplo] (en este momento está disponible en JavaScript, TypeScript y c#), revisar el contenido, contribuir en GitHub o bueno, darme feedback al respecto.

Quedo atento, un abrazo.

Fuente cabecera: [what are microservices?]

Book Review: Enero 2020

Uno de los objetivos que me tracé este año, involucra leer y publicar al respecto. Para ello estoy respetando un ejercicio de lectura diaria. Mi sugerencia es que encuentres un momento para leer, si puedes hacerlo diariamente pues genial. Sino, puedes empezar dejando uno o dos días. Con que empieces con diez minutos al día estás haciendo un gran avance 🙂

Con respecto a este mes, pude leer cuatro libros y aquí mis comentarios:

Capitanes

Este libro de Sam Walker (2017) es muy interesante pues hace un estudio que busca identificar el factor clave de un equipo deportivo. Luego de un análisis detallado encuentra que los capitanes de equipo juegan un papel importante. A partir de esto encuentra comportamientos comunes entre muchos de estos capitanes. La lectura es fácil de seguir y muy amena si estás familiarizado con los deportes o bueno, los métodos de análisis utilizados (que por cierto, no es necesario conocerlos)

Little Red Book of Selling

Jeffery Gitomer (2005) explica en términos simples los pasos a seguir si te interesa vender o sumergirte en el mundo de las ventas. Lo interesante es que tal como el autor indica, no es necesario trabajar como vendedor, lo importante es ver como realizar estas prácticas en tu vida diaria pues lo que debemos hacer siempre es mejorar nuestra marca personal. Un dato adicional sobre el libro, es que la lectura y los ejemplos son digeribles gracias a los gráficos y frases que nos acompañan en este viaje.

Mario

Carlos Freyre (2019) nos presenta un formato gráfico que nos ayuda a conocer más del escritor peruano ganador del Premio Novel de Literatura. Esta suerte de biografía incluye pasajes de la vida del novelista y elementos que han influido en los escritos que nos ha presentado hasta la actualidad. Una característica adicional de esta publicación es que cada capítulo muestra un estilo gráfico particular debido a que el trabajo fue realizado por diferentes artistas.

Charlas TED

Chris Anderson (2017) comparte las experiencias y recomendaciones de charlas TED (o TED Talks) que permiten hacernos una idea de lo que debemos –y no debemos– hacer al momento de preparar una presentación. La lectura nos explica cómo debemos empezar una presentación, como conversar con el público y lo más importante, qué tanto debemos ensayar antes de salir al público.

Mayor información sobre el review

Les cuento que he preparado un documento con información adicional al review que acabo de escribir. Este contiene la ficha técnica de cada libro y claro, una versión extendida del review que acaban de leer 🙂

Quedo atento a sus comentarios, un abrazo.

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]

new beta release in process