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

Importància de l'arquitectura tècnica en el desenvolupament d'apps mòbils

Quan es desenvolupa una aplicació mòbil és important plantejar bé la seva arquitectura tècnica des d'un inici. Sovint moltes empreses es solen centrar únicament en aspectes com l'experiència d'usuari, la usabilitat o el disseny, però es 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, però que a llarg termini es converteix en quelcom difícil de mantenir, difícil d'extendre amb noves funcionalitats i un projecte en el qual ningú vol treballar. En aquest article intentarem analitzar aquestes situacions i com intentar evitar-les.

Què és l'arquitectura d'una aplicació mòbil?

Una arquitectura és un conjunt d'elements i decisions que defineixen com ha de 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 programari 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 les mateixes, 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 d'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 sinó que es prioritzin altres aspectes. És important no passar per alt com pot beneficiar una arquitectura modular a una aplicació mòbil si el projecte és mitjanament gran. En el cas d'aplicacions més petites, l'ús d'aquest tipus d'arquitectures seria considerat sobre enginyeria.

Per què cal tenir en compte l'arquitectura des del principi?

Per entendre-ho, el millor és utilitzar un exemple de la vida quotidiana: imaginem que acabes d'adquirir un terreny i vols construir-hi una casa. Avui en 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 dels mateixos, 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 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-hi o si tenim pensat renovar-la completament 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 aquesta vivenda: humitats, sorolls de l'exterior, goteres... i un munt 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ó tinguis 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 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 requereixen canviar gran part de la instal·lació.

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

L'impacte de la rotació en els projectes

Que les arquitectures no es pensin bé des d'un principi no només 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 segueixi 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 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 a la vida quan alguna cosa no funciona, s'acaba trencant per complet i les persones s'acaben marxant. Cada vegada que una persona de l'equip se'n va, no només se'n va un recurs sinó que se'n va tot el coneixement i l'experiència d'aquesta persona.

Sovint és habitual pensar que amb una persona més sènior o amb més experiència solucionarem el problema, ja que reescriurà parts de codi que no estiguin bé i així ja no hi haurà frustració. Però normalment s'aconsegueix l'efecte contrari: com més experiència té un professional, més fàcilment s'adona dels problemes estructurals d'una aplicació i segurament acabi 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.

Què podem fer per millorar aquestes situacions?

L'única solució possible passa per reescriure en la seva totalitat 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 estarà allà. És com intentar solucionar un problema de convivència sense que ambdues parts reconeguin els seus errors amb sinceritat, tornarà a aflorar de nou amb el temps.

Avui en 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.

Què és una arquitectura modular?

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 altre
• La capacitat de comunicar-se amb altres mòduls però sense conèixer-los completament
• 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 de seguida. A nivell tècnic, la descripció d'aquesta arquitectura es diu que segueix els principis SOLID, dels quals segur que has sentit parlar amb anterioritat.

Avantatges i Inconvenients de les arquitectures modulars

Com tot a 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 un cop que la base tècnica està assentada.
• Faciliten el manteniment en estar dividit 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 força 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ècnics complexos que donin solucions a les necessitats de negoci a llarg termini.
• Requereixen una monitorització constant: per evitar que s'acabi distorsionant el plantejament inicial, és fonamental monitoritzar 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.