Regla N°3 de la Ingeniería de Software: Se va a mantener

El tiempo que vas a estar creando software nuevo, es incomparablemente menor al tiempo que vas a estar manteniéndolo.

Gran parte nuestros esfuerzos de desarrollo van a estar enfocados en el mantenimiento de código que bien puede ser código ajeno o código de otras personas.

El peor escenario donde hay que mantener un software, es donde el código se ha ajustado durante años al gusto, y costumbres particulares de un analista-programador, que no ha seguido ninguna regla en concreto para creación del producto. Generalmente estos sistemas se vuelven contra su creador, convirtiéndose lo que debiera ser un aparente software sencillo, en vacaciones pasadas en la oficina en lugar de en la playa. La situación solo puede acabar de varias formas

• Rehacer el sistema desde cero (con un nuevo programador).
• No actualizar nunca el sistema, y por lo tanto limitar las posibilidades del negocio para el cual se aplica (hasta que se hace demasiado evidente que el sistema ya no sirve, y se cae en el primer punto).
• Explotar al programador (horas extras, falta de vacaciones), hasta que este renuncie, y se vuelve a caer en el punto número uno.

A veces noto a ciertos programadores querer hacerse imprescindible para la continuidad de un sistema, mi consejo es que no caigan en ese juego. Al final se hacen esclavos del sistema, en lugar de hacer que el sistema les reporte beneficios. Lo ideal es que a un empleado le quieran por lo que es capaz de hacer en el futuro, y no que dependan de él por lo que ya ha hecho, debido a que generalmente las empresas buscaran cortar esa dependencia lo antes posible y de la manera más beneficiosa para la ellas y no para el empleado. Diferente es el caso en el que un empleado es requerido por sus conocimientos y capacidades ya que es una inversión a largo plazo. Resumiendo la idea seria "ser un buen programador tiene beneficios, aunque a veces no son tan visibles".

Volviendo a la idea del mantenimiento de software, nuevamente es una idea que debemos asumir como cierta, y para la cual debemos estar preparados, algunos consejos son:

• No programes de forma artística: la programación no es un arte, eso no quiere decir que no sea creativa, ni importante, ni interesante, sino que generalmente es una creación "objetiva" a la que deben llegar un equipo de desarrollo en conjunto. Si lo vemos como un arte, lo veremos como algo muy personal (y subjetivo), que acabara siendo difícil de mantener.
• Sigue estándares: antes de comenzar un desarrollo, es importante tener claro los estándares y que sean conocidos (y afectados) por todo el equipo de desarrolladores.
• Haz un plan de manteniendo de un software, mas cuando este no tiene estándares o lógica aparente: Si te toca un software de este tipo, planea como vas a hacer las cosas a partir de ahora, donde podrás el acceso a datos, donde la seguridad, servicios globales, etc.
• Intenta comprender el software desde el punto de vista de las personas que lo hicieron: Muchos proyectos reflejan el cansancio y la frustración desde las horas extras, al momento de su construcción. Para comprender el código piensa desde esa perspectiva, y ve donde esta los huecos de "lógica" y los posibles errores cometidos.
• Haz refactoring siempre que puedas: El refactoring no es trabajar doble, es trabajar ahora para descansar mañana (y pasado mañana). Nunca subestimes el refactoring, no tengas miedo de mover algo que no entiendes, al contrario, buscar entender lo que estas moviendo (apóyate en el punto anterior).
• Siempre utiliza control de versiones (el que sea, GIT, SVN,...). No hay proyecto demasiado pequeño para usar control de versiones, no importa que sea un proyecto individual o en equipo, siempre úsalo.

Finalizando, recuerda que el valor del software, está en su capacidad de ser mantenibles, dicho de otra manera, si un software no se puede mantener, perderá su valor muy rápido a través del tiempo, ya sean meses o escasos años (uno o dos). Las necesidades profesionales o empresariales del mundo cambian demasiado rápido, evolucionan siempre en nuevas necesidades, y cualquier necesidad requerirá de un software que la gestione. Esforzarse en crear un software mantenibles desde sus raíces, es una inversión en recursos y tiempo, que dará beneficios en un corto tiempo en la vida del sistema donde esta implementado.