Experiențe de programare Android cu câștiguri grele

Acest post, așa cum spune Kent Beck în cartea sa „Implementing Patterns”, „se bazează pe o premisă destul de fragilă, potrivit căreia codul bun contează…”. Cu toții știm că codul curat contează așa cum a trebuit să ne ocupăm atât de mult cu lipsa lui. La fel și Kent.

Kent Beck

Costul total al deținerii unui mess

În urmă cu câțiva ani, ca fiecare dezvoltator naiv de Android care lucra într-o etapă inițială de pornire în India, am încercat să „hack” problemele reale din lumea întreagă, să „perturbe industria” și să pun un „pas în univers”. Fără să aibă grijă în lume de proiectarea sau arhitectura bună a software-ului, am început să scriu cod pentru a construi o aplicație Android care, într-o bună zi, va deveni una dintre cele mai mari aplicații de îngrijire a consumatorilor din India.

Sprint după sprint, hack după hack, funcțiile au fost construite într-un ritm nebun. Construi. Măsura. Învăța. Timpul de comercializare a fost important și fiecare zi a contat. Timpul a trecut, creșteam la un nivel de 1 membru al echipei la fiecare 6 luni și aplicația a atins nota de milioane de descărcări.

Descărcările și evaluarea magazinului Google Play a aplicației noastre.

Până în acest moment, aplicația încetase să mai fie banală și devenise un client cu mai mulți chiriași, chiar dacă asta este un lucru. Caracteristici care ar dura ore în care am început acum au luat zile, uneori săptămâni. Fiecare activitate a fost de peste 1000 de linii de cod spaghete, deoarece Android în mod inerent nu-și face prea multe griji cu privire la separarea preocupărilor. Costul total al deținerii unei încurcări ne-a încetinit semnificativ.

Android Conundrum

Codul arăta urât, Activitățile au gestionat totul:

  • Filetat
  • I / O
  • Calcul
  • aspecte
  • Configurarea modificărilor
  • Ce nu

La urma urmei, Activitățile sunt controlori, nu? Sau sunt vizualizări? Nu mai știam.

MVC

Marele reproiectare în cer

Aveam nevoie să proiectăm aplicația într-un mod în care schimbarea unei linii de cod undeva să nu spargă ceva în altă parte. Aplicația trebuia să fie, după cum spune unchiul Bob, „robustă, dar nu rigidă, flexibilă, dar nu fragilă”.

Robert „Unchiul Bob” Martin

Acest lucru a fost atunci când mentorul și prietenul meu Kashif Razzaqui s-au alăturat echipei pentru a ne ajuta să atenționăm mizeria. Marele reproiectare nu s-a întâmplat niciodată, dar am refactat iadul din codul nostru:

  • Am adăugat un strat „serviciu” și am mutat toate codurile non-UI în ele, un serviciu la un moment dat.
  • Am tăiat AsyncTasks și ne-am mutat în ListenableFutures folosind Guava.
  • Am aruncat AsyncHttpClient pentru OkHttp.
  • Dar, mai important, am început să citim mult: Clean Code, Clean Architecture, SOLID, DRY, The Pragmatic Programmer, Java Concurrency In Practica, Domain Driven Design etc.

Curând am început să vedem care sunt beneficiile eforturilor noastre. Productivitatea a crescut, scriam lucrurile mai repede, toată lumea era fericită.

Acest lucru a fost până când ne-am unificat aplicațiile și tot iadul s-a pierdut. Doar faptul că aveți un strat suplimentar de serviciu nu l-a tăiat.

Arta Codului curat

După ce am vizionat videoclipurile Uncle Bob despre Clean Architecture de mai multe ori și am citit multe despre arhitectura de aplicații pentru Android, am decis să experimentez cu modelul de design MVP și RxJava.

După câteva zile de la experimentare, am decis să trecem la RxJava și să implementăm MVP folosind Clean Architecture. Ne-am asigurat că am încapsulat toate straturile din spatele interfețelor și am separat bine problemele.

  • Vizualizarea, de obicei implementată de un fragment, conține o trimitere la prezentator. Singurul lucru pe care îl va face vizualizarea este să apelezi la o metodă de la Prezentator de fiecare dată când există o acțiune de interfață.
  • Prezentatorul este responsabil să acționeze ca omul de mijloc între View și Model. Acesta preia datele din model și le returnează formatat în vizualizare. Dar spre deosebire de MVC tipic, acesta decide, de asemenea, ce se întâmplă atunci când interacționezi cu View.
  • Modelul este doar poarta de acces către stratul de domeniu sau logica de afaceri.
  • Interactorul se ocupă de I / O și este furnizorul de date care trebuie afișate în View.

Acum este mult mai ușor să comutați un strat cu o implementare complet nouă. Redesignarea interfaței de utilizare, parte integrantă a dezvoltării de aplicații Android, a devenit mult mai ușoară. Lucrurile se pot mișca repede fără să se rupă.

Regula cercetașului băiat

Nu este suficient să scrii bine codul, ci trebuie să fie păstrat curat în timp. Faptul vieții este că software-ul are o tendință de entropie. Cu toții am văzut că codul s-a putrezit și s-a degradat de-a lungul timpului, așa că am împrumutat regula simplă a cercetașilor băieți: „Lăsați campul mai curat decât l-ați găsit.

Dacă am verificat cu toții codul nostru puțin mai curat decât atunci când l-am verificat, pur și simplu nu puteam să putrezească. Curățarea nu trebuie să fie ceva mare. Schimbați un nume variabil în mai bine, descompuneți o funcție care este puțin prea mare, eliminați un pic mic de duplicare, curățați o instrucțiune compusă dacă.

Concluzie

Modul nostru de a crea o aplicație scalabilă poate să nu fie „corect” și s-ar putea să nu fiți de acord cu această postare. Până la urmă, nu toți artiștii marțiali sunt de acord cu privire la cea mai bună artă marțială sau cea mai bună tehnică din interiorul uneia;)

Există multe abordări diferite față de MVP și o mulțime de soluții interesante pentru a-l adapta la Android. Singurul fapt pe care nu îl putem nega este faptul că Clean Code contează și pur și simplu nu îl poți mătura sub un covor.

Acest post împrumută foarte mult din Codul curat al unchiului Bob și fură titlul din discuția Droidcon a lui Kashif din 2011.

Dacă Codul curat contează pentru tine, hai să vorbim :) Twitter: @_arunsasi LinkedIn: https://www.linkedin.com/in/arunsasidharan

Dacă ți-a plăcut această postare, te rog să lovești inima mică! ❤