La Simplicidad viene de la Reducción

La Simplicidad viene de la Reducción
Autor: Paul W. Homer

“Hazlo de nuevo…”, me dijo el jefe mientras su dedo presionaba con fuerza la tecla de borrado. Miré la pantalla de la computadora con una sensación de vacío muy familiar, mientras mi código –línea tras línea– desparecía en el olvido.

Mi jefe, Stefan, no siempre fue el más vocal de las personas, pero él sabía que era un mal código cuando lo veía. Y sabía exactamente qué hacer con él.

Había llegado a mi puesto actual como un programador estudiante con mucha energía, mucho entusiasmo y sin la menor idea de cómo codificar. Tenía esa horrible tendencia a pensar que la solución a cada problema era agregar otra variable en algún lugar. O escribir otra línea. En un mal día, en vez de que la lógica fuera haciéndose mejor con cada revisión, mi código se hacía gradualmente más grande, más complejo y mucho más lejos del trabajo consistente.

Es natural, sobre todo cuando estás apresurado, que sólo quieres hacer los menores cambios a un bloque de código existente, aunque sea horrible. Muchos programadores preservan mal código, temen que iniciar de nuevo requerirá mucho más esfuerzo que continuar donde se quedaron. Esto puede ser cierto para el código que está cerca de ser funcional, pero hay algunos códigos que están más allá de toda ayuda.

Se desperdicia más tiempo en tratar de salvar un mal código del que se debería. Una vez que algo se vuelve un sumidero de recursos, necesita ser descartado. Rápidamente

No es que debas tirar todo lo que has escrito, nombrado y formateado tan fácilmente. La reacción de mi jefe fue extrema, pero me obligó a repensar el código en el segundo (u ocasionalmente tercer) intento. Aún así, la mejor estrategia para arreglar un mal código es cambiándolo de tal modo que el código sea refactorizado sin misericordia, cambiado de lugar o borrado.

El código debería ser simple. Debería ser un mínimo de variables, funciones, declaraciones y otras necesidades sintácticas del lenguaje. Las líneas, variables adicionales… nada de adicional, en realidad, eso debería ser purgado. Removido inmediatamente. Lo que está ahí, lo que queda, sólo debería ser lo suficiente para realizar el trabajo, completar el algoritmo o realizar los cálculos. Cualquier otra cosa y todo lo demás es sólo ruido adicional no deseado, introducido accidentalmente y que obscurece el flujo. Ocultando las cosas importantes.

Por supuesto, si no lo logra, entonces sólo borra todo y escríbelo una vez más. Iniciar el diseño desde lo recordado a menudo puede ayudar a cortar una gran cantidad de desorden innecesario.

Leer contribución original

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *