Hårdförtjänade Android-programmeringsupplevelser

Detta inlägg, som Kent Beck säger i sin bok Implementation Patterns, "är baserat på en ganska bräcklig förutsättning att god kod betyder ...". Men vi vet alla att ren kod är viktig eftersom vi har varit tvungna att ta itu med så länge med dess brist. Och det gör Kent.

Kent Beck

Den totala kostnaden för att äga ett röra

För några år sedan försökte jag, liksom alla naiva Android-utvecklare som arbetade i ett tidigt skede i Indien, att "hacka" verkliga problem i världen, "störa branschen" och sätta en "tand i universum". Utan vård i världen om bra programvarudesign eller arkitektur började jag skriva kod för att bygga en Android-app som en dag skulle bli en av de största apparna för heath-care-produkter i Indien.

Sprint efter sprint, hack efter hack, funktioner byggdes i en galna rusning. Bygga. Mäta. Lära sig. Tid till marknad var viktig och varje dag spelade någon roll. Tiden passerade, vi växte med en gruppmedlem var 6: e månad och appen hade nått miljoner nedladdningsmarkeringar.

Vår apps nedladdningar och betyg av Google Play-butiken.

Vid denna tid hade appen slutat att vara trivial och den hade blivit en klient med flera hyresgäster, om det till och med är en sak. Funktioner som skulle ta timmar när vi började nu tog dagar, ibland veckor. Varje aktivitet var 1000+ rader med spagettikod eftersom Android i sig inte oroar sig för mycket om separationen av oro. Den totala kostnaden för att äga en röra hade betydligt bromsat oss.

Android Conundrum

Koden såg ful ut, aktiviteter hanterade allt:

  • Threading
  • I / O
  • Beräkning
  • layouter
  • Konfigurera ändringar
  • Vad inte

När allt kommer omkring är aktiviteterna kontrollörer, eller hur? Eller är de åsikter? Jag visste inte längre.

MVC

Grand Omdesignen i himlen

Vi behövde utforma appen på ett sätt som att ändra en kodrad någonstans inte bryter något någon annanstans. Appen måste vara, som farbror Bob säger, "robust men inte styv, flexibel men inte ömtålig".

Robert “Uncle Bob” Martin

Det var när min mentor och vän Kashif Razzaqui gick med i teamet för att hjälpa oss att lindra röran. Den storslagna omdesignen har aldrig hänt, men vi återinfekterade helvetet ur vår kod:

  • Vi lägger till ett "service" -lager och flyttade all icke-UI-kod till dem, en tjänst i taget.
  • Vi chuckade AsyncTasks och flyttade till ListenableFutures med hjälp av Guava.
  • Vi dumpade AsyncHttpClient för OkHttp.
  • Men ännu viktigare, vi började läsa mycket: Clean Code, Clean Architecture, SOLID, DRY, The Pragmatic Programmer, Java Concurrency In Practice, Domain Driven Design, etc.

Snart började vi se fördelarna med våra ansträngningar. Produktiviteten ökade, vi skrev saker snabbare, alla var nöjda.

Det var tills vi förenade våra appar och all helvetet blev förlorad. Att bara ha ett extra servicelagret skar inte det.

Konsten att rena koden

Efter att ha tittat på farbror Bobs videor om Clean Architecture flera gånger och läst en hel del på Android-apparkitekturen, bestämde jag mig för att experimentera med MVP-designmönstret och RxJava.

Några dagar efter experimentet beslutade vi att byta till RxJava och implementera MVP med Clean Architecture. Vi såg till att vi inkapslade alla lager bakom gränssnitt och separerade bekymmerna väl.

  • Vyn, vanligtvis implementerad av ett fragment, innehåller en hänvisning till presentatören. Det enda som vyn kommer att göra är att ringa en metod från presentatören varje gång det finns en gränssnittshandling.
  • Presentatören ansvarar för att fungera som den mellersta mannen mellan View och Model. Den hämtar data från modellen och returnerar den formaterad till vyn. Men till skillnad från den typiska MVC, bestämmer den också vad som händer när du interagerar med vyn.
  • Modellen är bara porten till domänskiktet eller affärslogiken.
  • Interaktorn hanterar I / O och är leverantören av data som ska visas i vyn.

Nu är det mycket lättare att byta ut ett lager med en helt ny implementering. Att designa UI, en del av Android-apputvecklingen, har blivit mycket enklare. Saker kan äntligen gå snabbt utan att gå sönder.

Pojkespetsregeln

Det räcker inte med att skriva kod väl, koden måste hållas ren över tid. Livets faktum är att mjukvara har en tendens till entropi. Vi har alla sett kod ruttna och försämras över tid så vi lånade de enkla pojkespeiderna regeln: "Lämna campingen renare än du hittade den."

Om vi ​​alla checkade in vår kod lite renare än när vi checkade ut den, kunde koden helt enkelt inte ruttna. Rensningen behöver inte vara något stort. Ändra ett variabelnamn till det bättre, dela upp en funktion som är lite för stor, eliminera en liten dubblett, rensa upp en komposit om uttalande.

Slutsats

Vårt sätt att bygga en skalbar app är kanske inte "korrekt" och du kanske inte håller med om det här inlägget. När allt kommer omkring, är inte alla kampsportkonstnärer överens om den bästa kampsporten eller den bästa tekniken inom en;)

Det finns många olika tillvägagångssätt för MVP och många intressanta lösningar för att anpassa den till Android. Det faktum att vi inte kan förneka är att Clean Code är viktig och att du bara inte kan sopa den under en matta.

Detta inlägg lånar mycket från farbror Bobs Clean Code och stjäl titeln från Kashifs Droidcon-samtal från 2011.

Om Clean Code är viktig för dig, låt oss chatta :) Twitter: @_arunsasi LinkedIn: https://www.linkedin.com/in/arunsasidharan

Om du gillade det här inlägget, vänligen slå det lilla hjärtat! ❤