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 con 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 relacionadas con 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, que más y mejores habilidades tiene su autor. En software, la verdadera habilidad y excelencia consisten en encontrar una solución sencilla a un problema complejo. Siempre me ha causado admiración ver cómo se encuentran soluciones comprensibles que 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 la sencillez mientras programamos.
Idea contraintuitiva #2
El diseño de una solución también evoluciona y crece, así como su arquitectura.
En el 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: hay que cambiar el diseño para ajustarlo a la nueva funcionalidad que se va incorporando. Se mejora continuamente la calidad del código y también su diseño.
Idea contraintuitiva #3
Hacer pruebas aumenta la productividad.
Cuántas veces he oído lo mismo: «No tengo tiempo para hacer pruebas». Decir esto no es profesional, ya que respaldar nuestro código con pruebas no es una tarea ajena al desarrollo de software, sino inherente a él. Contrariamente a lo que pueda parecer, escribir pruebas reduce el tiempo dedicado a detectar y corregir errores, además de darle solidez a la aplicación.
Idea contraintuitiva #4
Hacer pruebas es un modo de documentar nuestro proyecto.
El exceso de comentarios insertados a lo largo del código es un síntoma de su pobreza. En ocasiones puntuales son necesarios, pero su sobreutilización revela que el código no es lo suficientemente simple y fácil de entender. En cuanto a las pruebas, ¿cómo podemos aprender a usar una clase, una librería, un módulo, etc.? Efectivamente, con las pruebas que los respaldan. Nada mejor que aprender cómo se utiliza algo que con código que lo prueba.
Idea contraintuitiva #5
Hacer pruebas obliga, en cierta medida, a realizar un mejor diseño.
Plantea una aplicación monolítica para hacer cualquier cosa que se te ocurra. Con toda seguridad, obtendrás una serie de clases con métodos muy largos, acoplados y rígidos, aunque funcione y cumpla 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á probarse manualmente, poco más. Si quieres introducir pruebas en ella, pronto te darás cuenta de que su estructura y la relación entre sus componentes (el diseño) deben cambiar: deben mejorar. Hacer pruebas 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 el código para que se ejecute con mejor rendimiento es una tarea habitual, sobre todo para aquellas partes de la aplicación que se ejecutan con más frecuencia. 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 la creación de pruebas para respaldar nuestro trabajo, también debemos incluir esas pequeñas optimizaciones que mejoran su rendimiento, siempre y cuando no sacrifiquemos la simplicidad ni la legibilidad.
Del mismo modo 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, sino también con un mejor diseño.
La solución rápida cuando aparecen problemas de rendimiento consiste en añadir más hardware al sistema de producción donde se ejecuta la aplicación: más memoria para el motor de la base de datos, más discos SSD, balanceo entre servidores, etc. Puede que sea necesario, pero en ocasiones ese coste no hace más que tapar una arquitectura, un diseño o una solución pobres e ineficientes. 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 activo de un proyecto de software, también está sujeto a una mejora continua.
Todos los elementos de una aplicación son susceptibles de mejora: desde archivos CSS, HTML y scripts de front-end en JavaScript hasta soluciones de más alto nivel en C#. Absolutamente todo. Las bases de datos y su diseño no escapan a esta mejora y evolución continuas. Si mantenemos su rigidez inicial, o el modo en que se planteó originalmente la base de datos, tendremos el problema de intentar encajar a la fuerza 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: refactorizaciones simples (como las descritas en este libro), pequeñas mejoras en la legibilidad del código siguiendo las técnicas de código limpio, mejoras en el diseño, cambios insignificantes en la organización del proyecto, etc. Con el tiempo se acumulan cientos de pequeños cambios que realmente aumentan la calidad y la mantenibilidad de la aplicación. Además, muchas de estas mejoras son minitareas que se pueden realizar en minutos: mejorar los nombres de variables, simplificar un método, extraer código duplicado, agregar un par de pruebas unitarias, etc.
Nota: Este artículo es un resumen y forma parte del proyecto en desarrollo El Libro Práctico del Programador Ágil. Lanzamiento previsto para julio de 2018.