El Refactor com a Ritual

“Canvia el que calgui, però no trenquis el que funciona. El refactor no destrueix: revela.”

En el camí del desenvolupament artesanal, hi ha un moment en què el projecte deixa de ser una pàgina en blanc. Apareixen dreceres, els "això ho fem ràpid i ja ho arreglarem després", les decisions preses amb pressa però amb bona intenció. I aleshores, quan tot encara funciona però comença a grinyolar, arriba el moment del refactor.

El refactor no és reescriure. No és tirar-ho tot a terra per començar de nou. És mirar el que ja hi ha amb ulls d’avui, entendre què es necessitava en el seu moment, i decidir amb cura què conservar, què millorar i què deixar enrere.

El codi com a arqueologia: primer comprendre

Refactoritzar no és improvisar. No es tracta d’obrir l’editor i començar a moure coses "perquè això es veu lleig". A Anfibic ho tractem com un acte d’investigació.

Què volia fer qui va escriure això?
Quin context tenia?
Quins riscos amaga aquest canvi?

El codi és comunicació. I refactoritzar és com rellegir una carta antiga amb una lupa: t’adones de coses que abans havien passat desapercebudes. Per això, abans de modificar res, dediquem temps a entendre. Només així el refactor no trenca màgia, sinó que l’afina.

Laravel: una capsa d’eines ideal per al refactor

Una de les raons per les quals ens encanta Laravel a Anfibic és perquè convida a l’ordre. La seva filosofia expressiva ens permet aplicar patrons de refactorització sense fricció.

Alguns exemples reals del dia a dia:

Separació de responsabilitats
Un controlador que fa de tot pot semblar eficient... fins que cal modificar-lo. Refactoritzar-lo pot implicar:

• Moure la lògica a Service Classes per mantenir el controlador net.
• Utilitzar Form Request Classes per encapsular validacions i autoritzacions.
• Dividir accions en Single Action Controllers quan la lògica ho justifica.

Extreure processos a Jobs o Listeners
Si un mètode fa múltiples tasques encadenades — enviar un correu, guardar un log, actualitzar estadístiques — les separem en Jobs o Event Listeners.

Això fa que cada part sigui testejable, desacoblada i reutilitzable.

Claredat semàntica amb noms ben posats
Refactoritzar també és posar noms més clars. Canviar un mètode de process() a applyDiscountsToCart() ho transforma tot. Laravel, amb la seva estructura de rutes, models i controladors, promou aquesta semàntica explícita.

Refactor com a inversió: impacte real

“Però si ja funciona, per què tocar-ho?”

Bona pregunta. Perquè el que funciona avui pot ser un obstacle demà.

Quan refactoritzem, no ho fem per estètica. Ho fem perquè:

• Accelera el desenvolupament futur: amb un codi més clar i modular, noves funcionalitats s’integren amb menys fricció.
• Redueix errors: el codi duplicat o barrejat en capes incorrectes tendeix a trencar-se amb els canvis.
• Facilita l’onboarding: els nous desenvolupadors entenen el sistema més ràpidament i amb menys por.
• Genera confiança: el client percep que estem construint sobre una base sòlida, no sobre pedaços.

En projectes a llarg termini (i a Anfibic en tenim molts així), el refactor és el que permet que seguim creixent sense haver de reconstruir-ho tot cada dos anys.

El Refactor com a ritu artesanal

En aquest taller digital que és Anfibic, refactoritzar no és un luxe. És una rutina, gairebé un ritu. No ho fem perquè ens sobri temps, sinó perquè sabem que estalvia temps en el futur.

És com esmolà una eina abans de tallar: triga uns minuts, però evita fer malbé tota la peça.

Cuidar el que no es veu

El client sovint no veu el refactor. No és una nova pantalla ni un botó més bonic. Però hi és. És el que permet que el projecte creixi, s’adapti i sobrevisqui als seus propis canvis.

En El Camí de l’Artesà, refactoritzar és com cuidar el sòl abans de sembrar. No es nota... fins que floreix.