Android Architecture Review – en arkitektur som håller för nästa fem år
En genomgång av hur er Android-app är byggd, med en konkret målarkitektur och en migreringsplan som teamet kan följa utan att stoppa funktionsleveransen.
Kontakta migVanliga signaler på att arkitekturen bromsar
- Teamet är oense om hur nya funktioner ska byggas och varje pull request blir en principdiskussion.
- Ändringar på ett ställe ger oväntade fel på ett annat.
- Ni har både Views och Compose i samma app utan en tydlig linje för vad som gäller.
- State-hanteringen är svår att följa och buggar går inte att återskapa.
- Testerna är långsamma, spröda eller obefintliga eftersom koden är svår att testa.
- Flera team arbetar i samma monolit och blockerar varandra.
När passar en arkitekturgranskning?
Vad ingår
- Genomgång av nuvarande lagerindelning, moduler och beroenderiktningar.
- Bedömning av state management, unidirektionellt dataflöde och Kotlin coroutines/Flow-användning.
- Compose-strategi: migreringsordning, samexistens med Views, designsystem och återanvändning.
- Modulariseringsplan med tydliga gränssnitt och ägarskap per modul.
- Testbarhet: enhetstester, UI-tester, testpyramid och byggtidspåverkan.
- Offline, synkronisering, felhantering och datalager där det är relevant.
- Arbetssätt: kodstandard, granskningsrutiner, definition av klar.
Vad ni får
Ett arkitekturdokument med nuläge, målbild, motiverade vägval och avvägningar, samt en stegvis migreringsplan där varje steg går att leverera separat. Vid behov även referensimplementation av ett vertikalt snitt genom appen som teamet kan kopiera mönstret från.
Tidsram och arbetssätt
En arkitekturgranskning tar normalt en till två veckor, inklusive workshops med teamet. Arbetet görs på distans med en till två workshoppar där målbilden tas fram tillsammans – förankring i teamet är en förutsättning för att planen ska överleva vardagen.
Vanliga frågor
Förespråkar ni en särskild arkitektur?
Nej. Valet styrs av appens storlek, teamets sammansättning och hur ofta ni släpper. Utgångspunkten är Googles rekommenderade arkitektur, anpassad till er verklighet snarare än till en mall.
Måste vi migrera allt till Jetpack Compose?
Nej. Compose och Views kan samexistera under lång tid. Rekommendationen brukar vara att bygga nytt i Compose och migrera befintliga skärmar när de ändå ska ändras.
Kan ni hjälpa oss att genomföra planen också?
Ja, antingen som löpande expertstöd åt teamet eller genom att jag driver de första stegen och sätter mönstret som teamet sedan följer.
Hur hanterar ni multi-modul-projekt?
Modulgränser sätts efter funktion och ägarskap, inte efter tekniskt lager. Planen tar hänsyn till byggtider, beroendegrafen och hur teamen faktiskt arbetar.
Vad skiljer detta från ett Health Check?
Ett Health Check svarar på hur appen mår i dag över hela bredden. En arkitekturgranskning går på djupet i strukturen och levererar en målbild och en plan framåt.
Gäller detta även Android i fordon och inbyggda system?
Ja. Jag har arbetat med Android i fordonsindustrin och med systemnära utveckling ned till drivrutinsnivå, vilket ofta ställer andra krav på arkitekturen än en konsumentapp.
Behöver ni en teknisk målbild att samlas kring?
Beskriv appen och teamet så föreslår jag ett upplägg för granskningen.
Kontakta mig