El cap de setmana del 7 al 8 d’octubre es va celebrar la 4a edició del congrés anual de la Barcelona Software Craftsmanship i en Jose Francisco Crespo i n’Eduard Maura que hi van assistir ens expliquen la seva experiència.
El cap de setmana del 7 al 8 d’octubre es va celebrar la 4a edició del congrés anual de la Barcelona Software Craftsmanship i en Jose Francisco Crespo i n’Eduard Maura que hi van assistir ens expliquen la seva experiència.
L’organització
El Software Craftsmanship o Artesanía del Software és una disciplina del desenvolupament, extensió del Manifest Àgil, que neix com a resposta dels desenvolupadors a les males pràctiques percebudes per la indústria. Aquesta, es presenta en un manifest que principalment defensa el software ben dissenyat i el valor constant per sobre d’allò que funciona. A Barcelona existeix una gran comunitat de software craftsmanships que es reuneixen setmanalment per fer katas (exercicis per millorar les habilitats de programació), xerrades i discutir en general sobre el desenvolupament de software. En aquest congrés ens vam reunir unes 200 persones per atendre a xerrades, tallers i discussions sobre diversos temes. A continuació us explicarem les que ens van cridar més l’atenció.
Mesurant la qualitat del codi en WTF ‘s per minut by David Gómez
La revisió de codi o peer code review és una pràctica comuna dels equips en què es pretén millorar la qualitat del codi que es genera mitjançant la detecció d’errors o alternatives més eficients a la implementació inicial. Dins d’aquesta pràctica és molt habitual mesurar la qualitat del codi a través quantitat de WTF per minuts que s’escolten durant la revisió (Un WTF és l’expressió anglesa de sorpresa que es podria traduir per un “Què dimonis?”).
L’objectiu d’aquesta xerrada era veure exemples reals de WTF’s per tal de fer èmfasis en com són d’importants les bones pràctiques de programació per la qualitat del codi. Entre els més rellevants podríem trobar els comentaris innecessaris en atributs, getters i setters; els mètodes amb noms genèrics en comptes d’usar un naming adequat, rellançar excepcions que prèviament hem capturat; la NullPointerExceptionParanoia…
TDD: el meu quadern de receptes by Modesto San Juan
Com molts ja sabeu, alguns dels nostres equips de desenvolupament de l’inLab FIB, utilitzem TDD (Test Driven Development) en el nostre flux habitual de desenvolupament de software.
Tal com ens explica Modesto San Juan, aquesta eina ens permet:
- Dormir tranquils.
- Tenir la documentació compilada.
- Enfrontar-nos al disseny.
- Com a element de retenció i centrar l’enfocament únicament a pensar quin és el comportament a resoldre.
Modesto San Juan desenvolupa codi d’exemple durant la xerrada, mostrar-nos les seves tècniques/receptes a l’hora de realitzar el cicle de TDD, que ens poden ser útils:
- Naming tests on els tests parlin el domini de negoci.
- Els comentaris dins del codi solen indicar que el nostre codi no explica bé que fa.
- En lloc d’utilitzar l’estructura del codi de test la triple AAA (Arrange-Act-Assert), utilitzar Given-When-Then.
- Utilitzar les eines de test que ens donin més semàntica de negoci, en cas conrari és recomanable crear-les.
- Abans d’escriure codi, de test, pensar en com enfocar el problema.
- Les eines de BDD (Behaviour Driven Development) a vegades condiciona la parametrització del codi. Ens recomana no generar el codi a partir de l’especificació de BDD.
- Evitar la fragilitat del codi de test, desvinculant la creació d’objectes en cada test.
- Utilitzar el patró de disseny Builder, per crear els objectes de tests.
- Evitar SQL únics en els tests d’integració. Cada test ha de ser el propietari de la transaccionalitat del test, insert de les dades necessàries per al test a la BD i en sortir fer un rollback. Molts frameworks de tests ens faciliten aquest comportament.
Us recomanem veure la xerrada completa per entendre l’explicació darrera de la recepta.
Random testing by Pedro Moreira
Els que desenvolupem usant TDD sovint ens trobem en la incòmoda situació de, tot i tenir el nostre codi cobert de proves, seguir trobant bugs que no estan coberts. Llavors ens adonem que no hem provat totes les combinacions possibles, però com les provem totes si són infinites o simplement són masses per escriure-les?
El TDD clàssic, que Pedro Moreira anomena Specification by Example, justament mostra això. Escrivim casos concrets i implementem el codi necessari per satisfer aquests exemples, la qual cosa ens aporta un codi senzill i centrat a resoldre els problemes del nostre negoci.
Per aquest motiu, presenta test amb inputs aleatori, el que ell anomenar Spefication by Hypothesis; sota els quals, el nostre codi ha de seguir funcionant. Aquest fet provoca un canvi en la forma de programar; ja no programem per complir/satisfer exemples, sinó propietats. Aquestes propietats, sovint relacionades amb l’àmbit matemàtic (com ara la consistència, la idempotència, la simetria…) provoquen que el nostre codi sigui més robust, però també més elaborat de pensar.
La xerrada, d’escolta obligatòria, dóna molts exemples pràctics i frameworks amb els quals programar Property-based Tests, així com els generadors aleatoris, filtres i reductors necessaris per a realitzar aquest tipus de proves.
Conclusions
Tant per en Josefran, que ja és més veterà en aquest àmbit; com pe mi, n’Eduard que justament m’inicio; ha estat una experiència que certament recomanaríem. No només per l’oportunitat de conèixer el que fan actualment empreses que es dediquen al desenvolupament de software a mesura, sinó també per l’enriquiment personal que comporta conèixer a persones a les quals els apassiona el mateix que fem nosaltres i poder discutir i reflexionar sobre els mateixos problemes que ens inquieten.