El Blog de Trespams

Llegir codi és una de les millors maneres que hi ha d'aprendre a programar. Veus com la gent fa certes coses i pots començar per copiar-les per passar a demanar-te per què es fa d'aquella manera i finalment mirar de millorar-ho.

M'agrada llegir codi, però també es veritat que quan he de llegir codi que he comanat per un projecte i veig segons quines coses em pos un poc de mala llet, no és res personal, crec que és un defecte del meu caràcter, d'aquest xic de perfeccionisme que tots duim a dintre.

Primer de tot s'ha de tenir en compte que escriure codi és molt personal, no hi ha una manera única de fer una mateixa cosa i els codi es converteix en una extensió de la personalitat de l'autor i de la seva manera de fer les coses.

Per això convé sempre ser caut a l'hora de valorar el codi d'altres. Sempre hi ha una manera millor de fer-ho, sempre hi ha una altra manera de fer-ho, la nostra manera.

Pel que es veu afectat per la revisió, les coses no són menys fàcils, sovint pareix que el codi és com un fill nostre, i que una vegada escrit, com nin malcriat, se li han de perdonar tots els defectes.

Personalment quan veig alguna cosa que no m'agrada ho dic. Al llarg del temps he desenvolupat una certa habilitat per veure quan un codi fa mala olor, i segons el que he dormit el dia anterior puc ser més o menys políticament correcte.

De tipus d'errors n'hi ha molts, i jo en tenc la meva classificació particular (ja sabeu, el món es divideix en dos tipus de persones, aquells que fan llistes i els que no).

• Errors puntuals. Són la típica cagada que li ha passat a tothom. Qui digui que a ell no li ha passat és perquè no ha programat prou. Són errors que poden ser greus en termes de les conseqüències, però que s'han de prendre com això, com part de la feina. Són errors per aprendre a no tornar-los fer.
• Errors de "però mira que guai que sóc". Sovint no són errors, sinó trossos de codi dels quals el creador se'n va sentir molt orgullós però que són mals de depurar i que es poden reescriure fàcilment per fer el mateix de manera més clara i amb menys línies de codi. Potser el programa funciona, però no és correcte, li falta qualitat i a la llarga representa un problema en el mateniment correctiu i evolutiu. Sovint aquest tipus d'error està molt relacionat en el concepte de reinventar la roda i amb el síndrome NIH (Not Invented Here). S'han de corregir tot d'una que es presenten i mirar de conscienciar a la gent per a que no es repetesquin.
• Errors de seguiment dels estàndards de codificació. No tenen excessiva importància, però dificulten la lectura del codi i l'evolució del programari. Els estàndards de codificació i localització del codi serveixen per a que qualsevol persona que no està familiaritzada amb el codi, pugui llegir-ho sense dificutat i saber on ha d'anar a trobar les coses. Particularment me resulta molt més fàcil llegir un codi amb noms de variables ben posats, amb els comentaris allà o toca. Llegir codi requereix molt atenció i esforç i tenir que bregar a més amb distintes maneres de codificar no ho fa més fàcil.
• Errors d'arquitectura: Cohesió i acoblament. Cohesió bona, acoblament innecessari dolent. I m'estic referint a l'acoblament de codi, a casa que cada un faci el que pugui. Tenir tot el relacionat a un mateix lloc (llibreria, paquet, arxiu, ...) i no separat en mil i un trocets que fan mil i una coses sols per peresa de no crear un nou arxiu o estructurar el programa, d'això se'n diu cohesió. L'acoblament és la dependència que hi ha entre mòduls distints i que fa que sovint aquests no es puguin reutilitzar de manera independent. L'acoblament és necessari per a construir programes, però ha de tenir un perquè. Cohesió i acoblament són conceptes que van molt lligats i codi amb poca cohesió sols presentar molt acoblament.
• Errors de concepte. Són els errors que es cometen perquè un no s'ha aturat a pensar en el que està fent i bé per desídia o bé per malentesos crea codi que no té sentit. És el típic error de permetre fer reserves per dies passats i coses semblants. Són errors que em preocupen, perquè vol dir que s'està programant sense reflexionar i això és molt perillós. La programació no és sols picar codi, és picar codi amb una finalitat i aquesta no sols ha de ser la de cobrar a final de mes, sinó que ha de servir al nostre client. Quan són errors per desconeixement del negoci s'ha d'insistir en que se demani tot el que no es coneix, quan són errors per no pensar en el que se està fent convé insistir en conscienciar a la gent del tipus de feina que fa.
• Errors de code monkey. Errors de copiar i aferrar, funcioni el codi o no. S'ha copiat cinquanta vegades el mateix sense aturar-se a pensar si convendria fer-ho d'una altra manera. Són errors que al igual que l'anterior m'empipen especialment, ja que per defecte vull pensar que la gent fe la seva feina el millor que sap. Em preocupen perquè sovint vol dir que s'ha escrit el codi a tot màquina per cobrir l'expedient i que les hores s'han dedicat a altres coses. Estirada d'orelles.

No passa res per cometre errors, el que no és admissible es no aprendre dels errors, o preferir reinventar la roda per no aturar-se a pensar en maneres alternatives. Quan el problema es molt bàsic hem de pensar que l'error sols estar en la nostra banda, que la funcionalitat existeix però no l'hem vista i hem de llegir més. L'alternativa: codificar-ho nosaltres mateixos, o començar a pensar que l'error és de la pila TCP del nostre ordinador i posar-se a davallar-se el codi per anar a fer la depuració no és la primera opció que un ha de pensar. Primer s'han de provar les coses més habituals, ja que el el 99,9% de casos l'error serà nostre, del nostre codi.

Llegir el codi, el nostre i els d'altres, ens ajuda a reflexionar sobre allò que podem millorar i a evitar els errors més comuns. Recordem que com a programadors no escrivim codi per a ser executats per les màquines, sinó per a ser llegits per altres persones.