El artículo publicado ayer en el que comentaba los beneficios de la refactorización, lo contextualicé con una cita de Ron Jeffries en la que venía a decir que una aplicación bien diseñada y programada de base podría convertirse en un elemento complicado de mantener si no se revisaba con la frecuencia necesaria el código, sobre todo en contextos iterativos, evolutivos o de mantenimiento del sistema.
Y es que queramos o no, si no se hace esta tarea el programa se convierte en un conjunto de parches cada uno de ellos con el sello de su programador y cada vez resulta más costoso de mantener a la vez de que se incrementarán las posibilidades de efectos colaterales.
Jeff Atwood realiza la siguiente cita que complementa perfectamente a la de Jeffries: “Si no te paras de vez en cuando (frecuentemente, en realidad) en revisar y limpiar el código que ya has escrito, terminará convirtiéndose en una gran y descuidada bola de código”.
No es necesario poner ejemplos sobre esto porque la mayoría de vosotros habréis tenido la oportunidad de padecer y sentir las consecuencias de código de baja calidad y/o parcheado. Pese a esto y como ya comenté en el artículo de ayer no se le presta en la mayoría de los casos la atención que se merece a la refactorización, algo que resulta todavía más sangrante cuando el producto que desarrollas es para tu organización ya sea de uso interno o para comercializarlo ya que en estos casos no se tiene la excusa de que el cliente no valora este tipo de esfuerzos.
