Per què el teu producte necessita un bon codi per funcionar? | el deute tècnic
Què és el deute tècnic?
Molts coneixem el concepte o el significat de deute en sentit econòmic. Tots hem prestat diners (o n’hem demanat), i la majoria de nosaltres haurem fet servir una targeta de crèdit a la nostra vida.
Un deute, en termes econòmics simples, és un compromís de pagament. Si no es tornen aquests diners, les diferents entitats financeres activen interessos, que es poden acumular, cosa que pot provocar seriosos problemes a la part prestada. L’acumulació d’interessos va carregant cada cop més una motxilla que dificulta el progrés.
Si traslladem aquesta definició al cicle de vida de l’aplicació, aquest deute implica un codi que, per motius de pressió a l’entrega o per decisions funcionals, no s’ha implementat de la millor manera, i acaba precisant una refactorización posterior. És el resultat de prioritzar un lliurament ràpid per sobre del codi òptim. D’això se’n diu el deute tècnic.
Des que es va introduir el concepte “Technical Debt” per Ward Cunningham a principis dels noranta, moltes vegades els equips de desenvolupament s’han referit al terme com aquell mal que cal evitar costi el que costi durant el desenvolupament d’un projecte. No obstant, la idea que expressava Cunningham era més àmplia: ell defensa que una mica de deute és bo i necessari. Tal com ell ho va expressar, “una mica de deute agilitza el desenvolupament en tant que aquest sigui retornat reescrivint el codi”.
Quin tipus de deute hi ha?
Martin Fowler, un dels gurus de les bones pràctiques en el desenvolupament de programari, va establir un quadrant per representar els diferents tipus de deute tècnic en funció del context i la intenció. Aquest quadrant és molt útil mostrant que no sempre és dolent generar deute si es fa a canvi de tenir entregues més ràpides.
Segons Fowler, definim els deutes tècnics com:
- Prudent i deliberada: Succeeix quan l’equip és conscient que s’estan acumulant “interessos” al deute per centrar-se en un lliurament primerenc, però la decisió és acceptable si es gestiona més endavant. És una estratègia molt equilibrada sempre que més endavant li dediquem temps a reparar aquest deute.
- Prudent i inadvertit: L’equip aprèn quina hauria de ser la solució correcta després de la implementació. Com en el cas anterior, si després aquest canvi necessari s’implementa, s’elimina aquest deute adquirit inconscientment.
- Imprudent i deliberada: Quan l’equip coneix les conseqüències i evita deliberadament gestionar-les, prioritzant únicament la velocitat per sobre de la qualitat. Sens dubte, la pitjor estratègia que es podria tenir en el desenvolupament de programari.
- Imprudent i inadvertit: quan l’equip no té experiència i implementa la solució a cegues. Un escenari totalment indesitjable.
Qualsevol equip que estigui al quadrant de l’esquerra, el de les decisions imprudents, deliberades o inadvertides, acabarà generant una aplicació que, si bé a l’inici li permetrà lliurar funcionalitats molt ràpidament, a causa de la creixent complexitat del codi els equips de desenvolupament tindran cada cop més dificultats per escalar la funcionalitat o simplement solucionar incidències, les que es poden veure multiplicades si no s’han pres les decisions d’arquitectura adequades durant la implementació.
Com gestionar el deute?
Si un Product Owner deixa que s’acumuli massa deute, el projecte sencer podria caure pel pes d’aquest. Quan fer qualsevol canvi, millora o fins i tot resoldre petites incidències es torna una tasca llarga, complicada i tediosa. En conseqüència, la metàfora dels diners i els interessos deixa de ser-ho, ja que el preu econòmic de mantenir un producte amb un alt deute tècnic s’incrementa dramàticament amb el temps.
El deute s’associa únicament a consideracions tècniques del codi o la solució tècnica i, per definició, el Product Owner tendeix a estar més focalitzat en els aspectes funcionals. Per això és especialment important que sàpiga escoltar l’equip tècnic quan li indiqui que certa decisió funcional comporta deute o que se n’ha acumulat massa.
Per tal de mantenir el compte del deute que comporta un projecte, cada cop que es troba un punt del codi o funcionalitat que es tradueix en augmentar el deute, cal afegir una tasca al Backlog per “pagar” aquest deute més endavant.
Quan es visibilitza i estima, el deute tècnic es fa més difícil d’ignorar i passa a planificar-se en les iteracions de desenvolupament posteriors per anar arreglant aquestes deficiències o dreceres que s’han hagut d’introduir per certs requeriments funcionals que requerien una entrega ràpida.
Com arreglar el deute?
No hi ha eines específiques per “reduir” el deute tècnic d’un codi. Cal parlar de tot el ventall d’eines i mètodes que comprenen un ampli espectre d’àrees dins del cicle de vida i el desenvolupament d’una aplicació.
Ens trobem sovint buscant solucions per a l’arquitectura de l’aplicació, tipus de base de dades, processos d’integració i desplegament continu, tests automàtics, seguretat, protocols, i una llarga llistes d’àrees en què hem de prendre la decisió més adequada. Aquí entra en joc el nostre coneixement de les eines amb què treballem, el temps de què disposem, així com les necessitats funcionals, que sempre són el més prioritari.
Hem d’analitzar les diferents opcions que hi ha a cada moment per determinar la solució òptima i estàndard a un problema, des dels principis SOLID, patrons de disseny y codi net, a frameworks de desenvolupament, passant per infinitat de llibreries, serveis o llenguatges més adequats per a cada necessitat.
Aplicar les eines i patrons adequats ens permet refactoritzar el nostre codi per anar eliminant aquest deute progressivament i reduir-lo a uns nivells acceptables per mantenir una evolució i manteniment sa del nostre producte.
Què hauries de conèixer sobre el deute tècnic?
Quan es desenvolupa un programari, cal assegurar un equilibri entre els participants del projecte, des de desenvolupadors a negoci. Això implica un balanç adequat del triangle de temps, qualitat i cost.
Cada part de l’equip pressiona feia les seves necessitats, però la qualitat, més enllà que no hi hagi bugs a l’aplicació, no és sempre la més prioritària ja que moltes vegades no és visible des de negoci.
Això no obstant, no mantenir la qualitat del codi acabarà repercutint en els costos extra, que només augmentaran si no es redueix aquest deute per mitjà de refactoritzacions del codi.
En definitiva, com estigui fet el codi determinarà la facilitat perquè aquest producte sigui escalable, vendible, mantenible, testejable o traspassable a altres equips de desenvolupament. Finalment, afectarà el cost i el temps de lliurament de cada nova funcionalitat, impactant directament en els plans que la teva empresa tingui per al producte si no satisfà els requeriments de cost i temps, ni per descomptat, qualitat.
Trobaràs més articles d’interès al nostre blog.