Vaikeasti ansaitut Android-ohjelmointikokemukset

Tämä viesti, kuten Kent Beck sanoo kirjassaan Toteutusmallit, "perustuu melko hauraaseen oletukseen, että hyvällä koodilla on merkitystä ...". Mutta me kaikki tiedämme, että puhdas koodi on tärkeä asia, koska olemme joutuneet käsittelemään niin kauan sen puutteesta. Ja samoin Kent.

Kent Beck

Messin omistamisen kokonaiskustannukset

Muutama vuosi sitten, kuten jokainen naiivi Android-kehittäjä, joka työskentelee varhaisessa vaiheessa käynnistyvässä Intiassa, yritin ”hakata” todellisen maailman ongelmia, ”häiritä teollisuutta” ja laittaa ”loven maailmankaikkeuteen”. Ilman huolta hyvästä ohjelmistojen suunnittelusta tai arkkitehtuurista maailmassa aloin kirjoittaa koodia rakentaaksesi Android-sovelluksen, josta tulisi yhtenä päivänä yksi Intian suurimmista kuluttajan terveydenhuollon sovelluksista.

Sprintti sprintin jälkeen, hakkerointi hakkeroinnin jälkeen, ominaisuudet rakennettiin hulluan kiireeseen. Rakentaa. Mitata. Oppia. Markkinoille saattamisen aika oli tärkeä ja joka päivä tärkeä. Aika lensi, kasvaimme nopeudella 1 joukkueen jäsen 6 kuukauden välein ja sovellus oli saavuttanut miljoonan latauksen merkinnän.

Sovelluksemme Google Play -kaupan lataukset ja luokitus.

Siihen mennessä sovellus oli lakannut olemasta triviaalia ja siitä oli tullut monivuokralainen asiakas, jos siitä edes asia. Ominaisuudet, jotka kestivät tunteja, kun aloitimme nyt, veivät päiviä, joskus viikkoja. Jokainen aktiviteetti oli yli 1000 riviä spagettikoodia, koska Android ei luonnostaan ​​ole huolissaan liikaa huolien erottamisesta. Sotun omistamisen kokonaiskustannukset olivat hidastaneet meitä huomattavasti.

Android-pehmo

Koodi näytti ruma, Aktiviteetit hallitsivat kaikkea:

  • ketjuttaminen
  • I / O-
  • laskeminen
  • ulkoasuja
  • Määritä muutokset
  • Mitä ei

Loppujen lopuksi aktiviteetit ovat ohjaimia, eikö niin? Vai ovatko ne näkymiä? En tiennyt enää.

MVC

Suuri suunnitteleminen taivaalla

Piti suunnitella sovellus siten, että koodirivin muuttaminen jonnekin ei rikkoa jotain muualla. Sovelluksen piti olla, kuten Bob-setä sanoo, ”vankka mutta ei jäykkä, joustava mutta ei hauras”.

Robert “setä Bob” Martin

Silloin mentorini ja ystäväni Kashif Razzaqui liittyivät joukkueeseen auttamaan meitä lievittämään sotkua. Suuri suunnitteleminen ei koskaan tapahtunut, mutta reforeoimme helvetin koodistamme:

  • Lisäsimme “palvelutaso” ja siirrimme kaikki ei-käyttöliittymäkoodit niihin, yksi palvelu kerrallaan.
  • Chucked AsyncTasks ja siirtyi ListenableFutures käyttäen Guava.
  • Pudotimme AsyncHttpClient-sovelluksen OkHttp: lle.
  • Mutta mikä tärkeintä, aloimme lukea paljon: puhdas koodi, puhdas arkkitehtuuri, SOLID, DRY, käytännöllinen ohjelmoija, Java-samanaikaisuus käytännössä, verkkotunnusohjattu suunnittelu jne.

Pian aloimme nähdä ponnistelujemme edut. Tuottavuus parani, kirjoitimme asioita nopeammin, kaikki olivat iloisia.

Tämä oli kunnes yhdistämme sovelluksemme ja kaikki helvetti menettää. Pelkkä ylimääräinen palvelutaso ei leikannut sitä.

Puhtaan koodin taide

Katseltuaan Bob-setän videoita puhtaasta arkkitehtuurista useita kertoja ja lukenut paljon Android-sovellusarkkitehtuurista päätin kokeilla MVP-suunnittelumallia ja RxJavaa.

Muutaman päivän kuluttua kokeilusta päätimme siirtyä RxJavalle ja toteuttaa MVP: n Clean Architecture -sovelluksen avulla. Varmisimme, että kapseloimme kaikki kerrokset rajapintojen taakse ja erotimme huolet hyvin.

  • Näkymä, jonka yleensä toteuttaa fragmentti, sisältää viittauksen juontajaan. Ainoa asia, jonka näkymä tekee, on kutsua menetelmä Presenteriltä joka kerta, kun siellä on käyttöliittymätoiminto.
  • Esittelijä on vastuussa toimimasta keskitiehenä Viewin ja Modelin välillä. Se hakee tietoja mallista ja palauttaa ne muotoiltuina näkymään. Mutta toisin kuin tyypillinen MVC, se myös päättää, mitä tapahtuu, kun olet vuorovaikutuksessa Näkymän kanssa.
  • Malli on vain yhdyskäytävä verkkotunnustasolle tai liiketoimintalogiikalle.
  • Interactor käsittelee I / O: ta ja tarjoaa näytössä näytettäviä tietoja.

Nyt on paljon helpompaa vaihtaa yksi kerros kokonaan uudella toteutuksella. Käyttöliittymän uudelleensuunnittelu, Android-sovelluskehityksen olennainen osa, on tullut paljon helpommaksi. Asiat voivat vihdoin liikkua nopeasti rikkomatta.

Scout -sääntö

Ei riitä, että kirjoitat koodia hyvin, koodi on pidettävä puhtaana ajan kuluessa. Elämän tosiasia on, että ohjelmistoilla on taipumus entropiaa. Olemme kaikki nähneet koodin mädäntymisen ja heikentyvän ajan myötä, joten lainsoimme yksinkertaisen partiolais-partiolaisten säännön: "Jätä leirintäalue puhtaammaksi kuin löysit sen."

Jos me kaikki tarkistimme koodimme hieman puhtaammin kuin tarkistaessamme sitä, koodi ei yksinkertaisesti voinut mätä. Siivouksen ei tarvitse olla jotain suurta. Vaihda yksi muuttujan nimi parempaan, hajotta yksi funktio, joka on vähän liian suuri, poista yksi pieni kappale päällekkäisyyksiä, puhdista yksi yhdistelmä, jos lause.

johtopäätös

Tapamme rakentaa skaalattava sovellus ei ehkä ole “oikea”, joten et ehkä ole samaa mieltä tämän viestin kanssa. Loppujen lopuksi kaikki taistelutaiteilijat eivät ole yhtä mieltä parhaasta taistelulajista tai parhaasta tekniikasta;)

MVP: hen on monia erilaisia ​​lähestymistapoja ja paljon mielenkiintoisia ratkaisuja sen mukauttamiseksi Androidiin. Yksi tosiasia, jota emme voi kiistää, on se, että Clean Code on tärkeä asia, etkä voi vain lakaista sitä maton alla.

Tämä viesti lainaa voimakkaasti Bob Uncle Bob -koodista ja varastaa otsikon Kashifin Droidcon-puheesta vuodesta 2011.

Jos puhdas koodi on sinulle tärkeä, keskustellaan :) Twitter: @_arunsasi LinkedIn: https://www.linkedin.com/in/arunsasidharan

Jos pidit tästä viestistä, lyö pieni sydän! ❤