Funciones y métodos mentirosos

por Fernando el 31/07/2013

Una de las prácticas más importantes para ir mejorando el código que producimos, consiste en leer, reflexivamente, el nombre de nuestras funciones y métodos para, a continuación, examinar su código. Una vez hecho esto, debemos preguntarnos si la función o método, a través de su nombre, nos está mintiendo. Y nos estará mintiendo, si no hace únicamente lo que su nombre sugiere.

Partiendo de la premisa de que una función debe de hacer una y solo una cosa, y que no es otra que la que dice que hace, podremos valorar el tomar una decisión de refactorización. La decisión puede ser:

  • No hacer nada. Haremos esto si la función, efectivamente, hace única y exclusivamente lo que su nombre dice que hace.
  • Cambiarle el nombre para que diga lo que realmente hace. Y sin miedo de que sea un nombre explícito, es decir, largo (los que trabajamos con Objective C no tendremos muchos complejos con este punto).
  • Descomponerla en otras funciones que hagan parte de su trabajo, crear otra que las coordine y sustituir la llamada original por esa nueva función coordinadora.

Esta práctica mejora de forma evidente la legibilidad del código producido, pues se generan funciones y métodos mucho más pequeños y claros, que facilitan la lectura y comprensión posterior de la implementación. Además, ayuda a entender mejor el propósito de aquello que estamos construyendo. Piensa que lo que estás haciendo es elegir los mejores nombres posibles para el código. Los nombres que elegimos son, al fin y al cabo, los que mejor explican cómo se hace aquello que estamos construyendo.

Elegir nombres no mentirosos suena sencillo sobre el papel pero, en la práctica, es difícil. Muy difícil. Y es difícil por dos motivos principales. El primero es que requiere esfuerzo y voluntad a la hora de trabajar (ya escribí algo relacionado con esto). Y, en segundo lugar, porque requiere de tiempo para pensar y refactorizar el nombre. Y no siempre la elección primera, segunda o enésima es la mejor. Lo normal es que vayamos refactorizando a medida que avanzamos, o volvemos, en el código.

Voy a poner un sencillo ejemplo. Pensemos que nos encontramos con este método:

¿Es mentirosa esta función? ¿hace realmente lo que dice que hace? Si tu, u otra persona, leyera el nombre de la función, sin ver el código, ¿tendría una absoluta certeza de lo que ocurre?

Aunque parece que es fácil decir que sí, examinando el código, vemos que hace realmente tres cosas diferentes. Por un lado, configura el delegado del controlador recibido, por otro, crea, configura y asigna a una variable de miembro el popover y, finalmente, hace lo que, supuestamente, únicamente iba a hacer: presentar el popover usando el View Controller pasado, sobre el área ocupada por la View recibida también por parámetro.

Una alternativa, siempre hay más de una solución, podría ser pensar en tres métodos:

Y coordinarlos desde uno más genérico llamado

Comparémoslo con el que había originalmente:

Como podemos observar, ahora la persona que lea el código va a tender, con mayor probabilidad, a pensar que lo que va a realizar es preparar el View Controller que enviamos y crear un nuevo popover que lo represente y que, seguro, sustituirá al que tenemos configurándolo (porque es nuevo).

Esto que, leído en este post, parece tan trivial y de sentido común, no lo es tanto. Examina tu código y responde, honestamente, cuántas veces has visto funciones o métodos que te mienten, o que te mentirán pasado un tiempo, porque ya no te acordarás de lo que hacían. Como digo, es algo de sentido común pero que requiere el esfuerzo y la voluntad de querer hacer las cosas bien y lo más profesionalmente posible. Y esto no es fácil. Requiere disciplina.

Seguramente que haya multitud de ocasiones en las que no tendremos tiempo para dejar el código como queremos. Es comprensible en primera instancia, pero siempre hay que sacar huecos para ir refactorizando. ¡Debe de ir en el tiempo presupuestado al cliente o a tu manager! Si no lo hacemos, estaremos programando sobre un gran basurero de código y, tarde o temprano, el proceso se convertirá en un infierno difícil de mantener (y más de soportar), que alargará, o imposibilitará, la implementación de futuros contratos o ampliaciones sobre el mismo código.

Escribe un comentario: