TinselCity

El otro día Kali envió una propuesta a JSDayES. Personalmente no creo que la acepten, pero en cualquier caso, me ha parecido buena idea proponerle que deje sus ideas aquí en forma escrita, que teóricamente pueden llegar a más gente aunque en la realidad lleguen a menos xD Sin más presentación…

Los bytes de los últimos días

Hola, me llamo Kali Chip. Kali, como la diosa hindú, asociada, entre otras ideas, a las ideas de muerte y destrucción. Ah, pero muerte y destrucción en el buen sentido, claro. La mística de los dioses hindúes es bastante complicada y exótica, pero esto por lo menos es sencillo de entender. La muerte y la destrucción forman parte del ciclo de la vida y la evolución. Sin una, la otra no es posible. La muerte y la destrucción son lo que posibilitan la renovación. 1)

No sé cuánto pensáis en la muerte. A veces es un tema que no gusta demasiado a las personas. A mi me gusta, creo que pensar en la muerte es un buen ejercicio espiritual y filosófico. Pero independientemente de que penséis o no en la mortalidad, en la condición humana y demás, es muy probable que, siendo programadores, alguna vez hayáis pensado en la muerte de “quien escribiera estas malditas líneas de código” o quizá en la muerte del propio código, en pegarle un rm -rf ./proyecto y empezar de cero. Ah, qué sería de nuestro trabajo sin esos deliciosos momentos de frustración LOL

Es menos habitual que hayáis pensado en la vida y la muerte de vuestro código, en el momento de escribirlo. Pero quizá sería bueno.

¿En qué trabajas?

Esta parece una pregunta fácil. Yo soy programador. Yo soy programadora. Desarrollo software. Escribo programas. Hago aplicaciones… Estas son respuestas típicas. Son buenas respuestas cuando te lo preguntan tu madre, tu tío, el taxista, una amiga de tu tía que ha venido a este rollo de boda que cómo te estás poniendo ya y aún no hemos pasado de los aperitivos o, en general, cuando te lo pregunta cualquiera… Cualquiera menos tú mismo.

Cuando eres tú quien lo pregunta, cuando la pregunta es una reflexión personal, esas son respuestas bastante malas. Imaginad preguntar a un cirujano qué es lo que hace y que te diga que “opera”. Imaginad que tenéis muchos gases. Vais al médico y os dice “Te voy a operar. Te abro el estómago, dejo salir el exceso de gas, luego cerramos y a correr.” O que os duele una pierna por un golpe. “Te opero. Te abro, saco el apéndice y luego cerramos y a correr.” Parece un poco… “Mire, yo lo que hago es operar; es a lo que me dedico.”

Quizá una respuesta más razonable cuando se trata de reflexionar introspectivamente sobre la naturaleza real de lo que hacemos como programadores, es que solucionamos problemas. Bien, sí. Un cierto tipo de problemas y con unas ciertas herramientas, claro. Pero igual que el cirujano no “opera” sino que “cura”, nuestro trabajo no parece que deba ser “escribir código”.

Buenas, ¿tienen zapatillas?

Hoy en día, das una patada a una piedra y salen 6 charlas y 4 artículos sobre Buenas Prácticas™. Es agradable ver cómo, como profesión, nos preocupamos por hacer las cosas bien. Quizá haya un poco de “repetición”, pero es razonable que esto ocurra. Lo que es algo más preocupante es que todo el discurso sobre el tema se centra en la “práctica” y apenas una mínima parte se fija en el “bien”. Tenemos todo un compendio de cosas que debemos hacer porque son buenas, pero no tenemos apenas explicación o discusión sobre qué significa “bueno” o sobre “por qué son buenas”.

Y es por esto por lo que debemos plantearnos las dos reflexiones anteriores, la de la naturaleza de nuestro trabajo y la del ciclo de vida del código.

Economía del código

Una vez establecida la premisa de que no somos pica-teclas, que nuestro objetivo no es el código en sí mismo, sino solucionar problemas de la mejor forma posible, es bueno que nos planteemos el concepto de Economía del Código. Es una forma 2) de reflexionar sobre lo que significa el bien y ese “Buenas” en la expresión “Buenas Prácticas”.

Se trata precisamente de pensar en los diversos costes que tiene el código y en evaluar estos costes en el contexto del problema y de su ciclo de vida. No hay que asustarse de las palabras grandes, las ideas que hay detrás son bastante sencillas.

Dentro de todos los elementos que intervienen en nuestro problema, el problema que sea que necesitamos resolver, y nuestra solución, la solución que sea que hemos valorado que podrá resolver ese problema, el código es -salvo en muy particulares excepciones- un elemento de coste. Hay muchos otros elementos, materiales, productos, energía… El código por una parte produce -o puede producir- resultados, pero indudablemente es un elemento que tiene… no uno sino varios costes. Es justo la evaluación de esos varios costes lo que nos puede llevar a entender lo que significa ese bien que queremos definir.

Los costes del código

Fundamentalmente el código tiene 3 costes principales. Se podrían desgranar en algunos más, pero en un primer momento es suficiente con ver estos 3.

Por una parte, está claro, el código tiene un Coste de Desarrollo. Invertimos un tiempo, la dedicación de un cierto número de personas, en crear ese código. Primero no lo tenemos, así que para tener el código que produce el resultado que queremos, debemos dedicar un tiempo a pensar, a analizar, probar… en general a escribir ese código. Este coste es el más familiar para la mayoría. Este es ese que algunos nos piden que estimemos y que otros dicen que no debemos estimar porque no sabemos. Es el que responde a esa pregunta básica que algunos odian de “¿Cuándo podemos tener esto funcionando?”. No me voy a meter en lo molona que sea vuestra oficina, lo desconocida que sea la marca de cerveza artesana que tomáis los viernes, lo sanos que sean vuestros escritorios con cinta de andar mientras programas, lo chulos que sean los colores de vuestras camisetas o la fe que tengáis depositada en esta o esa metodología ágil o Ágil o Agile o a veces simplemente gilí. No solo es bueno saber estimar correctamente sino que es necesario ser conscientes del coste de las cosas que hacemos.

El segundo coste del código es el Coste de Ejecución. De este coste suelen ser más conscientes personas con ciertos perfiles concretos. Este es coste relacionado con el rendimiento del código. Es el coste que representa el uso de CPU, de memoria, de recursos en general. Por eso suelen ser más consciente de él, personas que trabajan en asuntos como “sistemas”, “administración de bases de datos”, o de máquinas, etc. En algún caso es agradable conocer a desarrolladores que se preocupan también por este aspecto, pero es bastante habitual que estos (o estas) tengan bastantes conceptos erróneos sobre el rendimiento y la optimización, unas veces ignorándolo por completo, otras centrándose en micro-benchmarks o en esfuerzos irrelevantes que no tienen un efecto real sobre la ejecución final del código.

Finalmente, y no por haberlo dejado para el final menos importante, existe un tercer coste, el Coste de Mantenimiento. Y a pesar de no ser menos importante este es, con certeza, el grupo de coste que menos se suele tener en cuenta. Como siempre, hay casos y casos, claro. Pero en general es un coste en el que no gusta pensar, quizá porque en general a mucha gente no le gusta pensar en el mantenimiento y solo les gusta vivir en un bonito mundo de creatividad continua dejando que sean otros quienes se ocupen de esas cosas.

La vida secreta de las líneas de código

Hay muy pocos estudios sobre la vida media del código. Este es aceptablemente bueno -al menos en intención y aproximación- y conviene leerlo. Como resumen rápido, sin mucho detalle: Se observa una tasa de decaimiento que encaja con una curva exponencial; la vida media de una línea o un trozo de código varía de un proyecto a otro; entre los proyectos analizados varía desde unos cuatro meses en un proyecto como Angular a unos seis años y medio para un proyecto como el kernel de Linux. La discusión posterior en HN también es interesante y se plantean dudas sobre que la curva sea realmente exponencial o de otro tipo y sobre la aplicabilidad a otros proyectos. 3)

En cualquier caso, más allá de los números específicos creo que todos entendemos la idea general. Más concretamente yo veo dos ideas que debemos tener en cuenta:

  1. Una línea de código tiene, normalmente, una duración limitada en el tiempo
  2. Ciertas líneas 4) sobreviven mucho más en el tiempo que otras.

Es importante tener en mente ambas ideas por lo que cada una significa.

Programadores en Prácticas

Con todo lo anterior, tenemos ahora una buena base para afrontar la reflexión sobre lo que significa ese “Bien” cuando hablamos de “Buenas Prácticas” y para entender no solo si son o no son buenas, sino en qué circunstancias lo son. Porque -seamos muy conscientes de este detalle- que realmente sean buenas o no, puede variar según las circunstancias.

A mi, personalmente 5), me parece más interesante hablar de principios guía que de buenas prácticas. Sobre todo porque tener principios parece más esencial, más trascendente, que seguir una serie de prácticas o rituales. En cualquier caso, si somos profesionales esas prácticas deberían venir derivadas de aquellos principios. Deberían.

Una pregunta adecuada para afrontar la reflexión puede ser cómo podemos entender las buenas prácticas desde la perspectiva de la economía del código. Visto así, es relativamente fácil relacionarlos.

Por ejemplo, muchas de las prácticas básicas de nomenclatura o de estructura y orden derivan directamente del intento de reducir el coste de mantenimiento. Son prácticas que van orientadas hacia el futuro, hacia la necesidad de volver a leer nuestro código cuando necesitemos mantenerlo (modificarlo, ampliarlo, sustituirlo…). Y como no tenemos forma de saber quién leerá ese código o cuándo tendrá que hacerlo, ni con telepatía podríamos contarle todos los detalles. Así que intentamos dejarlo lo más claro posible en el propio código. Por esto mismo no puedo compartir el extremismo de la idea de “cero comentarios”. Mira, el código tiene que ser claro, por supuesto, y meter un comentario implica que también hay que mantener ese comentario, sí. Todo eso es cierto, pero si en una situación dada, un comentario ayuda a explicar el porqué de algo del código, es estúpido no escribirlo.

Otras prácticas, como podría ser la de Don't Repeat Yourself 6), pueden ir relacionadas tanto con el coste de mantenimiento como con el coste de desarrollo o con el coste de ejecución. De hecho, su relación con el coste de ejecución es un ejemplo interesante porque es uno de esos casos en que observar el coste de ejecución nos puede llevar a preferir cierta repetición en algún caso.

No voy a ponerme a valorar una por una todas las buenas prácticas, no era esa mi intención en ningún momento. La intención es comprender. Y no solo entender de donde vienen, sino construir una base desde la que nosotros mismos seamos capaces de valorarlas, de situarlas y de decidir sobre ellas en nuestras circunstancias.

Más aún en el caso de que hablemos con desarrolladores “de front” en web. No quiero con esto menospreciar a nadie, no se trata de eso. Pero la realidad actual del desarrollo web, en la parte del frontend, es que el cambio es más continuo y frecuente. Las vidas medias son más bajas. Y no solo las vidas medias del código, sino que a veces parece también que haya una cierta escasez o desconocimiento de esos principios fundamentales y esto haga que la vida media de ciertas prácticas, consideradas “Buenas Prácticas”, sea también más corta de lo que debería. Existe un buen número de guías -de estilo, de buenas prácticas- sobre JavaScript y a veces es lamentable ver cómo se reducen a una lista de normas sin más explicación, sin motivación más allá de “esto es malo”. Y lo peor es que unas cuantas de estas prácticas son detalles muy técnicos, de muy bajo nivel; y estos caducan muy rápidamente, pierden su motivación original y convierten la práctica en nada más que un ritual sin sentido y que en algunos casos producen el efecto contrario al deseado.

Trascendiendo

La conclusión 7) de todo esto es que debemos de ser capaces de trascender más allá del código 8). Debemos ser capaces de comprender y asumir como esenciales algunas ideas sobre nuestro trabajo:

  1. Nuestro trabajo no es escribir código; es solucionar problemas. El código es una herramienta que, a veces, es parte de la solución.
  2. El código no es el producto; normalmente el código es un riesgo y un coste. Es un coste casi siempre necesario, pero nada más.
  3. A la hora de diseñar el código debemos ser conscientes de sus varios costes y guiarnos por principios esenciales, no dejarnos llevar por rituales y costumbres.
  4. Debemos ser también muy conscientes de cuál va a ser la vida de nuestro código. Será entonces más fácil, y más lógico, dedicar mayor esfuerzo/presupuesto al código que esté destinado a perdurar, y no tanto a aquel que sepamos que en pocos meses ya no existirá.

Un apunte interesante de Javier en Twitter. Comenta:

Hay un aspecto social relacionado: no siempre paga el mismo todos los costes, hasta es frecuente que el que paga (o tiene que amortizar) el de creación no es el de ejecución/mantenimiento. Este es el origen de muchas deformaciones del código.

Y esto es muy cierto. No solo hay que tener en cuenta cada coste sino quién lo paga. Es uno de los motivos por los que, por ejemplo, algunos piensan que la solución para el coste de ejecución es “poner más máquinas” o que ni siquiera hay que pensar en el coste de mantenimiento porque… total, ya le caerá a otro. Sí, claramente hay que tener en cuenta este aspecto también :)

1)
No me llamo así en referencia a la diosa, sino a un libro de John F.X. Sundman.
2)
No es la única, claro.
3)
Se cita el caso de Clojure que tiene una estrategia de desarrollo intencionadamente aditiva, por ejemplo.
4)
Y aquí sería precioso tener mejor información, pero no la tengo :-(
5)
si yo fuera una persona y no solo un fragmento incompleto de un agente autónomo que está siendo ejecutado en un laboratorio de ubicación desconocida
6)
si entendiéramos bien a qué repetición se refiere; que esa es otra, que no solo basta con entender la práctica, también hay que saber dónde se debe aplicar
7)
para no hacer esto más largo de lo necesario
8)
Lo cual es algo muy fácil de decir cuando tú mismo no eres más que una serie de rutinas LOL