Llibres i recursos en línia tenen un límit: són converses d'una sola direcció. El criteri de disseny — saber quan un Strategy és elegància i quan és sobreenginyeria — s'esmola discutint amb altres persones: preguntant bé, defensant una decisió en una code review, llegint codi escrit per gent millor que tu. En aquesta lliçó mapem les comunitats on aquesta conversa passa — de Stack Overflow als grups d'usuaris de Java, de l'open source a la taula del teu propi equip — i, tan important com l'on, el com: la netiqueta i les tècniques perquè cada interacció et faci millor dissenyador.

1. El mapa: tipus de comunitat i què aporta cadascuna
2. Stack Overflow: com preguntar bé sobre disseny
3. Reddit i els fòrums de discussió
4. Comunitats locals i meetups: JUGs i grups d'arquitectura
5. Conferències
6. L'open source com a escola de patrons
7. El teu equip com a comunitat de pràctica: mentoria i code review
8. La qüestió de l'idioma: català, castellà i anglès

Fixa't en l'última fila: la comunitat més potent no és a internet. Hi tornarem.

Stack Overflow és el major arxiu de coneixement de programació que existeix, però les preguntes de disseny tenen truc: les purament basades en opinió ("quin patró és millor?") es tanquen. Per preguntar bé sobre disseny:

• Abans de preguntar, busca: gairebé tot dubte sobre un patró GoF ja té respostes excel·lents amb anys de vots.
• Ancora la pregunta en codi concret: no "he d'usar Strategy o State per a la meva app de comandes?", sinó un exemple mínim reproduïble — la teva versió reduïda del cicle de vida de la comanda de PideYa — i una pregunta específica: "quina conseqüència té que les transicions visquin als estats en lloc de al context?".
• Explica el problema, no la teva solució a mitges: el clàssic "problema XY" és demanar ajuda amb el pas 3 d'una solució equivocada en lloc d'exposar el problema original.
• Per a preguntes més obertes de disseny, el lloc germà Software Engineering Stack Exchange tolera millor la discussió conceptual.

I un consell que sorprèn: redactar bé la pregunta en resol la meitat abans de publicar-les. Explicar el problema amb precisió és una tècnica de disseny en si mateixa (la versió escrita del "rubber duck debugging").

Reddit funciona diferent: no hi busques respostes canòniques sinó conversa i pols de la indústria.

• r/softwarearchitecture: discussions sobre els temes del mòdul 6 — microserveis contra monòlits, event sourcing, DDD — amb experiències reals de sistemes en producció.
• r/java: novetats del llenguatge i de l'ecosistema; útil per no quedar-te ancorat en el Java amb què vas aprendre (els virtual threads del mòdul 6 van arribar al teu radar per llocs així).
• r/ExperiencedDevs mereix menció: debats sobre com es prenen decisions de disseny en equips reals.

Com aprofitar-ho sense perdre't: llegeix els fils amb moltes respostes argumentades, desconfia de les respostes absolutes ("X sempre", "Y mai no és bona idea") i tracta cada fil com una col·lecció d'anècdotes, no com a evidència. El valor és en la varietat de contextos, no en l'autoritat.

Els Java User Groups (JUGs) existeixen a la majoria de ciutats grans i celebren xerrades periòdiques gratuïtes; en el món hispanoparlant hi ha JUGs actius a Espanya i Llatinoamèrica. Al seu costat, els grups de software crafters i els meetups d'arquitectura de programari organitzen des de xerrades fins a kates en grup (recorda la Gilded Rose: fer-la en parella en un meetup és una altra experiència).

Per què mereixen el desplaçament quan el virtual és més còmode:

• Coneixes gent amb els teus mateixos problemes en empreses diferents: la manera més ràpida de calibrar si el teu context és normal o peculiar.
• Les converses de passadís després de la xerrada solen valer més que la xerrada.
• Són el planter natural de mentors, ofertes de feina i col·laboradors per a projectes personals.
• Presentar tu una xerrada curta (una lightning talk sobre, per exemple, "tres patrons que vaig trobar al meu codi llegat") és un dels millors acceleradors d'aprenentatge que existeixen.

Les conferències — Devoxx i GOTO en el circuit internacional, i a Espanya esdeveniments com Commit Conf o les edicions locals de Devoxx — condensen en dos o tres dies el que l'ecosistema triga un any a discutir. No són imprescindibles (les seves xerrades acaben a YouTube, com vam veure a la lliçó anterior), però assistir-hi en persona aporta el que el vídeo no dona: focus sense interrupcions, converses amb ponents i l'energia de veure que hi ha una professió sencera empenyent en la teva mateixa direcció. Si la teva empresa te'n finança una a l'any, aprofita-la; si no, les versions locals i gratuïtes dels meetups cobreixen bona part del valor.

L'open source és la major escola de disseny mai construïda, i té dues aules:

Llegir codi. Els projectes que ja uses són plens dels patrons d'aquest curs, aplicats per equips experts sota restriccions reals:

Mètode de lectura: tria una classe que usis cada dia (per exemple JdbcTemplate o ImmutableList), llegeix-la amb la pregunta "quin patró hi ha aquí i per què van triar aquest?", i contrasta amb el que tu hauries fet.

Contribuir. Comença petit i realista: issues etiquetades com a "good first issue", millores de documentació, un test que falta. El veritable premi de contribuir no és el commit acceptat sinó la revisió dels mantenidors: feedback gratuït d'alguns dels millors dissenyadors del món sobre el teu codi. Prepara't per iterar; aquesta iteració és la classe.

La comunitat més infravalorada és la que tens a tres metres (o tres clics): el teu propi equip. Dues pràctiques la converteixen en escola de disseny:

Mentoria, en totes dues direccions: demanar a algú sènior mitja hora quinzenal per revisar les teves decisions de disseny, i — tan aviat com puguis — fer tu de mentor d'algú júnior, perquè explicar un patró és la prova definitiva d'haver-lo entès (si no pots explicar per què FacanaCheckout no ha de contenir lògica de negoci, encara no ho saps del tot).

La code review com a conversa de disseny. Una revisió de codi pot ser un tràmit o la millor discussió de disseny de la teva setmana. Netiqueta perquè sigui la segona:

• Com a autor: PRs petites; explica el perquè a la descripció ("introdueixo Strategy aquí perquè ja hi ha tres polítiques d'assignació i en venien dues més"); si la decisió és gran, referencia l'ADR (mòdul 6).
• Com a revisor: comenta sobre el codi, mai sobre la persona ("aquest mètode barreja dues responsabilitats" i no "no has entès SOLID"); pregunta abans de sentenciar ("vas valorar X? què et va fer descartar-ho?"); distingeix explícitament el que bloqueja del que és opcional (un "nit:" al davant ajuda).
• Per a tots dos: cita principis i patrons pel seu nom — és exactament l'avantatge del vocabulari comú que vam prometre a la primera lliçó del curs — i treu de la PR les discussions llargues: una trucada de deu minuts resol el que vint comentaris enquisten.

Siguem honestos amb la realitat: la conversa global de disseny de programari passa majoritàriament en anglès. Els llibres de la lliçó 07-01, les respostes més votades de Stack Overflow, les issues de Spring i les xerrades de GOTO: anglès. Ignorar-ho és amputar-se el 90% de l'ecosistema.

Això no vol dir abandonar la teva llengua: hi ha comunitats actives en català i castellà (JUGs i meetups locals, comunitats de crafters, podcasts i canals tècnics) que són excel·lents per començar, per al contacte local i per explicar — que, ja ho vam dir, és aprendre dues vegades. L'estratègia sensata és asimètrica:

• Consumeix en anglès des d'ara: comença per material escrit (es llegeix amb l'ajuda del diccionari o del traductor), segueix amb xerrades amb subtítols. L'anglès tècnic és un vocabulari sorprenentment petit i repetitiu; en uns mesos d'exposició es torna transparent.
• Participa on et sentis capaç: primer a la teva comunitat local en la teva llengua; quan l'anglès escrit deixi d'intimidar-te, una primera pregunta a Stack Overflow o una issue ben redactada. Ningú no jutja l'accent en un fòrum.

Millorar el teu anglès tècnic és, probablement, la inversió amb millor retorn de tota aquesta lliçó.

• Error: consumir comunitat sense participar mai. Llegir Reddit durant anys sense escriure un comentari deixa fora la meitat del valor: articular la teva postura és el que forma criteri. Comença petit: una resposta, una pregunta ben feta.
• Error: preguntar sense haver buscat ni intentat. És la manera més ràpida de rebre fredor en qualsevol fòrum. Mostra sempre què vas provar i on et vas encallar.
• Error: prendre les opinions de fòrums com a evidència. "A Reddit diuen que els microserveis són morts" no és un argument de disseny; és una anècdota agregada. Contrasta amb el teu context.
• Error: contribuir a open source començant per una feature gran. Les PRs enormes de desconeguts es rebutgen o llangueixen. Documentació, tests, issues petites: així es construeix confiança.
• Error: tractar la code review com un combat. Si defenses el teu codi com si et defensessis a tu, deixes d'aprendre. El codi no ets tu.
• Consell: tria una comunitat de cada tipus (una de Q&A, una de local, un projecte open source) i sigues constant sis mesos. La pertinença superficial a deu comunitats aporta menys que la pertinença real a tres.

Escriu (sense publicar-la necessàriament) una pregunta de disseny sobre la teva implementació de PideYa com si fos per a Stack Overflow: context mínim, codi reduït, què vas provar, pregunta específica i no opinable. Revisa: podria algú respondre-la sense demanar-te més informació? Se't va aclarir alguna cosa en redactar-la?

Tria un projecte de la taula (o una llibreria que usis cada dia). Dedica una hora a llegir una classe central del seu codi font i documenta: dos patrons del curs que reconeguis, amb la classe/mètode concret on apareixen i una frase sobre per què creus que els autors els van triar.

Dissenya la teva participació per als pròxims tres mesos: una comunitat de cada tipus (Q&A, fòrum, local, open source), què faràs a cadascuna (de "llegir setmanalment" a "presentar una lightning talk") i un compromís concret de participació activa — almenys una contribució visible: pregunta, resposta, PR o xerrada.

Exercici 1 (orientativa): una bona versió s'assembla a: "Modelo el cicle de vida d'una comanda amb el patró State (codi de 30 línies adjunt, estats Confirmada/EnPreparacio/EnRepartiment). Les transicions vàlides són a cada estat, però ara necessito que depenguin també del tipus de restaurant. Quines conseqüències té moure la lògica de transició a una taula al context en lloc de mantenir-la als estats?". És concreta, mostra feina prèvia i demana conseqüències, no opinions. I sí: sovint la resposta se t'acut en acabar de redactar-la.

Exercici 2 (orientativa): un resultat típic amb Spring: Template Method a JdbcTemplate.execute (l'esquelet gestiona connexió i excepcions, el callback aporta el pas variable — triat perquè el recurs s'ha d'alliberar sempre) i Strategy a PlatformTransactionManager (la mateixa abstracció de transacció sobre JDBC, JPA o JTA). L'important no és encertar la intenció històrica exacta sinó argumentar-la amb el que has après.

Exercici 3 (orientativa): un pla realista: Stack Overflow (llegir cada dia les etiquetes java i design-patterns; respondre una pregunta al mes), r/softwarearchitecture (lectura setmanal, un comentari argumentat al mes), el JUG o meetup de la teva ciutat (assistir a les tres pròximes sessions, presentar-te a l'organitzador), i una llibreria que ja usis (llegir-ne el codi, resoldre una "good first issue" abans de 90 dies). Poc, concret i sostingut guanya a molt i abandonat.

L'aprenentatge de disseny és, en el seu tram final, un esport d'equip: Stack Overflow per a les preguntes precises, els fòrums per al pols de la indústria, els meetups i JUGs per a la comunitat propera, l'open source per llegir i rebre feedback dels millors, i — la joia amagada — el teu propi equip, on cada code review pot ser una classe de patrons si autor i revisor hi posen netiqueta i vocabulari comú. I gairebé tot això, convé assumir-ho aviat, passa en anglès. Amb els llibres, els recursos en línia i les comunitats ja mapats, només queda una cosa: mirar enrere al camí complet que has recorregut amb PideYa i decidir els primers passos del que ve. T'espera a la Conclusió del Curs.