¿Cómo evitas la abstracción prematura?

Ian Bicking tiene una muy buena publicación en “El uso excesivo de funciones”. Y creo que mi respuesta (interstar) en los comentarios también es buena.

No estoy seguro de que haya reglas duras y rápidas. Identificar elementos comunes que vale la pena refactorizar es un arte más que una ciencia. Las personas inteligentes pueden estar legítimamente en desacuerdo.

Pero hay cosas a las que diría que vale la pena prestar atención:

1) No se trata solo de líneas de código. En su lugar, trate de tener una idea del número de puntos de decisión o “bits de información” que representa cualquier fragmento de código. Incluso vale la pena abstraer / refactorizar media línea de código si representa varias decisiones que serían fáciles de olvidar o inconsistentes.

Un buen ejemplo es que cada vez que te encuentres construyendo una tupla, vale la pena estar alerta ante la posibilidad de refactorizar. P.ej. si te encuentras escribiendo
(nombre, edad, peso) más de una vez, puede que no valga la pena crear una clase especial, sino al menos una función de constructor para armar esa tupla. ¿Por qué? Porque a pesar de ser tan breve, ese código representa varias * decisiones * … lo que entra en la tupla y en qué orden están. Ese es el tipo de cosas que es fácil de olvidar. Si me encontraba escribiendo esto en tres o cuatro lugares, probablemente abstraería.

Un caso similar es cuando construyes una cadena de varias partes. Si es importante que esa cadena sea consistente, considere un constructor especial para ella.

Por otro lado, si tiene un gran bloque de repetitivo que realmente no representa ninguna decisión que haya tomado, puede que no sea tan urgente abstraerse de él. Aunque lo haría solo para deshacerme de la contaminación visual.

2) Otra forma de pensar sobre esto. Algunos bits de código son iguales porque HACEN lo mismo. Pero otros bits de código son iguales porque significan lo mismo. Los segundos son más urgentes para abstraer que los primeros.

3) Pero, por supuesto, el valor de la abstracción también depende de qué tan barato sea hacerlos. Un lenguaje donde todo exige una clase, es más pesado que un lenguaje con funciones flotantes.

4) Considera qué espacio de nombres estás abarrotando con tus nuevas abstracciones. Si es global, es peor que abarrotar el módulo en el que se encuentra. Aún mejor es si logra contener sus abstracciones dentro de los miembros privados de una clase o incluso como funciones locales dentro de un solo método.

5) Las abstracciones pueden o no ahorrarle números absolutos de caracteres a corto plazo. Pero SIEMPRE deben hacer que el código que los usa sea más fácil de entender. El nombre de tu abstracción siempre debe corresponder a algo que puedas con fluidez.

Uno de los problemas para las personas que aprenden la Programación Funcional es que las abstracciones son tan desconocidas que no parecen hacer que el código sea más fácil de leer porque hay que ir a buscar lo que significa un pliegue. Obviamente, las personas con PF conocen esos términos íntimamente y no tienen problemas. Pero tenga en cuenta hacer abstracciones con nombres que no lo ayuden a comprender qué hace realmente el código que los usa.