No me digas que el programa está haciendo algo raro. Es tu programa. No se ha escrito solo. Únicamente hace lo que le has pedido que haga. Que no siempre es lo que pretendes que haga. Tampoco me digas que no sabes lo que está pasando en un momento dado. Es tu obligación saber depurar tu propio código. De hecho, deberías ejecutarlo con el depurador al menos una vez. Es tu código. No es dificil de leer. Si sabes programar.
No te obsesiones por blindar tu trabajo. Es tentador tener lo que se conoce técnicamente como “seguridad laboral”, ser el dueño de ese trozo de código que nadie entiende. El problema es que, colega, siempre habrá gente que lo entienda. O que lo consiga duplicar sin tener que suplicar audiencia para que arregles lo que sabes que falla. La seguridad laboral a través de la oscuridad es algo muy español pero tiende a desaparecer.
Responsabilízate de tu código. Del bueno y del malo. Lo de “esto lo ha hecho otro” cuela las tres primeras veces. Al igual que se puede determinar quien ha escrito un texto por los trazos, se puede identificar a un programador por su estilo. Sobre todo si está lleno de errores de diseño. Incluso siendo código limpio es fácil identificar, en una empresa, el estilo personal de cada programador.
No pienses en que esa automatización la dejas mejor para el que venga después. No la haces únicamente para facilitar tu trabajo. Piensa de manera egoista: lo haces para aprender algo nuevo. Oblígate a aprender cosas nuevas. No a diario, pero sí cada poco. Tampoco interpretes esto como un “vamos a cambiar el framework que usamos por este otro que está de moda”. Haz que tu código evolucione sin romperlo. Es posible.
El refactoring no es un equipo de la liga inglesa. Es otra herramienta en tu arsenal de herramientas intangibles. Úsalo con prudencia y criterio. Aprende a pensar en las implicaciones de tus cambios y a hacerlos sin temor al fin de la civilización. Y, cuando rompas algo, hazte responsable.