«La puerta por donde entrares, déjala como la encontrares» me repetían en mi casa para hacerme consciente de mantener las cosas ordenadas y en su sitio. Y aún lo siguen haciendo.

Pero, desde hace un tiempo veo que, cuando hablamos de código, no siempre es así.

Otra de las frases que se suelen dar en un entorno de desarrolladores es «Si funciona, no lo toques».

A mí nunca me ha parecido tranquilizador, pese a que en ocasiones no hay discusión posible, por falta de tiempo. Por eso, intento ir aplicando la idea de dejar las cosas mejor que cuando llegué. Y me baso en tres ideas principales para alcanzar una mejora en la calidad de mi trabajo.

El Kaizen o mejora continua

Hace años, durante la carrera, oí hablar de la idea usada en Toyota sobre la mejora continua de los procesos, también llamado Kaizen.

Ya entonces me pareció la forma más lógica, sencilla, fácil y barata de mejorar las cosas a medio y largo plazo. Se trata de introducir cambios muy pequeños, de manera frecuente, en los procesos. Poco a poco, se va consiguiendo mejorar la productividad y la calidad en la empresa.

Es importante entender que, en la terminología relativa a la gestión de la calidad, la calidad de un producto o servicio se determina en tanto se ha ejecutado conforme con unos parámetros establecidos previamente. En lenguaje coloquial, la calidad es inversa al número de sorpresas inesperadas que nos encontramos al entregar un producto o realizar un servicio.

En mi opinión, este método kaizen consigue varias cosas:

• Cuesta menos conseguir que se cumpla un cambio pequeño que un cambio grande.
• Si el cambio no consigue los resultados esperados, el coste de haberlo introducido ha sido bajo y el coste de descartarlo también lo será.
• El efecto de varios cambios pequeños va a equivaler a un gran cambio en el transcurso de no demasiado tiempo.

Para que estos cambios sean realmente útiles hay que tener en cuenta que éstos deben tener entidad por sí mismos y deben ser asumidos por todos los miembros implicados en el proceso. No deben ser una parte de otro proceso mayor porque, entonces, el descartar este cambio afectará a todo el proceso. Y la idea es que aporte mejoras al aplicarlo, no inconvenientes al retirarlo.

Los estándares de código de WordPress

Por otro lado, casi desde el primer momento que empecé a hacer cositas con WordPress ví que había unas formas estándar de codificar para normalizar el código del CMS.

Encontrarse código con un estilo que resulte familiar ayuda a encontrar problemas más rápidamente y a hacer el trabajo más compartible. Antes o después, lo vas a agradecer.

Si bien he oído criticar la calidad del código de WordPress, así como de otros CMS de código abierto, para mí, el argumento de conseguir un código más democrático, en cuanto a que sea más sencillo de entender para desarrolladores no-expertos, pesa más que el conseguir cumplir a rajatabla algunos otros principios de la programación.

Así que desde el principio he querido escribir el código siguiendo en menor o mayor medida los estándares de código de WordPress. Cosa que se ha convertido en algo serio desde que descubrí la posibilidad de poder integrar phpcs con las reglas WPCS y mi editor para todos los días.

Sin duda las ventajas son múltiples. Ya no solamente por el hecho de acabar con un código ordenadito que da gusto verlo, sino porque entre las alertas que te muestra phpcs, se incluyen recomendaciones que mejoran la seguridad del código y la documentación de métodos y funciones.

Por aquí dejo unas guías “random” de las muchas que se pueden encontrar en intentet:

WPCS en VSCode

WPCS en Sublime text

El refactor pequeñito

Con esto y algunos conceptos extraídos de La guía del refactor cotidiano de Fran Iglesias, cada vez que cae un trozo de código en mi editor, intento hacer pequeños cambios que lo acerquen más al estándar de código que toque, en general WordPress. Mejorar nombres de funciones y variables, aplicar cambios que puedan mejorar la optimización del código…

Muchas veces estas pequeñas mejoras no aportan demasiada mejora al rendimiento pero la suma de todas, a lo largo del tiempo, va haciendo el código más eficiente y, sobre todo, más mantenible.

Además, con este esfuerzo pequeño, pero cotidiano voy interiorizando buenas costumbres.

Una de regalo: Hansei

Podemos entender el Hansei como el análisis de los propios errores y posterior búsqueda de una solución para ellos.

Pero va un poco más allá. Incluso cuando todo parece haber salido bien, el hansei va a entrar a analizar si hay algo que se podría haber hecho mejor, y qué cambio haría que mejorase. Podría decirse que, ya en el medio plazo, el hansei será el proceso de análisis del que surgirán esos pequeños cambios del kaizen.

Y hasta aquí la entrada de hoy, quizás algunos conceptos aquí expuestos no sean completamente correctos. Llegado el caso, quizás evalúe si es necesario introducir pequeñas mejoras.

¡Hasta la próxima!