Aquesta és l'única lliçó del curs que no parla de CicloUrbana, i és deliberat. La xarxa de Ribalta està construïda, provada, desplegada, observada i revisada; el que queda no és una peça més del projecte, sinó la capacitat de continuar aprenent quan ja no hi hagi un temari a seguir.

I això té la seva pròpia tècnica. Internet és ple de material sobre Spring Boot, i bona part està desactualitzat d'una manera especialment traïdora: un tutorial de Spring Boot 2 no sembla antic —el codi compila gairebé igual— però ensenya javax.persistence en lloc de jakarta.persistence, WebSecurityConfigurerAdapter en lloc de SecurityFilterChain i Spring Cloud Sleuth en lloc de Micrometer Tracing. Saber distingir-ho val més que qualsevol llista d'enllaços.

Aquesta lliçó organitza els recursos que sí que mereixen el teu temps, comentats i amb criteri: quina documentació llegir i com, per què el codi font és la millor font, com mantenir-se al dia i planificar una actualització de versió major, quins llibres valen la pena i per a qui, on és la comunitat, com practicar de debò, quins temes són el pas següent natural des d'on ets ara, i un full de ruta raonat per als propers sis mesos.

1. Aprendre amb criteri
2. La documentació oficial i com llegir-la
3. El codi font com a documentació
4. Mantenir-se al dia
5. Planificar una actualització de versió major
6. L'ecosistema Java
7. Llibres
8. Certificacions
9. Comunitat
10. Pràctica deliberada
11. Temes naturals per al pas següent
12. Com avaluar un recurs
13. Un full de ruta de sis mesos
14. Errors Comuns i Consells
15. Exercicis

Un avís abans de la llista, perquè és el que decideix si la resta serveix d'alguna cosa.

El coll d'ampolla no és l'accés a la informació: és l'atenció. Hi ha més contingut sobre Spring Boot del que es pot consumir en una vida, i l'impuls natural —desar vint enllaços, apuntar-se a tres butlletins, començar quatre cursos— produeix la sensació d'estar aprenent sense que es consolidi res. La manera que sí que funciona té tres trets:

I una jerarquia de fonts que convé interioritzar, de més a menys fiable: el codi font > la documentació de referència > les guies oficials > els llibres d'autors reconeguts > les conferències > els articles de blog > les respostes de fòrums > el contingut generat sense revisió. No vol dir començar sempre per dalt: vol dir que quan dues fonts es contradiuen, guanya la de dalt.

Com llegir la documentació de referència sense perdre's. Tres tàctiques que canvien l'experiència:

• Cerca-hi, no la llegeixis de dalt a baix. Està escrita per consultar-se. L'estructura de seccions i el cercador integrat estan pensats per arribar directament al paràgraf que respon la teva pregunta.
• Comença per l'apèndix de propietats. Quan dubtis de si alguna cosa és configurable, la resposta sol ser-hi, amb el valor per defecte —que és la meitat de la informació útil—.
• Llegeix les notes de versió de la versió que fas servir. És mitja hora ben invertida: t'assabentes de funcionalitats que fa mesos que reimplementes a mà.

Com llegir javadoc amb profit. No és documentació de màrqueting: és el contracte. El que cal buscar-hi són les tres coses que la signatura no diu: què passa en els casos límit (retorna null o llista buida?, accepta zero?), quines excepcions llança i quan, i si és segur entre fils. Aquesta última dada apareix sovint en una frase del javadoc de classe i és exactament la que es busca quan alguna cosa falla sota càrrega.

Un exemple concret de recorregut, perquè la tècnica s'entén millor en acció. Suposa que vols saber si pots limitar la mida de la cua de l'executor asíncron i què passa quan s'omple:

Quatre consultes, cinc minuts, i una resposta que no depèn que cap article l'hagi explicada bé.

Aquí hi ha el consell amb millor relació esforç/benefici de tota la lliçó: llegeix-te el codi de Spring. És obert, és a GitHub, està raonablement comentat i respon preguntes que cap documentació no respon.

Per què és la millor font. La documentació descriu la intenció; el codi descriu el comportament. Quan alguna cosa no funciona com esperaves, la diferència entre tots dos és exactament on és el teu problema. I a diferència d'un article, el codi mai no està desactualitzat respecte de si mateix.

Tres coses que convé aprendre a llegir:

Les classes d'autoconfiguració. Cercar *AutoConfiguration a l'arbre de spring-boot-autoconfigure i llegir-ne una de sencera —DataSourceAutoConfiguration, JacksonAutoConfiguration o WebMvcAutoConfiguration— desmunta la sensació de màgia de cop. Es veu quines condicions (@ConditionalOnClass, @ConditionalOnMissingBean) activen cada bean, i per tant què has de fer per substituir-lo: gairebé sempre, declarar el teu.

Les classes *Properties. ServerProperties, JpaProperties o DataSourceProperties són la llista exacta i tipada del que es pot configurar, amb els seus valors per defecte als camps. Sol ser més ràpid que buscar a la documentació.

Els spring.factories i AutoConfiguration.imports. El fitxer META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports és literalment la llista de tot el que Spring Boot pot autoconfigurar. Llegir-la una vegada dona una idea de l'abast del framework que cap altra cosa no dona.

Amb les fonts descarregades, Ctrl+B sobre qualsevol anotació a l'IDE porta a la seva definició. Aquest és l'hàbit: quan no entenguis per què alguna cosa es comporta així, entra-hi.

Spring Boot publica una versió menor cada sis mesos (novembre i maig, aproximadament) i correccions cada mes. L'important no és el calendari, sinó la política de suport:

La conseqüència pràctica és dura i convé assumir-la: una aplicació en producció necessita pujar de versió menor almenys una vegada l'any. No és una millora opcional, és manteniment de seguretat. Un projecte que fa tres anys que és a la mateixa versió menor no està «estable»: està acumulant vulnerabilitats conegudes sense pedaç.

L'estratègia sana és pujar aviat i sovint: passar de 3.3 a 3.4 tan bon punt surt i hi ha temps és una feina d'hores; passar de 2.7 a 3.x amb quatre anys de retard és un projecte de setmanes.

L'última fila no és negociable: una vulnerabilitat coneguda en un framework tan estès s'explota massivament al cap de poques hores de publicar-se.

Com llegir unes notes de versió en deu minuts. Tenen sempre la mateixa estructura i convé recórrer-la en aquest ordre: primer «Breaking Changes», que és l'única cosa que et pot trencar i sol ocupar mitja pantalla; després «Deprecations», per saber què has de començar a canviar encara que avui continuï funcionant; després «Dependency Upgrades», on es veu quines versions d'Hibernate, Jackson o Tomcat vénen a dins —i si alguna t'afecta directament—; i per últim «New and Noteworthy», que és la part divertida i la menys urgent. Llegir-les a l'inrevés, començant per les novetats, és el motiu pel qual molta gent s'emporta sorpreses.

Pujar d'una versió major a la següent —el cas paradigmàtic és Spring Boot 2.7 → 3.0, amb el salt de javax a jakarta— no és un canvi de número. Aquest és el procediment que funciona.

Pas 0: tenir proves. Sense la suite del mòdul 6, una actualització major és un salt al buit. Si el projecte no en té, escriure-les és el primer pas de la migració, no una tasca a part.

Pas 1: llegir la guia de migració sencera, abans de tocar res. És al wiki del repositori de Spring Boot i enumera els canvis incompatibles un a un. Mitja hora de lectura estalvia dies.

Pas 2: spring-boot-properties-migrator. Una dependència temporal que, en arrencar, informa de les propietats reanomenades o retirades i aplica temporalment les equivalències:

Arrenques, llegeixes l'informe del log, corregeixes el YAML i treus la dependència. Deixar-la posada és un error clàssic: emmascara els problemes en lloc de resoldre'ls.

Pas 3: OpenRewrite per al que és mecànic. Les migracions repetitives —javax.* a jakarta.*, anotacions retirades, APIs reanomenades— les fa una recepta automàtica:

És un canvi massiu, així que va en un commit propi, sense barrejar-hi res, i es revisa llegint la diferència. OpenRewrite fa el 80 % de la feina mecànica; el 20 % restant —el que requereix criteri— continua sent teu.

Pas 4: pujar d'una versió menor cada vegada. De 2.5 a 3.3 no es salta: es va 2.5 → 2.6 → 2.7 → 3.0 → …, amb la suite en verd a cada esglaó. Si alguna cosa es trenca, saps exactament quin esglaó ho va trencar.

Pas 5: revisar el que el BOM no gestiona. Les dependències amb <version> pròpia —a CicloUrbana, JJWT, ShedLock, MapStruct, Resilience4j— no les puja Spring Boot. Són les que queden enrere i les que donen sorpreses.

Pas 6: desplegar a pre i mesurar. Una actualització major pot canviar el rendiment en totes dues direccions. La línia base de k6 del mòdul 9 existeix exactament per a això.

Spring Boot viu sobre Java, i des de fa uns anys Java es mou de pressa.

Versions LTS i què aporten. Les versions amb suport estès surten cada dos anys, i són les que es fan servir en producció:

De tot l'anterior, el que ja fa servir CicloUrbana cada dia són els record dels DTOs, els blocs de text de les consultes JPQL, el switch com a expressió i els fils virtuals.

Project Loom i els fils virtuals. És el canvi conceptual més important de l'última dècada a Java: un fil que en bloquejar-se en entrada/sortida allibera el fil del sistema operatiu en lloc d'ocupar-lo. Per a una aplicació bloquejant amb molta espera de base de dades —que és la immensa majoria de les aplicacions de gestió— permet alta concurrència sense pila reactiva.

Aquest fragment amb fils de plataforma esgotaria la memòria molt abans d'arribar al milió. Val la pena entendre'l a fons, incloses les seves dues trampes: el pinning amb synchronized i el fet que el límit real passa a ser el pool de connexions, com vam veure a 09-01.

GraalVM i imatges natives. Compilar l'aplicació a un executable natiu redueix l'arrencada de segons a mil·lisegons i la memòria a una fracció. A canvi, la compilació triga minuts, la reflexió necessita RuntimeHints explícits i el rendiment sostingut pot ser una mica menor que amb la JVM. El seu cas clar són les funcions sense servidor i els processos de vida curta; per a un servei que arrenca una vegada al dia, aporta poc.

I una idea de fons: Spring Boot és la part més visible de la teva feina, però la que més es transfereix és Java. Un bon coneixement del llenguatge, de la JVM i de la concurrència sobreviu a qualsevol framework.

Només obres àmpliament reconegudes, amb a qui serveix cadascuna. Un llibre es llegeix en setmanes i es consulta durant anys; és el format amb millor retorn a llarg termini.

Si n'haguessis de triar tres per als propers sis mesos, partint d'on ets: Effective Java (et fa millor programador Java, no millor usuari de Spring), High-Performance Java Persistence (perquè la base de dades és on és el temps) i Designing Data-Intensive Applications (perquè és el que amplia la visió més enllà d'una aplicació).

La certificació de referència de l'ecosistema és la VMware Spring Professional, que cobreix contenidor, AOP, dades, MVC, seguretat, Boot i proves: aproximadament el temari d'aquest curs.

Una valoració honesta:

Quan compensa, en concret: si treballes en una consultora on influeix en l'assignació de projectes o en la tarifa; si la teva empresa la paga i et dona temps; o si necessites una estructura externa per estudiar de manera consistent. Quan no: si l'objectiu és demostrar que en saps. Per a això, un projecte públic ben fet —amb proves, canonada i README decent— diu moltíssim més, i és el que de debò es mira en una entrevista tècnica.

Existeixen a més certificacions adjacents que en molts contextos valen més que la de Spring: les de Kubernetes (CKA i CKAD) i les dels proveïdors de núvol, perquè cobreixen una àrea on la demanda supera amb claredat l'oferta i on l'examen és pràctic, amb una terminal de debò, en lloc d'una bateria de preguntes. Si l'objectiu és l'ocupabilitat i ja saps Spring Boot, aquesta direcció sol ser millor inversió.

I el consell sobre preguntar, que serveix en qualsevol d'aquests llocs: una bona pregunta inclou la versió de Spring Boot, un exemple mínim que reprodueixi el problema, el missatge d'error complet i el que ja has intentat. Preparar aquesta pregunta resol el problema per si sola una de cada tres vegades, i el fenomen té nom —rubber duck debugging—: l'obligació d'explicar el problema amb precisió et fa veure el forat del teu raonament.

Sobre el rastrejador d'incidències, que mereix un paràgraf propi perquè gairebé ningú no el fa servir: quan Spring fa alguna cosa que no entens, hi ha una probabilitat alta que algú ja ho hagi reportat, i que un membre de l'equip hagi explicat per què funciona així. Aquestes respostes són sovint millors que la documentació, perquè responen la pregunta exacta que tu tens. Cercar el missatge d'error literal entre cometes és el primer moviment, abans d'escriure en cap fòrum.

Llegir sobre programació no ensenya a programar, igual que llegir sobre natació no ensenya a nedar. Quatre maneres de practicar que sí que funcionen:

Projectes propis de dificultat creixent. L'error habitual és començar per «una xarxa social»: massa gran, s'abandona la setmana tres. Una progressió que funciona:

Les set extensions de 10-04 cobreixen exactament aquesta progressió sobre un projecte que ja coneixes.

Contribuir a un projecte lliure. Comença per documentació o per una incidència etiquetada com a bona per començar. El que s'aprèn no és tant el codi com el procés: revisions exigents, proves obligatòries, discussions de disseny en obert. És la manera més barata de treballar amb gent millor que tu.

Katas i exercicis curts. Repetir un problema petit concentrant-te en una cosa cada vegada —aquesta vegada amb TDD, aquesta vegada sense if, aquesta vegada amb noms perfectes— és el més semblant a practicar escales. Mitja hora a la setmana.

Llegir codi aliè. L'hàbit més infravalorat. Tria un projecte Spring Boot ben valorat a GitHub i llegeix-lo com es llegeix un llibre: l'estructura de paquets, un servei, les seves proves, la seva canonada. Hi trobaràs decisions diferents de les d'aquest curs, i entendre per què les van prendre és més formatiu que estar-hi d'acord.

I un advertiment sobre les tres primeres: la pràctica sense retroalimentació no és pràctica deliberada, és repetició. Escriure codi que ningú no revisa consolida tant els encerts com els errors. Les tres fonts de retroalimentació disponibles, de més a menys accessible, són: les proves, que et diuen si funciona; les eines de 10-03 —ArchUnit, SpotBugs, l'anàlisi estàtica—, que et diuen si està ben construït; i una persona, que és l'única que et diu si està ben pensat. Si treballes sol, contribuir a un projecte lliure és la manera més barata d'aconseguir la tercera.

Tots aquests parteixen d'alguna cosa que ja saps. La tercera columna és la que importa: diu quina lliçó et va deixar preparat.

Quin triar primer. No el que més soni, sinó el que resolgui un problema que tinguis. Si la teva aplicació perd feina quan es reinicia, missatgeria. Si dos equips es trepitgen al mateix codi, Spring Modulith. Si el domini se't dilueix en els serveis, DDD tàctic. I si res no et fa mal encara, l'ordre que millor consolida el que has après és Spring Modulith → missatgeria → DDD tàctic.

Tres preguntes, en aquest ordre, abans d'invertir temps en un article, un vídeo o un curs:

1. De quan és? Si no hi ha data visible, desconfia. Un article sense data sobre un framework que publica dues versions l'any no és un recurs, és un risc.

2. Quina versió de Spring Boot fa servir? És la pregunta decisiva, i gairebé sempre es respon mirant el codi en deu segons:

Per què un tutorial de Spring Boot 2 confon més del que ajuda. No és que estigui «una mica antiquat»: és que el codi no compila en un projecte Boot 3 —canvien els paquets de totes les anotacions de persistència, validació i servlet— i, pitjor, l'explicació conceptual continua sent plausible. El lector novell no distingeix entre «això ja no existeix» i «això ho he escrit malament», i perd hores. Amb la taula anterior, aquests deu segons de comprovació t'estalvien la tarda.

3. Qui el signa i què s'hi juga? Un article de l'equip de Spring, d'un autor amb trajectòria o d'un projecte amb revisió entre iguals té un incentiu per estar bé. Un contingut optimitzat per a posicionament, no.

I un quart criteri que s'aplica sobretot al contingut generat automàticament, cada vegada més abundant: si el codi no es pot executar tal com és, sospita. Els exemples que barregen versions, inventen mètodes que no existeixen o criden APIs de dues èpoques diferents són la firma característica.

Una proposta concreta i raonada per a qui acaba aquest curs i vol consolidar en lloc de dispersar-se. El principi que l'ordena: cada mes té un lliurament, i cada lliurament es recolza en l'anterior.

Per què aquest ordre i no un altre. El mes 1 no aprèn res de nou expressament: el que s'acaba de veure es consolida fent-ho servir, no afegint-hi temes a sobre. El mes 2 és Java i no Spring perquè és el que més es transfereix i el que menys caduca. El mes 3 ataca on de debò és el temps. El 4 i el 5 són els dos salts conceptuals —comunicació asíncrona i disseny de domini— i van després de tenir la base sòlida. I el 6 tanca el cicle, perquè operar el que un construeix és el que converteix un programador en un enginyer.

Com fer-lo realista. Quatre o cinc hores a la setmana, amb un lliurament visible cada mes. Un pla de vint hores setmanals no es compleix i produeix culpa; un de cinc hores mantingut sis mesos produeix un canvi real. I si algun mes no surt, no se salta: es retarda. La seqüència importa més que el calendari.

I si la teva situació és una altra, adapta'l amb aquest criteri en lloc de copiar-lo. Si estàs buscant feina, mou el mes 6 al principi: un projecte desplegat i observable és el que s'ensenya en una entrevista. Si el teu equip partirà el monòlit el trimestre vinent, avança el mes 4 i afegeix Designing Data-Intensive Applications. Si acabes d'entrar en un projecte heretat, els mesos 1 i 2 se substitueixen per escriure proves de caracterització i actualitzar la versió, que és el que desbloqueja tota la resta. El full de ruta correcte és el que ataca el problema que tens avui, no el que cobreix més temes.

Col·leccionar recursos en lloc de fer-los servir. Cinquanta pestanyes obertes i tres cursos començats produeixen la sensació d'estar aprenent i cap aprenentatge. Un recurs cada vegada, amb un problema al davant.

Seguir un tutorial sense comprovar la versió. És la causa número u d'hores perdudes amb Spring. Deu segons mirant si diu javax o jakarta te les estalvien.

Aprendre el que és nou abans de dominar l'actual. WebFlux, GraalVM o Spring AI són interessants; si encara no tens clar com funciona el proxy de @Transactional, no són el teu pas següent.

Copiar configuració sense entendre-la. Un application.yml copiat d'un blog porta propietats que no necessites, algunes perilloses —ddl-auto: update, Actuator obert, show-sql actiu— i cap explicació.

Confondre «he llegit sobre això» amb «sé fer això». La prova és senzilla i és implacable: obrir l'IDE i fer-ho sense mirar.

Acceptar sense verificar el codi que suggereix un assistent. Els models de llenguatge s'entrenen amb tot el que hi ha publicat, i el que hi ha publicat sobre Spring Boot és majoritàriament de l'era 2.x: veuràs WebSecurityConfigurerAdapter, javax.persistence i @MockBean amb una seguretat absoluta. Són eines excel·lents per explorar i per escriure el que és repetitiu, i s'hi apliquen exactament els mateixos criteris de l'apartat 12: comprova la versió, executa'l i no l'enganxis si no l'entens.

Estudiar només el que ja t'agrada. És còmode aprofundir en el que un domina i evitar el que li resulta aliè —per a molts programadors, l'operació i la base de dades—. I és justament aquí on sol ser la diferència més gran entre el que saps i el que el projecte necessita.

Consell: escriu el que aprens. Un article, una nota interna o un fitxer docs/decisions/ al teu projecte. Explicar alguna cosa obliga a entendre-la de debò, i descobreix els forats que la lectura passiva amaga.

Consell: mantén un projecte viu. Un repositori propi al qual tornes cada poques setmanes val més que deu cursos. És on provar cada cosa nova i on comprovar si funciona a les teves mans i no només a les de l'autor.

Consell: aprèn a llegir codi abans que a escriure'l. La major part de la teva carrera la passaràs llegint: el codi del teu equip, el d'un framework, el d'algú que se'n va anar fa tres anys. És una habilitat que s'entrena, i gairebé ningú no l'entrena expressament.

Consell: quan alguna cosa et sorprengui, atura't i entra-hi. Aquell instant de «vaja, no sabia que feia això» és el millor senyal d'aprenentatge disponible, i es malbarata gairebé sempre perquè hi ha pressa. Deu minuts llegint la classe que ho provoca valen més que dues hores d'un curs sobre alguna cosa que no t'ha sorprès mai.

Consell: la millor manera d'estudiar un tema nou és escriure l'exemple més petit possible. No un projecte: un mòdul Maven de tres classes que fa una cosa. Un consumidor de Kafka que imprimeix missatges. Un @Observed que produeix un span. És ràpid d'escriure, ràpid de llençar, i contesta preguntes que cap article no contesta.

Cerca tres articles o tutorials sobre «Spring Boot JWT authentication» en qualsevol cercador. Per a cadascun, aplica els criteris de l'apartat 12 i redacta una fitxa amb: data, versió de Spring Boot deduïda i amb quin senyal concret l'has deduïda, si el codi compilaria avui, tres coses que faries diferent segons el que has après al mòdul 5, i el teu veredicte final. És molt probable que almenys un estigui desactualitzat; l'exercici consisteix a detectar-ho en menys d'un minut.

Descarrega les fonts amb ./mvnw dependency:sources i obre DataSourceAutoConfiguration (o JacksonAutoConfiguration, si prefereixes alguna cosa més curta). Respon: quines condicions s'han de complir perquè s'activi? quins beans declara? quina anotació fa que el teu propi bean guanyi el seu? de quina classe *Properties llegeix la configuració i quins valors per defecte té? I per últim: què hauries de fer per substituir completament el seu DataSource per un de teu?

Adapta el full de ruta de l'apartat 13 a la teva situació real. Parteix de tres preguntes: quin problema tens avui a la teva feina o al teu projecte que Spring Boot encara no t'ha resolt?, quantes hores a la setmana pots sostenir de debò durant sis mesos?, i quin lliurament visible marcaria cada mes? Escriu el resultat amb un lliurament per mes i un criteri objectiu per saber si l'has complert.

Solució 1

Un exemple de fitxa ben feta, sobre un cas molt habitual:

Article A — Sense data visible (primer senyal d'alarma; al peu del blog apareix 2021). Versió deduïda: Spring Boot 2.5. Senyals, per ordre de contundència: estén WebSecurityConfigurerAdapter i sobreescriu configure(HttpSecurity), retirat a Spring Security 5.7; importa javax.servlet.FilterChain; fa servir antMatchers(...), substituït per requestMatchers(...); i io.jsonwebtoken 0.9.1, l'API Jwts.parser().setSigningKey(String) de la qual ja no existeix a 0.12. Compilaria avui? No. Fallaria als import de javax.* i a la classe base retirada, i ni tan sols arribaria als errors de l'API de JJWT. Tres coses que faria diferent segons el mòdul 5: (1) SecurityFilterChain com a bean en lloc de l'adaptador, amb authorizeHttpRequests acabat en anyRequest().denyAll(); (2) el secret per variable d'entorn i de 256 bits, no una constant "secret" al codi; (3) token d'accés de quinze minuts amb refresc rotatori, en lloc de les deu hores de l'article. Veredicte: descartar. No per antic, sinó perquè l'error que ensenya és de seguretat, que és la pitjor categoria per copiar sense entendre.

Els tres senyals que resolen el 90 % dels casos en deu segons: javax enfront de jakarta, WebSecurityConfigurerAdapter, i spring-cloud-starter-sleuth. Si apareix qualsevol dels tres, el recurs és de l'era Spring Boot 2.

I el matís que evita ser injust: un recurs antic pot continuar sent conceptualment correcte. L'explicació de què és un JWT, per què se signa i per què la seva càrrega útil és llegible no ha canviat. El que no es pot copiar és el codi.

Solució 2

Sobre DataSourceAutoConfiguration, les respostes i —més important— el que ensenya cadascuna:

Quines condicions l'activen? @ConditionalOnClass({DataSource.class, EmbeddedDatabaseType.class}), és a dir, només si aquestes classes són al classpath. D'aquí la regla que explica tota l'autoconfiguració: afegir un starter de dades no «encén» res màgicament; simplement posa classes al classpath i les condicions es compleixen.

Quins beans declara? Un DataSource, resolt en configuracions imbricades: si detecta HikariCP el fa servir (@ConditionalOnClass(HikariDataSource.class)), i si no prova amb Tomcat JDBC o DBCP2, en aquest ordre. També declara DataSourceInitializer i els beans de propietats.

Què fa que el teu bean guanyi? @ConditionalOnMissingBean. És l'anotació clau de tot Spring Boot: l'autoconfiguració només actua si tu no has decidit res. Declarar el teu propi @Bean DataSource la desactiva sense necessitat d'excloure res.

D'on llegeix? De DataSourceProperties (prefix spring.datasource), on hi ha url, username, password, driverClassName, generate-unique-name i la resta, amb els seus valors per defecte escrits als camps —cosa més ràpida de consultar que la documentació—.

Com substituir-lo del tot? Tres maneres, de millor a pitjor: declarar el teu propi @Bean DataSource, que guanya per @ConditionalOnMissingBean; excloure-la amb @SpringBootApplication(exclude = DataSourceAutoConfiguration.class); o treure la dependència, amb la qual cosa la condició de classe deixa de complir-se.

El que l'exercici ensenya de debò no és aquesta classe, sinó el patró: @ConditionalOnClass + @ConditionalOnMissingBean + una classe *Properties. Amb això entens les dues-centes autoconfiguracions restants, inclosa la de l'starter propi que vam escriure a 02-06. I confirma l'afirmació de l'apartat 3: quan llegeixes el codi, la màgia desapareix.

Solució 3

No hi ha solució única, però sí una manera reconeixible d'haver fet bé l'exercici. Un exemple:

Situació: treballo en un equip de quatre persones amb un monòlit Spring Boot 2.7 que ningú no gosa actualitzar. Puc sostenir quatre hores a la setmana. El problema real no és tècnic: és que no hi ha proves i per això ningú no toca res.

Mes	Focus	Lliurament	Criteri objectiu
1	Proves de caracterització dels tres fluxos crítics	Suite que s'executa a CI	./mvnw verify en verd a la canonada, no al meu portàtil
2	Actualització a Spring Boot 3, esglaó a esglaó	Branca amb 2.7 → 3.0 → 3.3	La suite del mes 1 en verd a cada esglaó
3	Effective Java + refactorització d'un mòdul	Mòdul de facturació net	Deu elements aplicats, documentats a docs/decisions/
4	Rendiment: k6, EXPLAIN ANALYZE, índexs	Línia base i una millora mesurada	p95 de l'endpoint pitjor per sota de 300 ms
5	Observabilitat: mètriques, logs i traces	Quadre de comandament i dues alertes	Provocar un incident i diagnosticar-lo en menys de deu minuts
6	Spring Modulith	Fronteres entre facturació i comandes	Regles d'ArchUnit que fallen si algú les creua

El que fa bo aquest full de ruta: el mes 1 no és «aprendre alguna cosa», és treure el bloqueig real —sense proves no es pot fer res de la resta—; cada mes té un criteri objectiu i verificable, no «entendre X»; l'ordre respecta les dependències entre temes; i les hores són les que la persona pot sostenir de debò, no les que li agradaria.

L'error típic en fer aquest exercici és escriure una llista de tecnologies que sonen bé —Kafka, Kubernetes, WebFlux, GraalVM— sense cap problema al darrere. Un full de ruta sense un problema a resoldre s'abandona la setmana cinc.

I una comprovació final que convé fer-se: si d'aquí a sis mesos complissis el pla sencer, què sabries fer que avui no saps? Si la resposta es pot formular amb verbs —«actualitzar un projecte heretat sense por», «diagnosticar un p99 alt en deu minuts»— el pla és bo. Si només es pot formular amb substantius —«Kafka», «Kubernetes»—, encara és una llista de temes i no un full de ruta.

Aquí s'acaba el curs, i convé mirar el camí complet abans de tancar-lo.

Vam començar a 01-03 amb un @RestController de nou línies que retornava quatre estacions escrites a mà i un curl que responia a localhost:8080. Acabem amb CicloUrbana: una aplicació amb un contracte REST versionat i documentat, amb els seus DTOs, la seva validació i els seus errors en RFC 7807; amb persistència sobre PostgreSQL governada per nou migracions de Flyway i transaccions que garanteixen que cap bicicleta de Ribalta no quedi bloquejada a mitges; amb autenticació JWT, jerarquia de rols i regles de seguretat que depenen de la dada i no només de la ruta; amb una suite de proves que va de la unitat d'un mil·lisegon al flux complet sobre un PostgreSQL real i efímer; amb tasques programades coordinades entre rèpliques i feina asíncrona que no bloqueja el ciutadà; empaquetada en una imatge multietapa, desplegada a Kubernetes per una canonada que la construeix, l'escaneja i la promociona sola; i observada d'extrem a extrem, on la mètrica detecta, la traça localitza i el log explica, units per un mateix rastreId. I amb el criteri, al final, per saber per què està feta així i on caldria trencar cada regla.

L'important és que gairebé res d'això no és específic de Spring Boot. La inversió de control, la separació entre domini i contracte, l'atomicitat d'un cas d'ús, la denegació per defecte, la piràmide de proves, mesurar abans d'optimitzar, els percentils en lloc de la mitjana, les migracions compatibles cap enrere, un artefacte per a tots els entorns, els secrets fora del repositori, els logs estructurats i correlacionats, el deute tècnic registrat amb el seu cost: tot això viatja amb tu a qualsevol framework, a qualsevol llenguatge i a qualsevol equip. Spring Boot ha estat el vehicle; el que has après a conduir és més gran.

Queden coses per saber, i sempre en quedaran. És la part incòmoda i també la millor d'aquest ofici: ningú no acaba d'aprendre'l, i la diferència entre algú amb dos anys d'experiència i algú amb quinze no és el nombre de frameworks que coneix, sinó la qualitat de les preguntes que es fa abans de decidir. Aquest curs ha intentat, sobretot, ensenyar-te aquestes preguntes: quin problema resol això?, què em costa?, com sabré si funciona?, què passa quan falli?, ho entendrà el proper que ho llegeixi?

Ara et toca a tu. Agafa CicloUrbana i porta-la a algun lloc: afegeix-hi les tarifes dinàmiques, extreu-ne la facturació, connecta-la a un mapa. O comença alguna cosa teva, més petita i més real, i fes-la bé de principi a fi. El que no funciona és esperar a saber-ho tot abans de construir: s'aprèn construint, mesurant el que es construeix i arreglant el que es trenca.

La xarxa de Ribalta està en marxa. Gràcies per arribar fins aquí, i bon viatge.