Excluderea factorului "Motive istorice" in proiectele mobile Android

Astazi voi vorbi despre refactoring, sarcini tehnice, si factorul “motive istorice” sau mai degraba despre cum sa il evitati.

Nov 6, 2018 834
Salut! Este timpul pentru o alta postare nu chiar atat de periodica despre mobile development.

Astazi voi vorbi despre refactoring, sarcini tehnice, si factorul “motive istorice” sau mai degraba despre cum sa il evitati.

De obicei, in special dupa o serie de sprint-uri curajoase, dezvoltatorii intra intr-o perioada unde realizeaza si recunosc activitatile facute pana atunci. Deciziile luate in graba provoaca dezbateri atunci cand oamenii isi beau cafeaua sau doar in comentariile care sunt facute atunci cand vine vorba de revizuirea cerintelor.

De ce se intampla asta?

  • Din cauza lipsei de planificare tehnica
  • Din cauza cerintelor neclare ale analistilor
  • Din cauza viziunilor si obiectivelor care se schimba
  • Din cauza nevoii de “a face totul la timp”

Cum puteti aborda aceasta situatie in asa fel incat sa respectati si programul de dezvoltare?

In primul rand, urmand cateva strategii care sa nu va puna intr-o astfel de situatie. Va impartasesc mai jos cateva idei care m-au ajutat pe mine.

Pastrati totul curat si ordonat

Se poate vorbi foarte mult despre code standards, tab-uri si blank spaces, despre irelevanta MVC sau despre necesitatea urgenta de implementare a MVVM. Este minunat, dar puteti incepe direct de la implementare:

  • LeakCanary – pentru a urmari memory leaks
  • StrictMode – pentru a urmari operatiunile consumatoare de timp, unclosed cursors, etc.

Cel putin, in fiecare dintre debug builds, chiar acum. Si nu va fi nevoie sa depuneti eforturi mari pe ultima suta de metri sau sa descoperiti memory leaks inainte de lansare sa proiectati o solutie dupa lansare.

programare android.jpg


KISS my SOLID YAGNI

Putem vorbi despre numeroase principii si modele de dezvoltare, dar toate vor ramane la stadiul de vorbe, pana in momentul in care veti incepe sa lucrati in conformitate cu anumite reguli.

Incepeti prin a respecta o arhitectura comuna in proiectul vostru, iar asta va va permite:

  • Sa efectuati refactoring-ul sau
  • Sa completati lipsurile in acelasi mod in cadrul intregului proiect si
  • Va ajuta toti membrii echipei sa lucreze pe toate componentele, fara sa existe o impartire stricta

Doar setati-o ca regula pentru Android Views personalizate mai simple, prin declararea si implementarea metodelor cerute prin interfete.

In acelasi timp, incepeti sa implementati Presenters pentru a functiona optiunea View in interfata. Scrieti teste simple in View si Presenter. Veti primi un cod simplu si stratificat.

Aceste nivele din arhitectura sunt necesare pentru angajatii vostri, nu pentru a explora, ci pentru a separa logica UI de logica procesarii datelor.

Incepeti sa scrieti teste, dupa cum am mentionat deja in paragraful anterior

Incepeti de la cele mai mici si mai simple lucruri. De exemplu incepeti prin a verifica daca se afiseaza bara de progres atunci cand este selectata din View sau daca linia apare asa cum era setata.

Este tot ceea ce aveti nevoie pentru a efectua smoke tests . Pentru a satisface nevoile de business, trebuie sa livram produse software cat mai repede, ceea ce creeaza o presiune ridicata asupra echipelor de proiect. Puteti reduce nivelul de presiune si stres prin crearea de teste simple.

Veti sti exact unde pot aparea bug-uri si veti petrece mai putin timp facand debugging.

Totul este asincron, nu exista sincronizare in secolul 21

Incepeti sa va uitati la fiecare eveniment, fiecare functie ca la o sursa potentiala de evenimente asincrone in sistemul vostru.

Invatati Rx Java/Swift/JS. Pur si simplu incepeti sa folositi o abordare reactiva deoarece nu a fost niciodata mai usor sa treceti de la un thread la altul. Acest lucru va va ajuta sa aveti un cod mai rezistent la un set de cerinte care se schimba mereu, interactiuni extra cu partea de back-end sau sa va pregatiti pentru acele momente cand echipa responsabila de server schimba protocolul – pur si simplu adaugati o actiune la Rx chain si salvati „release-ul” vostru.

Daca iti place acest articol, distribuie-l si prietenilor tai!




Mai ai intrebari?
Contacteaza-ne.
Thank you.
Your request has been received.