the black book of the programmer

Como parte de El Libro Práctico del Programador Ágil, he incluido un pequeño capítulo sobre un tema sobre el que he reflexionado mucho a lo largo de los años. En ocasiones, las cosas no son como parecen, y, sobre todo, en el desarrollo de software hay que hacer un gran trabajo de pedagogía a gestores de proyectos que no han programado lo suficiente, para hacerles comprender ciertos aspectos inherentes a la programación que no dejan de ser algo sutiles.

Las apreciaciones que voy a indicar a continuación, en un principio, pueden ir en contra de la intuición acerca de nuestra actividad como desarrolladores de software. Muchos de los errores que cometemos en nuestro desempeño profesional mientras programamos y diseñamos aplicaciones, derivan de no comprender ciertas sutilezas en relación a la producción de código de calidad.

Idea contraintuitiva #1

Es difícil hacer software simple

No podemos caer en el error de pensar que cuanto más complejo es algo, más difícil es, o peor aún, más y mejores habilidades tiene su autor. En software, la verdadera habilidad y excelencia consiste en encontrar una solución sencilla a un problema complejo. Es algo que para mí siempre me causó admiración comprobar cómo se encuentran soluciones entendibles y cómo resuelven problemas complejos. Nada peor que un sobrediseño innecesario, o añadir complejidad por no pararse unos minutos a buscar una solución más sencilla. Para ello, debemos tener siempre presente esta idea de la sencillez mientras programamos.

Idea contraintuitiva #2

El diseño de una solución también evoluciona y crece, así como su arquitectura

En desarrollo ágil (programar para que nuestra aplicación acepte cambios más fácilmente), se suele decir que el diseño emerge a medida que se implementan nuevos requisitos, y así es. Lo contrario es establecer un diseño al comienzo de la aplicación y tratar de mantenerlo rígido a toda costa. De ningún modo: el diseño hay que cambiarlo para ajustar a la nueva funcionalidad que se va incorporando. Se mejora la calidad del código de forma continua, también su diseño.

Idea contraintuitiva #3

Hacer tests aumenta la productividad

Cuántas veces he oído lo mismo: “no tengo tiempo para hacer tests”. Decir esto no es profesional, ya que respaldar con tests nuestro código no es una tarea ajena al desarrollo de software, sino inherente a ella. Contrariamente a lo que pueda parecer, escribir tests reduce el tiempo dedicado a detectar y corregir bugs, además de darle solidez a la aplicación.

Idea contraintuitiva #4

Hacer tests es un modo de documentación de nuestro proyecto

El exceso de comentarios insertados a lo largo del código es un síntoma de la pobreza del mismo. En ocasiones, contadas, son necesarios, pero en realidad su sobreutilización revela que el código no es lo suficientemente simple y fácil de entender. En relación a los tests, ¿cómo podemos aprender cómo usar una clase, una librería, un módulo, etc.? Efectivamente, con los tests que los respaldan. Nada mejor que aprender cómo se utiliza algo que con un código que lo prueba.

Idea contraintuitiva #5

Hacer tests obliga en cierta medida a realizar un mejor diseño

Plantea una aplicación monolítica para hacer cualquier cosa que se te ocurra. Te saldrá, con toda seguridad, una serie de clases con métodos muy largos, acoplados y rígidos, aunque funcione y realice su propósito… En este libro queremos aprender a programar para que nuestra aplicación acepte cambios más fácilmente y sea más mantenible, ¿no es así?

Esa aplicación monolítica solo podrá ser probada manualmente, poco más. Si quieres introducir tests en ella, pronto te darás cuenta de que su estructura y la relación de sus componentes (diseño) debe cambiar: debe mejorar. Hacer tests te obliga, en cierto modo, a crear un diseño mejor.

Idea contraintuitiva #6

La optimización del código es una tarea continua

Optimizar código para se ejecute con mejor rendimiento es una tarea habitual, sobre todo para aquellas partes de la aplicación que se ejecutan más frecuentemente. Sin embargo, dejar esa actividad para el final es un error. Del mismo modo que incluimos en nuestra práctica y rutina habitual de desarrollo el crear tests para respaldar nuestro trabajo, también debemos incluir esas pequeñas optimizaciones que mejoran el rendimiento del mismo, siempre y cuando no se sacrifique la simplicidad y su legibilidad.

Del mismo modo en que mejoramos la calidad del código y su diseño mediante pequeños pasos, ocurre lo mismo con su optimización.

Idea contraintuitiva #7

El rendimiento de una aplicación no solo se consigue con más hardware, también con un mejor diseño

La solución rápida cuando se presentan problemas de rendimiento, consiste en añadir más hierro al sistema de producción donde se ejecuta la aplicación: más memoria para el engine de la base de datos, más discos SSD, balanceo entre sevidores, etc. Puede que sea necesario, pero, en ocasiones ese coste lo que viene es a tapar una arquitectura, diseño y una solución pobre o ineficiente. He visto quemar, literalmente, miles de euros, en hardware para una solución con una arquitectura errónea y mal planteada.

Idea contraintuitiva #8

El diseño de las bases de datos, como cualquier otro asset de un proyecto software, también está sujeto a una mejora continua

Todos los elementos de una aplicación son susceptibles de mejora: desde archivos CSS, html, scripts de front-end en javascript hasta soluciones de más alto invel en C#. Absolutamente todo. Las bases de datos, su diseño, no escapan a esta mejora y evolución continuas.  Si mantenemos su rigidez inicial, o el modo en que se planteó inicialmente la base de datos, tendremos el problema de tratar de meter con calzador la nueva funcionalidad requerida.

Idea contraintuitiva #9

Una gran mejora siempre es producto de micro mejoras

En software se produce un efecto acumulativo cuando introducimos pequeños cambios de manera continuada: simples refactorings (como los descritos en este libro), mejoras minúsculas en la legibilidad del código siguiendo las técnicas de código limpio, mejoras en el diseño, mejoras insignificantes en la organización del proyecto, etc. Con el tiempo se van acumulando cientos de pequeños cambios que supondrán realmente aumentar la calidad y la mantenibilidad de la aplicación. Además, muchas de estas mejoras son mini tareas que se pueden realizar en minutos, como mejorar los nombres de variables, simplificar un método, extraer código duplicado, agregar un par de test unitarios, etc.

Nota: este artículo es es un resumen y forma parte del proyecto en desarrollo El Libro Práctico del Programador Ágil. Lanzamiento en julio 2018.

Hace ya cuatro años que publiqué El Libro Negro del Programador, con una segunda revisión de ese trabajo el año anterior. Desde entonces, no han parado de aumentar las reviews en Amazon así como los mensajes que me llegan directamente desde muchas partes del mundo.

Y todo esto, en definitiva, lo que me ha hecho es comprender que las problemáticas que se describen en el libro forman parte del sector en general, independientemente del país donde trabajes o del tipo de compañía.

Mala organización, software que se desarrolla sin cultura de tests, gestores de proyecto que no conocen la idiosincrasia inherente a un proyecto software, desarrolladores demasiado individualistas, ausencia de cultura de código limpio y de conocimiento de técnicas de refactoring, etc. Todo esto no ocurre más en el mundo castellano parlante, ni mucho menos, tan solo hay que ver algunos repositorios de código en GitHub, algunos de ellos muy populares.

He trabajado en proyectos internacionales con compañías de Suecia, USA y países de Oriente Medio y de Sudamérica, y puedo decir que lo que he visto con frecuencia viene a ser un poco más de lo mismo, las mismas dinámicas y problemas similares, salvo algunas excepciones de las que aprendí muchísimo y fueron fuentes de inspiración con las que tuve la suerte de cruzarme.

Por tanto, he lanzado una nueva edición de El Libro Negro del Programador pero esta vez en inglés, confiando en que sea de la misma ayuda para desarrolladores angloparlantes que para los lectores en español.

Y porque vivimos en un mercado global en donde todo lo digital y el conocimiento apenas tiene fronteras, y porque en el sector de la tecnología, el inglés es el idioma estándar de facto.

Confío en que este nuevo trabajo sea de la misma utilidad para todos los lectores que no hablan español pero sí leen en inglés y que funcione igual de bien tal y como lo ha hecho El Libro Negro del Programador en estos años.

A partir de ahora me propongo ir añadiendo contenido en inglés a mi web personal.