De qué hablo cuando hablo de programar (volumen 1)

A mis padres, hermana y mis hijas, Luna y Beatriz

A mi pareja Mercedes

Introducción

No es lo mismo programar que desarrollar una carrera profesional como programador.

Los capítulos que tienes a continuación (en esta primera entrega de dos), hablan exclusivamente de desarrollo de software y de todos esos temas relacionados con la creación de proyectos.

A diferencia de lo que muchos creen, sobre todo los que se acercan a esta actividad por primera vez y se integran en el mundo profesional, programar no es solo programar.

Como vengo escribiendo en todos mis libros desde que comencé con «El Libro Negro del Programador», pasando por «El Libro Práctico del Programador Ágil», «The Coder Habits» y otros, existen muchísimos elementos que rodean esta actividad y todos son necesarios para tener éxito con el código que escribimos.

Muchos de estos factores son bastante sutiles de ver y comprender, y se aprenden, me temo, con mucha experiencia acumulada (y también después de mucha prueba y error, me temo).

Si crees que programar es tan solo conocer un lenguaje o entorno y aplicarlo lo mejor posible, sigue leyendo.

Cualquiera puede aprender a escribir líneas de código, pero hacerlo bien no es tan fácil, hacerlo de forma profesional, menos aún, y mucho menos comprender que una aplicación es algo vivo que hay que diseñar, en cierto modo, para ser modificada a medida que se tiene que evolucionar.

Es como construir un edificio suponiendo que algunas de sus paredes, ventanas, estancias y hasta algunos pilares, en algún momento tendrán que ser destruidos y sustituidos «por otra cosa».

Esto afecta enormemente a cualquier definición de calidad de software que te puedas plantear.

Los capítulos que tienes a continuación, los he extraído como una colección de mis propios artículos escritos desde el año 2012 en mi web profesional (www.rafablanes.com). Son tan solo una parte de los más visitados.

Todos han sido mejorados, revisados y algunos hasta los he vuelto a escribir totalmente respetando el contenido original.

En ellos se hablan sobre muchos conceptos, pero todos, absolutamente todos, describen algún aspecto importante relacionado con el desarrollo de software, yo diría que hasta imprescindible.

Este conjunto de capítulos, forma un todo que no habla más que de la carrera de un desarrollador profesional; cuando leo de nuevo los títulos, me digo a mí mismo que ojalá hubiese tenido un texto así cuando comencé a trabajar como programador hace más de lo que me acuerdo.

Estos capítulos también forman cierto conjunto compacto, coherente y, como digo, todos giran alrededor de diferentes aspectos de nuestra actividad como programadores y que, muy a mi pesar, la mayoría de conceptos que describen no se enseñan en ninguna etapa académica pero sí se aprenden después de cometer muchos errores una y otra vez, si es que aprenden, claro.

Otros conceptos, en cambio, puede que nunca te hayas parado a pensar en ellos hasta que los lees en algún sitio (como en este libro).

Espero que ahora, que tienes un texto así, a ti no te pase.

Hay excelentes autores que también hablan de estas características relacionadas con el software y de los que he bebido desde hace años; no obstante, me temo que en castellano hay poco material al respecto.

Programar no es solo programar…, también conocer las razones de por qué el software ágil genera (bien implementado) código con mejor calidad. Normalmente, programamos en entornos colaborativos, por tanto, tenemos que organizarnos en él lo mejor posible. Además, existen muchos errores de concepto que veo repetidos una y otra vez (¿quieres más rendimiento…?, pues ¡a aumentar el tamaño de los servidores!, como si el diseño y la arquitectura no tuviesen algo que ver…) y hasta me atrevo a decir que no podremos programar bien si no nos rodeamos de un entorno adecuado para ello.

Del mismo modo, con pocas personas puedo mantener una conversación de meta-programación acerca de las razones por las que el software se corrompe necesariamente (salvo que se pongan los medios para impedirlo), o acerca de que el código únicamente «no cuenta toda la historia» que puede explicar cómo y por qué se ha hecho de ese modo y no de otro, y de ahí la dificultad de que un equipo nuevo lo asuma y tarde en poder modificarlo.

Son muchos temas diferentes que ahora presento en este formato renovado, revisado y actualizado.

He aprendido mucho en todos estos años desde que comencé a publicar regularmente en mi web y a lanzar mis libros técnicos junto con una gran cantidad de proyectos; no obstante, te puedo asegurar que todo el contenido que tienes ahora en tus manos habría cambiado radicalmente mi carrera profesional de haberlo conocido cuando apenas tenía veinte años y comencé a trabajar en la primera empresa que me contrató.

Del mismo modo, veo, no con tristeza, pero sí con cierto desánimo, cómo gran parte de los errores de concepto sobre los que hablo en las siguientes páginas son ignorados por muchos desarrolladores séniors, incluso CTOs, tanto en grandes entornos corporativos como en pequeños.

Tanto si estás empezando como si ya llevas muchos años en esto, apuesto a que este contenido al que le he dado el nombre de «De qué Hablo Cuando hablo de Programar (Volumen 1)», te será de enorme utilidad.

Rafael Gómez Blanes

Sevilla, junio de 2021

Chapter Uno

1

El programador kaizen

Existen muchos modos de organizar el trabajo y de abordarlo. He comprobado que kaizen es un método simple y absurdamente sencillo para mejorar casi todo lo que hago (mis proyectos software también).

Kaizen es un concepto japonés que viene a traducirse por «pequeño cambio» o «pequeña mejora» que en ese país es toda una filosofía de trabajo que explica cómo una nación próspera devastada por la Segunda Guerra Mundial, volvió a emerger a partir de los años sesenta hasta convertirse de nuevo en otra potencia económica y tecnológica.

Es también una filosofía de vida y una técnica maravillosa y sencilla de vencer la procrastinación, reducir lo complejo en pequeños pasos más simples y de mejorar en cualquier aspecto que te propongas.

En ingeniería del software se habla del concepto de mejora continua (continuous improvement), que puede ser nuestra particular aplicación práctica de kaizen.

Ahora bien, ¿mejorar en qué? ¿para qué?, y sobre todo, ¿cómo?

Puedo decir que practico kaizen desde hace años; sin ir más lejos, cada capítulo o sección de los libros que publico los encaro en ocasiones a ratos de veinte minutos, en otras, reviso y corrijo aquel texto que escribí hace ya un mes, y vuelvo a revisar y mejorar y ampliar el contenido en un sinfín de tareas e iteraciones que suelo anotar en aplicaciones como Microsft ToDo o Evernote.

Aunque considero que escribo y comparto experiencia en mis libros y artículos como parte de mi trabajo profesional, raro es el día o la semana en que puedo dedicarme a ello durante varias horas seguidas, sin interrupciones, de ahí que me obligo a mí mismo a identificar esas tareas de modo que sean cortas de realizar.

Precisamente por su tamaño y poca complejidad, las hago con facilidad y sin demasiado esfuerzo, y las realizo, quiero decir, que termino haciéndolas antes que tarde; lo importante es que «termino haciéndolas» sí o sí.

Así es como encaro la mayor parte del trabajo de redacción de un nuevo libro para compaginarlo con el resto de mis responsabilidades profesionales, que no son pocas.

¿Y por qué termino realizando esas minitareas?

La razón no es porque trabaje más que nadie, de ningún modo, sino que sé que la mayoría me van a suponer poco tiempo y casi siempre son más o menos sencillas de implementar, esto es, son pequeñas mejoras y pequeños avances en un proyecto como escribir este artículo: kaizen en estado puro.

En el momento de escribir esto, estoy avanzando mucho con uno de mis proyectos (Mantra); en ocasiones, tan solo abro el Visual Studio Code para crear dos o tres tests unitarios… Poca cosa, pero cuando multiplicas esto por mil a lo largo de meses, el resultado es impresionante.

Si llevas años sin correr, no te atrevas a tratar de salir a hacer cuatro kilómetros el primer día. Mejor hoy pasea un rato, mañana otro, la semana que viene camina pero a un ritmo algo mayor, en dos semanas ya puedes trotar y en un mes, tan solo introduciendo pequeños cambios en esa nueva rutina básica y simple que te estás construyendo, corre por fin unos cuantos cientos de metros.

Pequeños cambios y mejoras para abordar algo más complejo (como poder correr cinco kilómetros seguidos sin morirte en el intento).

Te preguntarás que qué tiene esto que ver con el desarrollo de software…

Kaizen funciona porque nos permite evitar el boicot de nuestra propia mente cuando la enfrentamos a trabajos complejos, pesados y que requieren un gran esfuerzo (o que tampoco nos estimulan y motivan especialmente). Recuerda, nuestro cerebro está diseñado para mantenermos en una cálida zona de confort (seguridad) y le asusta cualquier cosa que nos saque de ella, aunque sabemos que de un modo u otro, aquello que queremos conseguir (esa tarea compleja) requerirá salir de esa zona de confort en forma de esfuerzo y quebraderos de cabeza.

Con esta técnica evitamos ese mecanismo primitivo de autoprotección que nos impide en muchas ocasiones mejorar (o avanzar en nuestros proyectos), y me atrevo a decir que también en nuestros propósitos vitales.

¿Acaso tiene que ver kaizen con programar o modernizar esa aplicación heredada monolítica, fea y mal desarrollada, o avanzar en un proyecto personal para el que apenas tienes tiempo o escribir esos tests que se resisten?

Pues sí, y mucho, porque si afrontamos nuestro trabajo de ese modo, aunque parezcan tareas pequeñas, llegaremos más lejos, y lo podemos hacer practicando kaizen: paso a paso, pequeña tarea más pequeña tarea, una minúscula mejora aquí y otra allá y, cuando nos demos cuenta, después de acumular cientos de pequeñas mejoras (o miles), nuestra aplicación comienza a brillar, a contar con un mejor diseño y a estar mejor estructurada.

Además, si trabajas en una aplicación compleja y frágil, introducir pequeños cambios nos dará la seguridad de que en caso de efectos secundarios, los detectaremos con rapidez y también será más sencillo resolverlos.

No es trabajar menos horas, sino hacerlo de manera más descansada y avanzando con más seguridad.

Por otro lado, es una forma maravillosamente simple de poder asumir en el día a día responsabilidades muy diferentes.

Tan pronto como tengas que realizar algo que parece «grande», complicado y hasta pesado, tan solo tienes que descomponerlo en pequeñas tareas, cuanto más pequeñas mejor, darte una fecha e ir terminándolas una detrás de la otra.

Desarrollar buen software requiere de cuidar de muchos detalles: dos o tres pequeñas mejoras hoy, suponen decenas a lo largo tan solo de un mes y quizá miles a lo largo de un proyecto cualquiera.

Con el tiempo, me atrevo a decir que hasta desarrollas cierta «mente Kaizen», y comienzas a tirar de tu lista de tareas continuamente porque ves oportunidades de pulir esto y lo otro por todos lados, o bien te sientas un rato a añadir con placer más tareas a tus listas, porque sabes que las harás en algún momento.

Sospecho que se es mucho más productivo afrontando el trabajo mediante periodos cortos de concentración (tal y como sugiere la técnica del pomodoro) que sentarte una mañana entera y no despegar los ojos de la pantalla, más aún cuando tienes que atender, como es mi caso, tareas de muy distinta naturaleza.

Enfoca tu trabajo como desarrollador desde la perspectiva del kaizen y descubrirás que puedes hacer más cosas con menos esfuerzo.

2

Qué es la deuda técnica y cómo se produce

No lo olvides: la deuda técnica es tu enemigo número uno como desarrollador de software y, curiosamente, en nuestra etapa académica nunca se habla de ella ni de sus consecuencias.

Si llevas poco tiempo programando, enhorabuena, lo que vas a leer a continuación puede que te ahorre miles de horas de trabajo y tu carrera profesional sea mejor a lo largo del tiempo.

Si llevas varios años en esta profesión y no has conceptualizado lo suficiente las consecuencias de acumular «deuda técnica», sigue leyendo.

Algo que siempre me gustó de la programación, es que el desarrollo de software presenta aspectos sutiles que son difíciles de comprender en un principio hasta que lo experimentas por ti mismo: pequeñas decisiones, minúsculos cambios en el diseño, detalles aparentemente insignificantes… pueden implicar grandes consecuencias en el largo plazo de cualquier proyecto.

Quizá un buen método de aprendizaje consista en caer en todos los errores posibles y después darte cuenta de su solución, aunque lamentablemente eso, en el contexto de una compañía, supone pérdida de ingresos, proyectos fracasados y, lo más probable, la búsqueda de un nuevo empleo.

Con el tiempo y la experiencia, vas acumulando cierta sabiduría de modo que ya sabes con antelación las consecuencias a largo plazo de hacer algo de un modo o de otro.

Imagina qué ocurriría si durante un mes, nadie se preocupa de recoger, ordenar y limpiar la cocina de tu casa. El primer día no pasaría nada, el segundo, quizá, es ya algo molesto prepararte un simple sándwich. Pero sin