Desarrollo de software: Programar pensando en futuros mantenimientos

Hace unas semanas, un amigo me comentaba que le sorprendía como mucha gente codificaba como si nunca más se tuviera que volver a revisar o mantener el código que estaba programando, lo que provocaba la entrega de código no comentado, difícilmente legible o comprensible y lo que es peor, con mucha deuda técnica que hacía que el mantenimiento del mismo fuera a la vez complejo y costoso.

El programador tiene su culpa en todo esto y lo bien o mal que codifique será función de su experiencia, capacidad técnica y sobre todo de su implicación en el proyecto y de la conciencia de que el ciclo de vida del software no termina en la entrega, sino que después le queda un largo período de vida lleno de mantenimientos correctivos y evolutivos.

No obstante, por encima del programador, hay otros responsables que deben de dejar claro que la calidad del software para la empresa, no es una actividad secundario o la guinda del pastel, sino que es algo que debe ser inherente a los desarrollos de la organización, de manera que la calidad esté plénamente integrada en los procesos. Estos responsables son tanto los analistas funcionales, arquitectos y jefes de proyecto que deben supervisar y velar por el cumplimiento de unos estándares de calidad definidos y corregir cualquier actitud de los programadores y analistas programadores cuyo trabajo no respete esos estándares y si se persiste en dicha actitud tomar las medidas oportunas.

Se dice que la calidad del software va en contra de los costes del proyecto para el proveedor de los servicios de desarrollo de software. Yo no estoy de acuerdo, lo que va en contra de los costes es precisamente codificar sin tenerlo en cuenta, ya que tarde o temprano esa deuda técnica repercute contra el proveedor, ya sea durante el mismo desarrollo cuando se tengan que arreglar módulos de la aplicación con errores, durante la fase de garantía o durante la entrega del producto y puesta en marcha, donde esa falta de calidad traerá consigo un peor funcionamiento de la aplicación, un mantenimiento más costoso y una pérdida de confianza del cliente respecto al proveedor. Al final se tendrán flecos que no se terminan de cerrar y que son muchos más costosos que si se hubiera invertido el tiempo necesario para entregar un producto de mayor calidad o si se tuviera técnicos más cualificados para realizar dicho trabajo.

1 comentario

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: