El dissabte passat van ser les festes d’Open Source a Girona, i com cada any, al final sempre es fan les lightning talks. Aquestes xerrades són molt ràpides (5 minuts) i permeten presentar qualsevol cosa: una idea, un projecte, una eina, etc. En una d’aquestes xerrades l’Adri va presentar una eina per fer documentació anomenada Starlight, i em va captivar.
Aquesta setmana l’he estat provant durant alguns moments per començar a generar la documentació de desenvolupament del nostre frontal, i el que més m’ha agradat és que pot renderitzar els propis components! S’ha acabat fer captures de pantalla!
Començo amb algunes recomanacions,
💾 Programari
Avui torno amb una recomanació d’un client per API Rest. Fa poc, l’autor d’aquesta eina l’ha alliberat com a software lliure. L’eina es diu Yaak i la podeu trobar a GitHub.
🤔 Curiositats
2024 i ja és possible centrar contingut verticalment des de CSS! 🥳 El que trobo més interessant d’això és la història de les diferents maneres que s’han anat trobant per solucionar aquest problema :)
📦 Recursos
Us comparteixo el capítol “El arte de diseño de software” d’un podcast anomenat “Hablando de software”, on parlen de les pràctiques i fonaments de com dissenyar software.
🌟 El concepte
Aquesta setmana parlaré de les pull requests, una eina per col·laborar en el desenvolupament de codi dins d’un equip.
Les pull requests són una funció que permet a les persones desenvolupadores suggerir canvis en un repositori de codi. Quan algú treballa en una branca i vol integrar els seus canvis a la branca principal, crea una pull request perquè altres membres de l'equip puguin revisar i discutir aquests canvis abans de fusionar-los. Aquesta eina fomenta la col·laboració i garanteix que els canvis tinguin la qualitat necessària i estiguin alineats amb els objectius del projecte.
A GISCE-TI, fem servir les pull requests com a peça central del nostre procés de desenvolupament. Cada canvi passa per una revisió de codi per part de membres de l'equip, assegurant-nos que les noves línies de codi compleixen els estàndards establerts i no introdueixen regressions. A més, tenim integració amb eines d'integració contínua (CI) que comproven automàticament la qualitat del codi amb proves unitàries i proves de cobertura.
Però l'objectiu de les revisions de codi va més enllà de la simple validació tècnica:
Distribució del coneixement: Quan diferents membres de l'equip revisen una pull request, tots es familiaritzen amb els canvis introduïts. D'aquesta manera, si hi ha noves funcionalitats o correccions, tothom qui ha participat en la revisió està al corrent de les modificacions realitzades.
Distribució de responsabilitats: A GISCE-TI considerem que la responsabilitat de les modificacions no recau exclusivament en la persona que ha realitzat els canvis. Les persones que revisen i accepten la pull request també assumeixen part de la responsabilitat, ja que el seu vistiplau implica una aprovació col·lectiva. Això crea un entorn de confiança on tothom se sent part del procés.
Aquest enfocament ens permet treballar de manera col·laborativa, garantint que el codi es mantingui en bon estat i que l'equip tingui una visió compartida del projecte.
💖 Feedback
Si t’ha agradat i em vols ajudar, fes arribar aquest contingut a qui creguis que li pot interessar, i entra al canal de Telegram per comentar la publicació.