El Blog de Trespams

En aquest article intentaré definir què es la mantenibilitat del programari, com es classifica i miraré d'analitzar l'impacte que pot tenir un llenguatge de programació tipat o no en relació a la mantenibilitat. És la precuela de l'apunt Mantenibilitat en llenguatges tipats i no tipats d'aquest mateix blog, on intentaré definir què és el manteniment i recolzar amb xifres l'impacte que pot tenir utilitzar un llenguatge tipat o no.

Definició de manteniment: La modificació d'un producte de programari després de la seva posada en producció a fi i efecte de corregir defectes, augmentar-ne el rendiment u altres atributs o adaptar-lo a les modificacions de l'entorn.

El manteniment de programari es classifica en quatre categories:

• Manteniment correctiu. És a dir, la correcció d'errors (bugs) de tota la vida.
• Manteniment adaptatiu. No hi ha canvi de funcionalitat però ara s'ha de fer feina amb altres condicions. Per exemple un canvi a l'IVA o a un nou plà contable.
• Manteniment perfectiu o de perfeccionament. Destinat a afegir alguna característica nova al sistema, per tal de fer-ho millor.
• Manteniment preventiu: Fet de manera interna per tal de millorar el sistema sense afectar-ne a les característiques externes.

Podem agrupar el manteniment adaptatiu i el perfectiu com a millores al sistema, considerades aquestes com quelcom que ha demanat l'usuari i que no estava previst a les especificacions del programa quan es va posar en producció.

Dins el mateniment correctiu podem trobar d'acord amb William E. Lewis les següents categories:

• Errors de disseny: el sistema no s'adapta al que l'usuari havia demanant.
• Errors de lògica: parts del programa no testejades, condicions no previstes, etc)
• Errors de codificació. Errors que resulten de una mala implementació de la lógica o per una mala escriptura del codi.
• Errors de càlcul. Resultat de mesclar tipus incompatibles o fer els càlculs agafant dades incorrectes.
• Errors d'entrada/sortida. Errors de forma, protocols d'entrada i sortida incorrectes, etc.
• Errors d'interfície: nombre de paràmetres incorrectes per exemple (pensen en interfícies XML sense anar més enfora).
• Errors en la definició de dades: Fallades d'inicialització de dades, mal us d'indexs,...

D'aquests tipus d'erros, fitxem-nos que el compilador tipat sols caçarà alguns dels errors de codificació i alguns dels errors d'interfície. Els errors de càlcul no es refereixen sols a mesclar tipus, sinó també a agafar les dades que no toquen o fer operacions incorrectes. Fins i tot en el cas de la mescla de tipus, un llenguatge tipat tampoc és cap garantia, ja que la majoria tenen maneres de passar dades d'un tipus a un altre, i qualsevol programador que codifiqui per coincidència pot acabar aplicant el typecast necessari per a que el compilador no es queixi.

El més important de tota questa classificació d'errors és notar que la gran majoria són errors que no depenen de si el nostre llenguatge de programació es tipat o no, es poden donar en qualsevol llenguatge.

Però anem un poc més enfora. Resulta que en terme mig un 60% del cost d'un programa és cost de manteniment (els intervals van entre un 40 i un 80%). De totes les fonts d'errors que hem enumerat, resulta que la correcció d'errors representa sols un 17% del total del cost de manteniment. Un 60% es dedica a tasques de millora del sistema (el que hem anomenat manteniment perfectiu), representant el manteniment adaptatiu un 18% del cost. El 5% que queda es dedica al manteniment preventiu, és a dir, tasques de mantenimient internes i sovint lligades a la refactorització del codi.

Veim doncs que el cost de manteniment no està en la correcció d'errors, sinó en el manteniment evolutiu i en el manteniment perfectiu. És a dir, el nombre de millores que ens demanaran els usuaris del nostre programa (externs o interns en el manteniment preventiu) representen el 83% del cost de manteniment total.

Perquè aquest cost? Doncs perquè un canvi representa que s'ha de definir i entendre el canvi, avaluar-ne l'impacte (15%), mirar la documentació (si existeix) del programa (5%), seguir el programa per veure que fa el que se suposa que fa (25%), fer el canvi (20%), testejar i depurar (30%) i finalment actualitzar la documentació (5%). És a dir, quan s'afegeix una nova característica a un programa en producció el cost emnor és el de fer el de codificar, el gruix del cost se'n va en entendre el problema (45%) i en la depuració (30%), és a dir, un 75% en tasques que no són directament de codificació i per tant on el tipat del llenguatge poc hi té a veure.

Llavors quan ens demanam què fa un programa mantenible, ens estam demanam com podem fer que el temps necessari per entendre el programa sigui el mínim possible. Reduint el temps d'entendre el que fa el programa reduïm el cost de manteniment i per tant fem el programa més mantenible.

I entendre el codi implica llegir el codi, poder seguir-lo. Es a dir, el codi per a ser mantenible ha de ser escrit pensant en les persones, recordau, no hem d'escriure codi per a que ho executin les màquines sinó per a que ho llegeixin les persones. Un codi millor estructurat és més fàcil de llegir, variables ben posades, codi que no es repeteix, etc. Una vegada més el tipat del llenguatge no hi té res a veure, de fet la literatura ens parla que les inspeccions de codi disminueixen fins en un factor 10 el cost de manteniment, per què? Doncs perquè fan que els programes siguin llegibles, un codi mal d'inspeccionar no passa i per tant no es mantindrà.

En conclusió, la mantenibilitat no és la dóna el tipat del llenguatge, ens la dóna la claretat i l'expressivitat del mateix i la nostra pròpia metodologia de programació i bones pràctiques.

Referències:

• http://www.research.umbc.edu/~cseaman/ifsm698/lect0903.ppt
• Software testing and continuos quality improvement. William E. Lewis (p.285)
• http://en.wikipedia.org/wiki/Software_maintenance
• Facts and Falacies on software engineering. Robert L Glass (p.115)
• Peer Revies in Sofware. Karl E. Wiegers (p. 6)