La importància de les arquitectures modulars en les aplicacions mòbils

Quan es desenvolupa una aplicació mòbil és important plantejar bé la seva arquitectura tècnica des d’un començament. Sovint moltes empreses se solen centrar únicament en aspectes com la experiència d’usuari, la usabilitat o el disseny, pero se sol deixar de banda la qualitat del codi o conceptes com mantenibilitat i escalabilitat, entre d’altres.

El resultat és una aplicació que inicialment compleix les expectatives tant de la pròpia empresa com dels usuaris finals, pero que a llarg termini es converteix en una cosa difícil de mantenir, difícil d’estendre amb noves funcionalitats i un projecte en el que ningú vol treballar. En aquest article intentarem analitzar aquestes situacions i com intentar evitar-les.

Una arquitectura és un conjunt d’elements i decisions que defineixen com deu ser (i evolucionar) l’estructura interna del codi d’una aplicació. Aquest concepte no és específic de les aplicacions mòbils sinó que fa molts anys que està present en molts projectes de software de qualsevol tecnologia.

En el cas concret de les apps per a iOS i Android, una arquitectura és la forma en què s'estructuren les diferents vistes, el codi associat a aquestes, els recursos gràfics, la lògica de negoci, els models de dades, la comunicació amb serveis i bases de dades i la persistència de dades, entre altres. També descriu com s'han de comunicar els diferents elements que formen part de l'estructura d'una aplicació.

És bastant habitual que en les aplicacions mòbils no es tingui tan en compte el disseny tècnic i que prevalguin altres aspectes. És important no passar per alt com una arquitectura modular pot beneficiar una aplicació mòbil si el projecte és mitjanament gran. En el cas d'aplicacions més petites, l'ús d'aquesta mena d'arquitectures seria considerat sobre enginyeria.

Per a entendre-ho, el millor és utilitzar un exemple de la vida quotidiana: imaginem que acabes d'adquirir un terreny i vols construir una casa en ell. Avui dia hi ha una gran varietat d'opcions: cases prefabricades, per mòduls, construcció tradicional, etc.

Quan un es disposa a fabricar una casa o a comprar-ne una que ja estigui feta, es fixa en diversos aspectes com poden ser: tipus de materials que s'utilitzaran, qualitat d'aquests, cost que representen per al conjunt de l'obra, durabilitat i altres temes de major o menor interès.

Segons les eleccions que es realitzin, la casa que construïm serà una casa de luxe o una casa normal, durarà 10 anys o en durarà 200, etc. No significa que una sigui millor que l'altra, sinó que hem de tenir en compte la quantitat d'anys que volem viure en ella o si tenim pensat renovar-la per complet amb el pas del temps. Hem d'assegurar-nos que el projecte compleix les nostres expectatives.

Si només ens centrem en que quedi bonica i sigui funcional però no tenim en compte elements clau com els fonaments, la qualitat de les parets i altres, segurament tindrem problemes greus a mesura que passem temps vivint en aquest habitatge: humitats, sorolls de l'exterior, goteres… i una infinitat de problemes.

T'imagines una casa on el vàter estigui a la cuina i el bany tingui un forn? Segur que no viuries en aquest habitatge o com a mínim no podries anomenar-lo llar. Però amb un codi no som capaços de veure aquestes coses si no tenim coneixement tècnic; segurament a la teva aplicació tens un forn al bany.

Podem tenir una aplicació que sigui bonica i funcional per al seu llançament, però per dins el codi pot no ser òptim i tenir moltes funcionalitats acoblades. En aquest escenari, estendre aquest mateix codi amb noves funcions o mantenir-lo i buscar els seus errors per a solucionar-los es converteix cada vegada en una tasca més difícil. Seguint l'exemple anterior, reubicar el vàter al bany i el forn a la cuina no és tan simple com moure els elements de lloc, sinó que requereix canviar gran part de la instal·lació.

És un factor que no sols impacta al projecte sinó també a la rotació del personal tècnic.

Que les arquitectures no es pensin bé des d'un principi no sols provoca problemes per als desenvolupadors, sinó també per a les pròpies empreses. Quan un projecte no s'ha plantejat bé des d'un principi i se li demana a algú que continuï estenent el seu funcionament, al final acaba generant frustració perquè les coses van cada vegada pitjor. És molt difícil estructurar alguna cosa que inicialment ja estava mal plantejada, per moltes hores que es dediquin a refactoritzar codi i a reescriure’n unes certes parts.

Aquesta frustració sol acabar en problemes entre membres de l'equip (habitualment entre persones tècniques i no tècniques), per la incapacitat de transmetre i fer entendre als stakeholders que l'arquitectura de l'aplicació no es va plantejar bé des del principi. Al final, com tot en la vida quan alguna cosa no funciona, s'acaba trencant per complet i les persones acaben marxant. Cada vegada que una persona de l'equip se’n va, no sols se’n va un recurs sinó que acaba marxant tot el coneixement i l'experiència d'aquesta persona.

Sol ser habitual pensar que amb una persona més sènior o amb més experiència solucionarem el problema, ja que reescriurà parts del codi que no estiguin bé i així ja no hi haurà frustració. Però normalment s'aconsegueix l'efecte contrari: quanta més experiència té un professional, més fàcilment s'adona dels problemes estructurals d'una aplicació i segurament acaba abandonant el vaixell abans que un perfil més júnior, que trigarà més temps a adonar-se de la situació.

És un peix que es mossega la cua, mentre els usuaris finals continuen esperant actualitzacions amb noves funcions i correccions d'errors que mai arriben.

L'única solució possible passa per reescriure íntegrament l'aplicació, però canviant el procés. Si no vas tenir en compte el disseny tècnic quan es va començar el projecte, és el moment de fer-ho si decideixes començar de zero. Si intentes reescriure parts o solucionar alguns petits defectes, la base del problema sempre serà aquí. És com intentar solucionar un problema de convivència sense que totes dues parts reconeguin els seus errors amb sinceritat, tornarà a aflorar de nou amb el temps.

Avui dia hi ha una tendència en auge: les arquitectures modulars. No són una moda passatgera sense més, perquè les arquitectures modulars vénen a solucionar dos problemes principals: la mantenibilitat i l'escalabilitat. Vegem com ho fan.

Una arquitectura modular és aquella que permet dividir una aplicació en diversos mòduls. Un mòdul és un subconjunt d'una aplicació que té:

• Una responsabilitat única, només una
• Un comportament funcional determinat i cap més
• La capacitat de comunicar-se amb altres mòduls però sense conèixer-los per complet
• La capacitat de canviar el seu interior sense afectar l'exterior

Aquest tipus d'arquitectures utilitzen una tècnica anomenada divideix i venceràs, que consisteix a dividir un problema molt gran (una gran aplicació) en fragments molt petits i específics. D'aquesta manera, cada vegada que es fa un d'aquests mòduls és com començar un projecte de zero: si alguna cosa no funciona bé, pots fer-ho de nou.

La principal diferència amb una arquitectura tradicional és que els diferents mòduls poden usar-se i comunicar-se entre ells, però no han de conèixer-se. D'aquesta manera, és relativament senzill canviar una peça que no funciona per una altra, ja que la resta de peces sabran comunicar-se amb la nova immediatament. A nivell tècnic, la descripció d'aquesta arquitectura es diu que segueix els principis SOLID, dels quals segur has sentit parlar amb anterioritat

Com tot en la vida, les arquitectures modulars tenen avantatges però també inconvenients. Vegem quins són:

Avantatges més rellevants

• Permeten refer parts que no funcionen sense afectar la resta.
• Permeten paral·lelitzar més el desenvolupament una vegada que la base tècnica està assentada.
• Faciliten el manteniment en estar dividides en peces més petites i menys complexes.
• Milloren la felicitat de l'equip a llarg termini ja que no generen tanta frustració.
• Permeten adaptar-se ràpidament a noves funcionalitats dels sistemes operatius (p. ex. els “App Clips” recentment anunciats per Apple).

Inconvenients més rellevants

• Requereixen un major esforç inicial: la inversió econòmica que necessiten respecte a una arquitectura tradicional és bastant més elevada. Principalment perquè es necessiten perfils amb molta experiència i s'ha de dedicar molt de temps a escriure documentació tècnica i a realitzar anàlisis tècniques complexos que donin solucions a les necessitats de negoci a llarg termini.
• Requereixen un monitoratge constant: per a evitar que s'acabi distorsionant el plantejament inicial, és fonamental monitorar periòdicament l'estat del codi, que es compleixin les directrius marcades, etc. Els equips que solen fer aquestes tasques solen denominar-se oficines tècniques. No és necessari que estiguin formats per moltes persones, però sí que és estrictament necessari que existeixin.

A Opentrends tenim una sòlida experiència desenvolupant arquitectures modulars per a aplicacions de grans clients.

Si estàs pensant a començar un nou projecte que tindrà un llarg recorregut o la teva empresa es troba en una situació com la que hem descrit en aquest article (problemes de mantenibilitat, impossible afegir noves funcions, alta rotació de personal tècnic, etc.), podem ajudar-te a evitar repetir de nou els mateixos errors. Posa't en contacte amb nosaltres i estarem encantats d'ajudar-te.