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

Importància de l'arquitectura tècnica en el desenvolupament d'aplicacions 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 solen centrar-se únicament en aspectes com l'experiència d'usuari, la usabilitat o el disseny, però solen deixar de banda la qualitat del codi o conceptes com mantenibilitat i escalabilitat, entre 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 alguna cosa difícil de mantenir, difícil d'extensió 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 es un conjunto de elementos y decisiones que definen cómo debe ser (y evolucionar) la estructura interna del código de una aplicación. Este concepto no es específico de las aplicaciones móviles sino que hace muchos años que está presente en muchos proyectos de software de cualquier tecnología.

En el cas concret de les apps per a iOS i Android, una arquitectura és la forma en què es 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 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 tant en compte el disseny tècnic sinó que es prioritzen altres aspectes. És important no passar per alt com pot beneficiar una arquitectura modular a una aplicació mòbil si el projecte és prou 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 una casa en ell. 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 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 facin, 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. Cal 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 passi el temps vivint en aquesta vivenda: humitats, sorolls de l'exterior, goteres... i un sense fi 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 se li dediquin a refactoritzar codi i a reescriure certes parts.

Aquesta frustració acostuma a acabar en problemes entre membres de l'equip (normalment 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, acaba trencant-se completament i les persones acaben marxant. Cada vegada que una persona de l'equip marxa, no només marxa un recurs sinó que s'acaba marxant tot el coneixement i l'experiència d'aquella persona.

Sol sovint es pensa que amb una persona més sènior o amb més experiència resoldrem el problema, ja que reescriurà parts de codi que no estiguin ben fetes 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 es dóna compte dels problemes estructurals d'una aplicació i segurament acabarà 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 decides 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 venen 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 més
• La capacitat de comunicar-se amb altres mòduls però sense conèixer-los completament
• La capacitat de canviar el seu interior sense afectar a 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 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 ser utilitzats 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 manera immediata. A nivell tècnic, la descripció d'aquesta arquitectura es diu que segueix els principis SOLID, dels quals segurament 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 refàcils parts que no funcionen sense afectar la resta.
• Permeten paral·lelitzar més el desenvolupament un cop la base tècnica està assentada.
• Faciliten el manteniment al 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 bastant més elevada. Principalment perquè es necessiten perfils amb molta experiència i cal 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í és estrictament necessari que existeixin.