El teu projecte funciona, està provat i viu en un repositori endreçat: Implementació i proves va tancar la checklist d'«acabat». Queda una part que qui comença sol considerar accessòria i que a la pràctica decideix quant val la teva feina per als altres: saber-lo ensenyar. Un projecte que ningú no sap instal·lar, que no s'entén sense tu al costat o les decisions del qual no saps justificar és, a efectes pràctics, un projecte que no existeix. Aquesta lliçó converteix la teva carpeta de codi en alguna cosa presentable: un repositori net, un README que fa la feina per tu, una demostració de cinc minuts que no depèn de la sort, i les respostes preparades per a les preguntes que et faran —inclosa la més incòmoda, la de les limitacions—.

1. Deixar el repositori presentable
2. El README com a carta de presentació
3. La demostració de cinc minuts
4. Explicar decisions tècniques
5. Parlar de les limitacions sense restar-te valor
6. Preguntes típiques i com respondre-les
7. Rebre crítica i convertir-la en tasques
8. Publicar el projecte
9. Autoavaluació final i pla de millora
10. Errors comuns i consells
11. Exercicis
12. Conclusió

Qui miri el teu projecte veurà primer el repositori, no el programa. I la primera impressió es juga en trenta segons: si hi ha un README.md que explica què és això i hi ha fitxers amb noms raonables, continua llegint; si veu una carpeta amb prova2.py, dades_final_final.json i cap text, tanca la pestanya.

Recorre aquesta checklist sencera abans d'ensenyar-lo a ningú, reprenent Documentació i comentaris i Control de versions:

Sobre el punt 4, un advertiment seriós: esborrar un fitxer amb una contrasenya en un commit posterior no l'elimina de l'historial; continua allà i qualsevol el pot recuperar. Si t'ha passat, la resposta correcta no és maquillar-ho sinó invalidar aquella credencial i, si el repositori encara no és públic, refer-lo des de zero. En un projecte d'aquest curs el normal és que no hi hagi credencials, però sí dades personals reals: les teves, al fitxer de despeses o a l'agenda de contactes. Aquestes no es pugen.

I el tancament de la feina, reprenent el versionatge semàntic de 08-01:

El README és el document més rendible del teu projecte: s'escriu en una hora i és el que llegirà el 100 % dels qui el mirin. Aquesta és l'estructura, en ordre, amb el perquè de cada secció:

Un extracte comentat del README de LesMevesDespeses:

Els dos últims apartats porten blocs de codi amb les ordres literals, que són aquestes:

Fixa't en tres decisions. La descripció esmenta el problema abans que la solució: qui llegeix entén per a què serveix abans de saber com funciona. Les característiques són en infinitiu o substantiu, no en «podràs fer...». I la instal·lació són ordres copiables en ordre, sense prosa entremig: qui avalua el teu projecte les vol enganxar i que funcionin.

La part que més convenç, i la que gairebé ningú no inclou, és una demostració en text d'una sessió real. Val més que qualsevol descripció, perquè ensenya el programa funcionant sense instal·lar-lo:

Com es fa: executa el programa amb les teves dades d'exemple, copia la sortida literal del terminal i enganxa-la en un bloc ```text. Res de recrear-la a mà —es nota, i a més sol quedar desalineada—. Si prefereixes captures de pantalla, puja-les a una carpeta docs/ del repositori i enllaça-les amb ![Resum mensual](docs/resum.png); però el text té un avantatge: es cerca, es copia i no es trenca.

Tard o d'hora hauràs d'ensenyar el projecte en directe: a classe, en una entrevista o a algú que et va preguntar què estaves fent. Cinc minuts semblen pocs i són molts si no portes guió, perquè l'impuls natural és començar pel codi i perdre's en detalls.

Aquest és el guió, i el repartiment de temps importa tant com el contingut:

Sobre el bloc 3, que és el que es pot torçar: prepara les dades per endavant. Tingues un dades_demo.json amb quinze o vint moviments repartits en dos mesos, copiat al lloc just abans de començar. No facis mai una demostració amb la base buida: registrar cinc despeses en directe consumeix els teus dos minuts i no ensenya res. I assaja la seqüència exacta de tecles almenys dues vegades; l'objectiu és que puguis parlar mentre les teclejes, no llegir la pantalla.

I si alguna cosa falla durant la demostració? Falla, tard o d'hora. El que es jutja no és la fallada, és la reacció:

• No l'amaguis ni la minimitzis. «Aquí hi ha una fallada, no havia provat aquesta combinació» és una resposta professional. Fer veure que no ha passat res, no.
• No et posis a depurar en directe. Consumeix el temps de tothom i rarament surt bé. Anota-ho i continua.
• Tingues un pla B: una captura o una sessió gravada en text al README amb la qual continuar explicant.
• Converteix la fallada en informació. «És un cas que no és al meu guió de proves; l'afegeixo» demostra que tens mètode, que és justament el que s'està avaluant.

Tot el que hi ha al teu codi és el resultat d'una decisió, i la pregunta «per què ho vas fer així?» no és un atac: és la manera estàndard d'esbrinar si entens el que has fet. Una bona resposta té tres parts: què vas triar, quina alternativa vas descartar i amb quin criteri. Tres exemples reals sobre LesMevesDespeses:

«Per què una classe Moviment i no un diccionari?» Vaig començar amb diccionaris, que és el més ràpid. El problema va aparèixer amb la validació: cada lloc que creava un moviment havia de comprovar que la quantitat no fos zero i que la categoria existís, i me'n vaig oblidar en un. Amb una classe, la validació és a __post_init__ i no pot existir un moviment invàlid al programa. A més, __str__ em dóna la línia de taula ja formatada. Si només fos un contenidor de dades sense regles, hauria deixat el diccionari.

«Per què JSON i no CSV, si són registres plans?» Pels tipus. En CSV tot torna com a cadena i hauria de reconvertir imports i dates en llegir, amb el risc de fallar en silenci. JSON conserva els números i em deixa afegir camps opcionals sense trencar els fitxers antics, per a la qual cosa a més deso un número de versió. CSV sí que el faig servir, però només com a exportació d'un sentit, que és on té avantatge: obrir el mes al full de càlcul.

«Per què vas separar la interfície de la lògica, si és un programa petit?» Sobretot per poder provar-lo. Els càlculs del resum són a Quadern, que no imprimeix res, així que els puc verificar amb pytest en centèsimes de segon; si estiguessin barrejats amb els print hauria de simular la pantalla per provar-los. L'efecte secundari és que canviar el format d'una pantalla no pot trencar un càlcul, perquè viuen en fitxers diferents.

El patró es veu en els tres: context, alternativa, criteri, conseqüència. I una cosa igual d'important: si una decisió la vas prendre sense pensar, digues-ho. «Ho vaig fer així perquè era el que sabia fer, i ara que ho miro hauria estat millor...» és una resposta que suma, perquè demostra criteri adquirit. La resposta que resta és inventar-se una justificació que no sostens a la repregunta.

Tot projecte té mancances, i el teu, que és el primer, en té bastants. La diferència entre semblar un principiant que no en sap i un professional que comença és tota en com s'expliquen. El patró té tres temps:

«Ho sé → ho vaig deixar fora expressament → així ho faria»

Aplicat:

Les tres versions de la dreta comparteixen una cosa: converteixen una mancança en una decisió i proposen el camí. Això només és possible si de debò vas prendre la decisió, i per això el calaix Won't de Definició del projecte era tan important: ara és el teu guió.

Dues coses que no has de fer mai: disculpar-te en bucle («perdó, sé que està molt mal fet, és que soc principiant»), que convida a mirar el projecte amb desconfiança i no aporta informació; i inventar limitacions que no tens per semblar humil. Digues el que és.

Aquestes preguntes surten gairebé sempre. Prepara-les per escrit; respondre bé una pregunta previsible és de les coses que més diferencien una presentació d'una altra:

Sobre la de la IA: la resposta honesta sempre és millor. «La vaig fer servir per entendre un TypeError que no sabia llegir i perquè em revisés el magatzem.py; el disseny i el codi són meus» és una resposta professional i verificable —perquè si el codi és teu, el sabràs explicar—.

Quan ensenyes el teu projecte reps comentaris, i la reacció instintiva és defensar-se. És un error: la crítica d'algú que s'ha molestat a mirar el teu codi és de les coses més valuoses que rebràs de franc. El procediment:

1. Escolta sencera l'observació sense interrompre i sense justificar-te encara.
2. Anota-la literal. No la interpretis en el moment; ja la interpretaràs en fred.
3. Pregunta si no l'entens. «A què et refereixes amb que el mòdul fa massa coses?» és una pregunta legítima i demostra interès.
4. Agraeix-ho. Encara que no hi estiguis d'acord. El cost d'escoltar és zero.
5. En fred, classifica-la en una d'aquestes quatre caixes.

La quarta caixa és on més es pateix si no la tens clara: hi ha comentaris que descriuen un altre projecte, no el teu. I la primera és la més valuosa de totes: qui troba una fallada al teu programa t'està fent un favor, encara que no ho sembli en aquell moment. Converteix cada comentari de les dues primeres caixes en una línia de la teva llista de tasques, amb la seva prioritat; d'això surt el pla de millora de l'apartat 9.

Un projecte al teu disc dur no serveix a ningú, començant per tu. Publicar-lo costa vint minuts:

Després, dedica una estona a la pàgina del repositori, que és el teu aparador:

• Descripció curta (el camp About): una frase amb el que fa i en què està escrit. «Gestor de despeses personals per línia d'ordres en Python, amb persistència en JSON i proves amb pytest».
• Temes (topics): python, cli, json, pytest, learning-project. Ajuden que aparegui a les cerques.
• README ben renderitzat: mira-te'l a GitHub, no només a l'editor. Comprova que les taules es veuen i que els blocs de codi tenen el seu llenguatge.
• Llicència: si vols que altres el facin servir, afegeix-hi una MIT; sense llicència, tècnicament ningú no el pot reutilitzar.

Sobre el portafolis: dos o tres projectes acabats, explicats i amb historial de commits valen més que vint repositoris a mitges. Qui avalua mira si el projecte està acabat, si el README explica el perquè, si hi ha proves i si els commits expliquen una història coherent. Un projecte petit i complet comunica «aquesta persona acaba les coses», que és exactament el senyal que es busca.

I una pràctica que ensenya més del que sembla: mirar projectes aliens. Busca a GitHub una aplicació de línia d'ordres en Python amb poques estrelles —els projectes enormes són il·legibles al principi— i examina, en aquest ordre: el README (entens què fa en un minut?), l'estructura de fitxers (reconeixes les capes?), un mòdul qualsevol (com anomenen les funcions?), els tests (què proven?) i l'historial (com escriuen els missatges?). Mitja hora fent això et dóna referències que cap tutorial no et dóna.

Ha arribat el moment de fer servir la rúbrica que vas escriure a 09-01, quan encara no sabies com sortiria el projecte. Omple-la amb honestedat —l'única persona a qui enganyaries és a tu— i multiplica cada puntuació pel seu pes:

La columna de la dreta és la que fa útil l'exercici: obliga a justificar la nota amb una evidència, no amb una impressió. Un 3 en proves significa poder dir «onze proves que cobreixen model, agregació i cicle desar/carregar», no «em sembla que estan bé».

Amb la rúbrica omplerta, el pla de millora surt sol: ordena per pes descendent els criteris amb nota més baixa. Exemple de LesMevesDespeses, que va sortir amb 2,85 de mitjana:

Set hores de feina que pugen la mitjana a un 3,4. I observa l'ordre: primer el que és barat i arregla una nota baixa, després el que és car. Afegir una funció nova és el més divertit i gairebé mai és el que més millora el projecte.

• Ensenyar el codi abans que el problema. Ningú no pot valorar una solució si no sap quin problema resol. Trenta segons de context primer, sempre.
• README de tres línies. «Projecte final del curs de Python» no diu res. Si només tens una hora per polir el projecte, inverteix-la sencera aquí: és el que més multiplica.
• Demostració sense dades preparades. Registrar registres en directe consumeix el temps i avorreix. Tingues un fitxer de demostració llest i assajat.
• Disculpar-se tota l'estona. Rebaixa el valor del que has fet i no aporta informació. Fes servir el patró «ho sé, va ser expressament, així ho faria».
• Defensar-se de la crítica. Escoltar és gratis i decidir és cosa teva. Anota, agraeix, classifica en fred.
• Pujar dades personals. Revisa el repositori abans de fer-lo públic: el fitxer de dades reals no es puja, i esborrar-lo després no el treu de l'historial.
• Consell: explica el projecte en veu alta a algú que no programi. Si aconsegueixes que entengui què fa i per què, tens la presentació resolta.
• Consell: escriu el teu guió de cinc minuts i cronometra'l. Gairebé sempre en són vuit la primera vegada, i el que sobra és el bloc tècnic.

Els últims passos reals del teu projecte. En acabar-los, està lliurat.

Recorre la checklist de l'apartat 1 punt per punt i arregla el que falli, inclosa la comprovació de clonar en una carpeta nova. Després escriu el teu README.md complet amb les deu seccions de l'apartat 2, incloent-hi una demostració en text d'una sessió real copiada literalment del teu terminal. Crea l'etiqueta v1.0 i puja-la.

Escriu el teu guió de cinc minuts seguint la taula de l'apartat 3, amb el temps assignat a cada bloc i les dades de demostració preparades en un fitxer a part. Assaja'l cronometrat dues vegades. Després redacta per escrit tres decisions tècniques del teu projecte amb el patró context-alternativa-criteri-conseqüència, i tres limitacions amb el patró «ho sé, ho vaig deixar fora expressament, així ho faria».

Omple la rúbrica de l'apartat 9 amb una evidència concreta per criteri i calcula la teva nota ponderada. Construeix després el pla de millora ordenant per pes els criteris amb nota més baixa, amb una acció concreta i una estimació per fila. Finalment, tria l'acció de prioritat 1 i fes-la; després torna a puntuar aquell criteri.

Solució 1. L'apartat 2 conté l'estructura i l'extracte del README de LesMevesDespeses. Les tres fallades més habituals: un README que descriu el codi en lloc del problema, una secció d'instal·lació amb prosa entre les ordres, i cap demostració de sessió. Rúbrica d'autoavaluació: algú que no coneix el teu projecte sabria en un minut què fa i per a qui? Pot instal·lar-lo copiant i enganxant, sense preguntar-te res? Hi ha exemple de sessió real? La secció de limitacions existeix i està escrita com a decisions? git tag mostra v1.0?

Solució 2. L'apartat 3 té el guió amb temps i l'apartat 4 els tres exemples de decisió ben argumentada —classe davant de diccionari, JSON davant de CSV, separació de capes— amb l'estructura context, alternativa, criteri i conseqüència. L'apartat 5 fa el mateix amb les limitacions. Rúbrica: el teu guió dedica els primers 60 segons al problema i a la solució, sense esmentar tecnologia? La demostració és d'un flux real amb dades ja carregades? Cada decisió esmenta l'alternativa que vas descartar? Cada limitació acaba proposant com es resoldria? Cap en cinc minuts cronometrats?

Solució 3. L'apartat 9 té la rúbrica i el pla de millora de LesMevesDespeses, amb la seva nota de 2,85 i les quatre accions ordenades per pes. El que sol fallar en aquest exercici és la generositat: si et poses un 4 en proves amb tres proves soltes, la rúbrica deixa de servir per a res. Rúbrica de la rúbrica: cada nota té una evidència concreta i numèrica al costat? El teu pla està ordenat per pes del criteri, no pel que et ve de gust fer? Cada acció cap en tres hores? Ja has fet la primera?

Un projecte que no se sap explicar no compta, i explicar-lo comença pel repositori: README complet, requirements.txt, .gitignore, zero dades personals o credencials, sense fitxers temporals, historial llegible, tot committejat, etiqueta v1.0 i la comprovació definitiva de clonar en una carpeta nova i arrencar. El README és el document més rendible que escriuràs: deu seccions en ordre —títol i frase, descripció del problema abans que de la solució, característiques, requisits, instal·lació en ordres copiables, ús amb demostració en text d'una sessió real, estructura, proves, limitacions i autoria— i s'escriu en una hora.

La demostració de cinc minuts té guió i repartiment de temps: trenta segons de problema, trenta de solució, dos minuts de demostració del flux principal amb dades preparades per endavant i assajades, un minut de detall tècnic del qual estiguis orgullós i un minut de limitacions i següents passos; i si alguna cosa falla, es reconeix, s'anota i es continua, sense depurar en directe. Les decisions tècniques es defensen amb el patró context, alternativa descartada, criteri i conseqüència —per què una classe i no un diccionari, per què JSON i no CSV, per què separar la interfície de la lògica—, i les limitacions amb el patró «ho sé, ho vaig deixar fora expressament, així ho faria», que converteix cada mancança en una decisió i pel qual el calaix Won't de 09-01 esdevé el teu guió. Les preguntes típiques es preparen per escrit, la de la IA inclosa, on la resposta honesta sempre guanya. La crítica s'escolta sencera, s'anota literal, s'agraeix i en fred es classifica en error real, millora encertada, preferència personal o fora d'abast; les dues primeres es converteixen en tasques. I el projecte es publica: repositori a GitHub amb descripció, temes i llicència, amb la idea que dos o tres projectes acabats valen més que vint a mitges, i amb l'hàbit de llegir codi aliè per tenir referències. L'autoavaluació tanca el cercle amb la rúbrica de 09-01, exigint una evidència concreta per criteri, i el pla de millora ordena per pes el que més puja la nota.

Amb això, el projecte està fet, acabat, defensat i publicat —que és exactament el que es proposava en obrir el mòdul—. Queda una última conversa, i no és tècnica: què fer a partir d'ara. A Següents passos com a programador recorrerem el que s'ha après en aquests nou mòduls, el que aquest curs no va cobrir i convé saber que existeix, els camins professionals que s'obren amb el que ja saps, els hàbits que convé consolidar i un pla concret per als propers tres mesos.