Full stack developer

Com escric el programari: proves primer i peces que es poden canviar.

TDD, SOLID, integració contínua i unes quantes regles més que no negocio. Aquí hi ha cada una amb el seu motiu, un cas on s'aplica i el text públic on està definida.

Proves TDD, piràmide de proves
Disseny SOLID, hexagonal, KISS i YAGNI
Entrega CI/CD, versionat semàntic, dotze factors

Les regles que no negocio

No són manies: cada una es paga sola la primera vegada que cal canviar alguna cosa amb el programa ja funcionant i gent a dins.

Un encàrrec petit i un de gran s'escriuen igual. La diferència és quantes vegades hi tornaràs: el programari que resol un procés d'una empresa es toca cada pocs mesos perquè el procés canvia, i el que decideix si això és barat o caríssim es va decidir el primer dia, quan es va triar on posar cada frontera.

El que no faig

Gairebé tota la feina de mantenir alguna cosa barata consisteix en el que es va decidir no posar-hi.

No començo triant framework. Primer hi ha el procés que cal resoldre i la dada que cal guardar; l'eina es tria després, i de vegades la resposta és que no en cal cap. Aquesta mateixa web n'és l'exemple: PHP pla, sense base de dades, sense dependències i sense pas de compilació, perquè res del que fa ho demanava. Es pot llegir sencera i se serveix amb un servidor web i res més.

No escric codi «per quan calgui». Una capa d'abstracció que encara no té dues implementacions no és flexibilitat: és una peça més per mantenir i una indirecció més per llegir. Quan apareix la segona, s'extreu, i llavors les proves ja hi són i el canvi és mecànic.

I no deixo la interfície per al final. El que es veu té el seu propi mètode, les seves regles de contrast i de focus, i no s'improvisa la tarda abans de lliurar.

Glossari de l'ofici.

Els termes tal com es fan servir, amb un cas on aplico cada un i el text públic que el defineix. Així no cal creure'm: es pot comprovar.

TDD · Desenvolupament guiat per proves Escriure primer una prova que falla, després el codi mínim que la fa passar i només llavors netejar el resultat. És el cicle vermell-verd-refactor, i ordena el disseny abans que hi hagi codi per defensar. Exemple: En un validador de formulari, la primera prova és la del correu invàlid: fins que no falla pel motiu correcte, no s'escriu el validador. Quan mesos després cal admetre un domini nou, aquella prova continua vigilant els altres casos. Font: Test-Driven Development, Martin Fowler
Piràmide de proves Moltes proves unitàries ràpides a baix, unes quantes d'integració al mig i molt poques d'extrem a extrem a dalt. Com més amunt, més tarden i més fràgils són, així que a dalt només hi va el que de debò cal comprovar sencer. Exemple: El càlcul dels dies de vacances que li queden a algú es prova desenes de vegades en unitàries; la pantalla completa, amb navegador, una sola vegada. Font: Test Pyramid, Martin Fowler
SOLID Cinc principis de disseny: responsabilitat única, obert-tancat, substitució de Liskov, segregació d'interfícies i inversió de dependències. Tots apunten al mateix: que un canvi previsible es faci en un lloc i no en catorze. Exemple: Afegir una forma de pagament nova hauria de ser una classe nova i una línia de configuració. Si cal obrir el càlcul de la comanda per posar-hi un «si és la passarel·la nova, llavors…», el disseny t'està avisant. Font: SOLID Relevance, Robert C. Martin
Arquitectura hexagonal · Ports i adaptadors La lògica del negoci es queda al centre i tot el de fora —base de dades, API, correu, pantalla— entra per un port amb el seu adaptador. El centre no sap qui li parla. Exemple: L'enviament del correu d'un formulari va darrere d'una interfície: en producció surt per SMTP i a les proves s'escriu en un fitxer, sense tocar ni una línia de la lògica. Font: Hexagonal Architecture, Alistair Cockburn
KISS, YAGNI i DRY · Simplicitat primer Tres dreceres per al mateix: fes-ho simple, no ho construeixis fins que calgui i no repeteixis la mateixa decisió en dos llocs. L'ordre importa, perquè treure repetició abans d'hora també acobla. Exemple: Aquesta web: sense base de dades, sense dependències i sense build. El contingut viu en tres fitxers i el lloc se serveix amb un servidor web i res més. Font: Yagni, Martin Fowler
Refactorització Canviar com està escrit el codi sense canviar què fa, en passos petits i amb les proves en verd tota l'estona. No és «reescriure-ho»: reescriure és començar de zero i perdre el que s'havia après. Exemple: Una funció de quatre-centes línies es parteix en cinc amb nom propi, una a una, executant les proves entre pas i pas. Si alguna cosa es trenca, se sap exactament en quin pas. Font: Refactoring, Martin Fowler
CI/CD · Integració i entrega contínues Integrar la feina a la branca principal sovint, amb les proves passant a cada integració, i tenir sempre una versió llesta per sortir. El que s'acumula durant setmanes es trenca tot junt i el mateix dia. Exemple: Cada canvi passa la bateria de proves abans de fusionar-se; el desplegament és sempre el mateix guió, així que pujar és rutina i no un esdeveniment. Font: Continuous Integration, Martin Fowler
Versionat semàntic · SemVer 2.0.0 Numerar les versions com major.menor.pedaç, on el primer número només puja quan es trenca la compatibilitat. El número deixa de ser decoratiu i passa a ser una promesa. Exemple: Qui consumeix una API sap que pot actualitzar de 2.3.1 a 2.4.0 sense tocar la seva integració, i que un salt a 3.0.0 cal llegir-lo abans. Font: Semantic Versioning 2.0.0
Commits convencionals Escriure el motiu del canvi amb un prefix fix —fix, feat, refactor…— perquè l'historial es pugui llegir i d'aquí surtin les notes de versió i el número següent. Exemple: L'historial del projecte contesta «per què està això així?» sense haver de preguntar-ho a ningú, que és just el que no pot fer un comentari al codi. Font: Conventional Commits 1.0.0
Dotze factors · Twelve-Factor App Dotze regles perquè una aplicació es pugui desplegar, escalar i moure sense sorpreses: configuració a l'entorn, dependències declarades, processos sense estat, registres com a flux. Exemple: Les credencials no viuen al repositori, sinó al fitxer de configuració del servidor, fora del directori que es publica. La mateixa aplicació arrenca en local i en producció canviant només aquell fitxer. Font: The Twelve-Factor App
Problem Details · RFC 9457 Un format estàndard per explicar l'error d'una API: tipus, títol, estat, detall i instància. Serveix perquè qui la consumeix programi el cas dolent en lloc d'endevinar-lo llegint cadenes de text. Exemple: Una integració amb un ERP distingeix «el document no existeix» de «no tens permís» pel camp de l'error, i no per si el missatge porta la paraula «permís». Font: RFC 9457, Problem Details for HTTP APIs (IETF)
OWASP Top 10 La llista dels deu riscos de seguretat més habituals en aplicacions web, mantinguda per la fundació OWASP. Funciona com a llista de repàs: la majoria dels forats reals hi són. Exemple: Abans de publicar, el repàs de sempre: control d'accés per recurs i no per pantalla, consultes amb paràmetres, dependències al dia i registres que no escupen dades personals. Font: OWASP Top 10
Qualitat de producte · ISO/IEC 25010 El model internacional que descompon la qualitat d'un producte de programari en nou característiques —entre elles mantenibilitat, seguretat i fiabilitat— amb les seves subcaracterístiques. Serveix per discutir qualitat amb paraules concretes. Exemple: Quan algú demana «que sigui robust», el model obliga a separar quina part és fiabilitat, quina part és seguretat i quina part és simplement que la pantalla s'entengui. Font: ISO/IEC 25010:2023

Preguntes.

Escriure les proves primer no va més lent?

El primer dia, sí. El càlcul canvia tan bon punt cal tocar alguna cosa que ja és en producció: sense proves, cada canvi obliga a repassar a mà el que abans funcionava, i això es paga cada vegada. Amb proves es paga una.

Es pot aplicar SOLID sense framework, en PHP pla?

SOLID no és una biblioteca, és on es posen les fronteres. Es pot fer malament amb el framework més modern i bé amb un grapat de fitxers: el que importa és que la lògica no sàpiga d'on ve la dada ni a quina pantalla va.

Quina cobertura de proves busques?

No persegueixo un percentatge. Un número alt amb proves que no comproven res dona falsa tranquil·litat. El que busco és que allò que fa mal si es trenca —el càlcul, el permís, els diners— estigui cobert, i que una fallada en producció deixi sempre una prova nova al darrere.

I si el projecte ja existeix i no té res d'això?

Es comença per on es tocarà. Abans de canviar una peça, se li escriuen proves que fixin què fa avui —encara que el que faci avui sigui estrany—; amb aquella xarxa, el canvi deixa de ser una juguesca. Reescriure-ho tot gairebé mai és la resposta.

Qui decideix quan una cosa està acabada?

Ho decideix una llista escrita abans de començar, no la sensació que ja va bé: les proves passen, l'error està explicat en el seu format, la pantalla es pot fer servir amb teclat i amb lector, la versió està numerada i el desplegament s'ha fet amb el guió de sempre.

Fonts.

Tot el que s'afirma aquí està descrit en un text públic. Aquestes són, amb el seu organisme i la seva data.

On continuar.

Parlem?

Et quadra aquesta manera de treballar?

Explica'm què tens entre mans i et dic per on començaria.

Escriu-me