El cicle de desenvolupament
Escrit per Aaloy a 11 de July , 2010 a les 10:51 a.m.
L'altra dia vaig tenir l'ocasió de parlar amb un responsable informàtic d'una empresa gran. Una conversa llarga però entretinguda, afegiria.
El cas és que en un moment de la conversa l'home va venir a dir que abans es pensava molt més a l'hora de programar, que com que el temps de CPU era molt més car, llavors els programadors s'havien de pensar molt el que feien, que els programes tenien menys errors d'entrada.
La veritat és que no tenc dades estadístiques de la quantitat d'errors que hi podria haver, però també és veritat és que pareix que la taxa d'errors per línia de codi és una constant que s'ha mantingut pràcticament constant al llarg del temps. De fet és una de les raons per elegir llenguatges d'alt nivell respecte a llenguatges de baix nivell a l'hora de programar, ja que hem d'escriure menys línies de codi, llavors la quantitat total d'errors introduït també serà menor.
Així doncs, tenir molt repensant els programes a l'hora de picar-los no feia que tinguessin menys errors, sinó que sintàcticament eren correctes. Però la gràcia dels analitzadors de codi actuals, dels compiladors, és que permeten caçar tots aquests errors de manera ràpida.
És a dir, actualment es pot teclejar el codi directament a l'editor, compilar-lo (o no si feis servir un llenguatge interpretat) i provar-lo en un cicle de realimentació ràpid. El que estam fent és aprofitar la tecnologia al nostre favor, deixar que l'ordinador caci els errors de sintaxi i ens avisi dels errors més obvis. En definitiva el que estam fent és aprofitar-nos de que l'hora de CPU té un preu al voltant de zero, superant en molt el cost de l'hora de programador.
Els programes s'han fet més complexos, amb més línies de codi, on cada vegada hi ha més capes i més distribució, i això fa que les tècniques de programació i testeig també hagin evolucionat. Encara tenim que picar el codi, però podem fer-ho directament a l'ordinador, no hem d'esperar per saber si el codi té errors de sintaxi o no, i això ens fa més productius i evita temps d'espera. Això no vol dir que els programador siguin ara més descuidats en el seu codi ara que abans, sinó que senzillament poden dedicar-se més ara a la funcionalitat i no tant a tenir que validar manualment que tota la sintaxi del programa sigui correcta.
Personalment no he tingut que tractar amb mainframes i amb el tipus de programació i feina de la que parlava el meu interlocutor, però tenc clar que en informàtica com en altres coses el temps passat no era millor. Potser ara el veim amb nostàlgia, però la realitat és que ara comptam amb una gran quantitat d'eines i ajudes a la programació que fan que el programador pugui destacar per la seva creativitat i coneixements i no per la seva habilitat mecanogràfica.
Traducciones/Translations by apertium
1 comentari, 0 trackbacks (URL) , Tags: Informàtica Gestió de projectes
Comentaris
1 Comentari de paurullan a les 01:07 del Sunday 11 Jul de 2010
(el meu comentari s'ha d'agafar amb un poc de sal perquè em falta experiència «al món real»)
Després d'haver acabat la pràctica de compiladors amb el llenguatge «més heavy ever» (Ada) sóc del parer que el tipat dur i el verbose sols són productius _SI_ el llenguatge+compilador+IDE t'ajuden. I me sap greu dir-ho així però crec que això sols es compleix al Haskell, on els tipus s'infereixen i deriven, proporcionant tot el «boilerplate» necessari alhora que es resolen la gran majoria de problemes.
Per tota la resta tipus de pato i llenguatges dinàmics.
El motiu és molt semblant al que exposes: els vertaders errors d'un programa no són els de sintaxi sinó els conceptuals i algorítmics. Deixar-se un punt i coma o oblidar-se escriure el «end» és trivial d'arreglar i a la llarga el programador minimitza aquestes falles. La facilitat de resoldre el problema tindrà una forta relació amb la flexibilitat del llenguatge com a eina. Significa un impacte molt major damunt la productivitat i verificació haver de muntar una complexe estructura per accedir a les nostres dades que tirar-ho tot dins un diccionari de Python.
