Hardt opptjente Android-programmeringsopplevelser

Dette innlegget, som Kent Beck sier i sin bok Implementation Patterns, “er basert på en ganske skjør forutsetning om at god kode betyr noe…”. Men vi vet alle at ren kode betyr noe, da vi har måttet håndtere så lenge med mangelen. Og det gjør Kent.

Kent Beck

Den totale kostnaden for å eie et rot

For noen år siden, som alle naive Android-utviklere som jobbet i en oppstart i et tidlig stadium i India, prøvde jeg å "hacke" problemer i den virkelige verden, for å "forstyrre bransjen" og å sette en "bul i universet". Uten omsorg i hele verden om god programvaredesign eller arkitektur, begynte jeg å skrive kode for å bygge en Android-app som en dag skulle bli en av de største forbrukerheath-care-appene i India.

Sprint etter sprint, hack etter hack, funksjoner ble bygget i et sint rush. Bygge. Måle. Lære. Tid til marked var viktig og hver dag betydde noe. Tiden fløy, vi vokste med en hastighet på 1 teammedlem hver 6. måned og appen hadde nådd million nedlastingsmerket.

Nedlastinger og vurdering av Google Play-butikken til appen vår.

På dette tidspunktet hadde appen sluttet å være triviell, og den hadde blitt en klient med flere leietakere, hvis det til og med er en ting. Funksjoner som ville ta timer da vi startet nå, tok dager, noen ganger uker. Hver aktivitet var over 1000 linjer med spaghettikode, da Android iboende ikke bekymrer seg for mye om atskillelsen av bekymringer. De totale kostnadene ved å eie et rot hadde redusert oss betydelig.

Android Conundrum

Koden så stygg ut, Aktiviteter klarte alt:

  • Threading
  • I / O
  • Computation
  • oppsett
  • Konfigurer endringer
  • Hva ikke

Tross alt er aktiviteter kontrollører, ikke sant? Eller er de synspunkter? Jeg visste ikke mer.

MVC

Grand Redesign In The Sky

Vi trengte å designe appen på en slik måte at å endre en kodelinje et sted ikke ødelegger noe annet sted. Appen måtte være, som onkel Bob sier, “robust, men ikke stiv, fleksibel, men ikke skjør”.

Robert “onkel Bob” Martin

Dette var da min mentor og venn Kashif Razzaqui ble med på teamet for å hjelpe oss med å lindre rotet. Den storslåtte redesigningen skjedde aldri, men vi refakturerte helvete ut av koden vår:

  • Vi la til et "service" -lag og flyttet all ikke-UI-koden inn i dem, en tjeneste av gangen.
  • Vi humret AsyncTasks og flyttet til ListenableFutures ved hjelp av Guava.
  • Vi dumpet AsyncHttpClient for OkHttp.
  • Men enda viktigere, vi begynte å lese mye: Clean Code, Clean Architecture, SOLID, DRY, The Pragmatic Programmer, Java Concurrency In Practice, Domain Driven Design, etc.

Snart begynte vi å se fordelene med vår innsats. Produktiviteten økte, vi skrev ting raskere, alle var glade.

Dette var før vi forenet appene våre og alle helvete gikk tapt. Bare det å ha et ekstra servicelag kuttet det ikke.

Kunsten å rense koden

Etter å ha sett onkel Bobs videoer om Clean Architecture flere ganger og lest mye på Android-app-arkitektur, bestemte jeg meg for å eksperimentere med MVP-designmønsteret og RxJava.

Noen dager etter eksperimenteringen bestemte vi oss for å bytte til RxJava og implementere MVP ved hjelp av Clean Architecture. Vi sørget for at vi lagde inn alle lagene bak grensesnitt og skilte bekymringene godt.

  • Visningen, vanligvis implementert av et fragment, inneholder en henvisning til programlederen. Det eneste visningen vil gjøre er å ringe en metode fra Presentatøren hver gang det er en grensesnitthandling.
  • Presentatøren er ansvarlig for å fungere som den midterste mannen mellom View og Model. Den henter data fra modellen og returnerer de formatert til visningen. Men i motsetning til den typiske MVC, bestemmer den også hva som skjer når du samhandler med visningen.
  • Modellen er bare porten til domenelaget eller forretningslogikken.
  • Interaktoren tar for seg I / O og er leverandøren av data som skal vises i visningen.

Nå er det mye lettere å bytte ut ett lag med en helt ny implementering. Å omdesigne brukergrensesnittet, en del av Android-apputvikling, har blitt mye enklere. Ting kan endelig bevege seg raskt uten å bryte.

Guttespeiderstyret

Det er ikke nok å skrive kode godt, koden må holdes ren over tid. Faktum med livet er at programvare har en tendens til entropi. Vi har alle sett kode råtne og forringe over tid, så vi lånte de enkle guttespeidere regelen: "La campingplassen være renere enn du fant den."

Hvis vi alle sjekket inn koden vår litt renere enn da vi sjekket den ut, kunne koden rett og slett ikke råtne. Opprydningen trenger ikke å være noe stort. Endre ett variabelnavn til det bedre, bryte opp en funksjon som er litt for stor, fjern en liten duplisering, rydd opp en kompositt hvis setning.

Konklusjon

Vår måte å bygge en skalerbar app på er kanskje ikke "riktig", og du er kanskje ikke enig i dette innlegget. Tross alt er ikke alle kampsportkunstnere enige om den beste kampsporten, eller den beste teknikken innen en;)

Det er mange forskjellige tilnærminger mot MVP og mange interessante løsninger for å tilpasse den til Android. Det faktum at vi ikke kan benekte er at ren kode betyr noe, og du bare ikke kan feie den under et teppe.

Dette innlegget låner tungt fra onkel Bobs Clean Code og stjeler tittelen fra Kashifs Droidcon-tale fra 2011.

Hvis Clean Code betyr noe for deg, la oss chatte :) Twitter: @_arunsasi LinkedIn: https://www.linkedin.com/in/arunsasidharan

Hvis du likte dette innlegget, kan du slå det lille hjertet! ❤