Redovno održavanje i unapređivanje mobilnih aplikacija

Share

Kodovi, njihove česte izmene, kao i promene članova na izradi projekta u velikoj meri utiču na dugoročne projekte i njihov kvalitet, a utiču i na izradu softvera. Danas, kad u ponudi imamo Ajfon aplikaciju, čiji je prvi red koda zabeležen još novembra 2013. godine, nailazimo na neke manje-više uobičajene probleme u razvoju softvera za svakodnevno poslovanje.

  1. Izmena članova – Jedan od vodećih članova na izradi projekta napušta tim i sa sobom odnosi saznanja koja nigde nisu registrovana
  2. Proširenje osnovnih saznanja – Pojedinac je svestan praktičnijih pristupa od već postojećih rešenja
  3. Zastarelost – Delovi koda su danas prevaziđeni i postoje lakša i praktičnija rešenja koje diktiraju nova oprema i ažuriranje OS

Nakon što je zaživeo razvoj standardne metodologije, prešli smo na agilni razvoj procesa i upravljanje koherentnim EPIC protokolima i sličnim zahtevima. Imali smo izbor da pojačamo stablinost koda na osnovu već postojećih delova koda ili ponovo osmislimo “novi zupčanik” i samim tim refaktorišemo veliki broj međusobno povezanih jezgara. Ovde bih želeo da vam u kratkim crtama pokažem i približim refaktorisanje kodova, čak i kod onih koji su kjučni nosioci logistike i funkcionalnosti jedne aplikacije.

Trenutni dizajn

Redovno Odr Avanje I Unapre Ivanje Mobilnih Aplikacija

Razlozi za ažuriranje ovog pristupa

  • Ne postoji više Core Data sistem jer
    • Hijerarhijom Data modela dobija se jedna jedina tabela za sve objekte potkategorije, a samim tim ima više ulaznih podataka u jednoj jedinoj tabeli podataka
    • Testiranje jedinica, a naročito testovi integracije koji su se odnosili na razmenu unutar baze podataka ukazuju da jedinice u velikoj meri zavise jedna od druge – zbog same prirode jezgra podataka
    • Baza podataka se lako kodira, pa možemo da koristimo jedan izvor podataka i za kodirane podatke koji se trenutno čuvaju u drugačijem obliku ili za podatke koje bi tek trebalo uneti
  • Direktna procena ključnih vrednosti na objektima jezgra podataka vrši se samo radom u okruženju (poslušati obaveštenja o čuvanju objekta).
    • Kontrolor je morao da ima kontrolu nad objektom i operacijama čuvanja koje se tiču entiteta tog objekta.
    • Procena ključnih vrednosti trebalo bi da utiče na otpornost objekta, kako bi sprečila kontrolora da se opet aktivira nakon manipulisanja delom objekta.
  • Promena vrednosti trebalo bi da direktno stavi obaveštenje na interfejs kako bi se što bolje sinhronizovao ishod samog projekta (takođe između uređaja). Kontrolor ne bi trebalo da odlučuje o tome koji tip veb zahteva je neophodan za ažuriranje nekog objekta i njegova propratna svojstva na kraju celog procesa.

Poseban razlog za izmenu bila je i revizija internog koda u februaru. Revizija se ticala izmena broja članova na izradi projekta, kodiranja, zastarelosti koda zbog korišćenja starih arhiva, kao i priprema kako bi se izašlo u susret potrebama korisnika tokom narednih godina.

Refaktorisani dizajn

Planirani zadati dizajn se već dokazao na nekoliko drugih projekata, a koraci koji se nalaze između su rešenja napravljena posebno za aplikacije iOS.

Prednost novog pristupa: sloj veze, a naročito komunikacijski sloj bi trebalo da su slabije upareni sa aplikacijom, a ipak vidljivi korisniku. Ni mi ne želimo da se preterano bakćemo logikom poslovanja operacija CRUD u kontrolorskim klasama ili diferencijacijom REST-Call pristupa u njemu. Ideja: sloj veze i komunikacijski sloj formiraju zaseban logistički nivo kome se može pristupiti putem precizno definisanih opštih metoda. Ukratko: Logika poslovanja biće spakovana u biblioteku koja će zameniti postojeći heterogeni izvor koda.

 

Redovno Odr Avanje I Unapre Ivanje Mobilnih Aplikacija

Uspeh?

Zagarantovan! Testirali smo metod 6 nedelja (uz pomoć 8 stručnih ispitivača) i pronašli 22 problema, od kojih su 3 bila kategorisana kao velika ili kritična. Čak su i dva od ta tri velika/kritična problema bila pronađena i popravljena tokom prvih dana testiranja. Nova biblioteka ima 14.000 linija koda, ne računajući linije koda postojeće aplikacije koja ima pristup biblioteci. Zahvaljujući testiranju unapredili smo izvor koda kako bismo obezbedili pouzdanu osnovu za postojeći projekat. Prednost se ogleda ne samo u dobrom dokumentovanju i specifikacijama interfejsa, već i u sklopu dobro poznatih načina manipulacije i korelacije podataka.

Mali statistički podatak koji potvrđuje ovako veliki uspeh: čak i veoma optimistična predviđanja “Odnosa broja bagova po kodu” prema kojima se očekuju tri kvara na svakih 1.000 linija koda (koja se odnose isključivo na kvalitetna softverska rešenja poput programa za spejs šatlove itd.), dok pesimistične prognoze obično predviđaju 15 do 50 bagova na svakih 1.000 linija koda.

Samim tim smo (sudeći po saznanjima koja do sada imamo, a nakon opsežnih testiranja od nekoliko nedelja) došli do opsega od ispod 2 baga na 1.000 linija koda! Ali, i pred mogućih skrivenih bagova, veoma smo zadovoljni rezultatima.

 

Svi oni koji su zainteresovani za primenu ovakvog procesa refaktorisanja, u prilogu će naći vodič koji će im u tome pomoći korak po korak.

Proces refaktorisanja

Kako biste nastavili sa aplikacijom koja ima specifičan izvor koda (izuzev drugih biblioteka, itd.) od 60.000 linija koda, što je otprilike dokument od 1.300 strana?

Nađi i zameni?

‟Ukloni stari kod i zameni ga novim”

Da, otprilike je tako:

  1. Pronaći klase, funkcije ili svojstva koje bi trebalo zameniti
  2. Mapirati klase i metode za novi dizajn
  3. Zabeležiti one koji bi bile nepodesne zbog novog dizajna
  4. Pronaći preciznu funkciju (koja može lako da se prevede i ugradi) i promeniti svojstva
  5. Dodati Biblioteku projektu
  6. Ukloniti stari kod iz projekta
  7. Iskoristiti našu metodologiju zamene i završiti refaktorisanje osnove sopstvenog koda

1) Pronaći klase, funkcije ili svojstva koje bi trebalo zameniti

Znamo da su stari delovi koda povezani sa Slojem Veze i Komunikacijskim Slojem, pa smo stoga prilično brzo izlistali foldere i klase koji će biti zamenjeni novom bibliotekom. Još je lakše bilo zbog toga što smo imali dobro definisane specifikacije interfejsa, pa smo do detalja znali sve o funkcionalnosti različitih klasa, koji podaci su zaista neophodni, a koji proizvoljni.

Osim očiglednog modela veze ili ostalih klasa interfejsa, morali smo da definišemo i metode delegacije, pomoćne funkcije i ostale fragmente koda. Sve ovo može se podeliti u četiri različite kategorije:

  1. Klase, funkcije ili svojstva koja se mogu ponovo iskoristiti sa istim nazivom (olakšavajući tako integrisanje arhive i smanjujući potrebu da se diraju radni delovi koda)
  2. Klase, funkcije ili svojstva koja se mogu ponovo iskoristiti sa različitim parametrima ili tipovima koji se mogu vratiti (želim da vam pokažem način za praktično rešavanje ovog problema u koraku 2, jer on ne zahteva nikakve izmene naziva klase, ukoliko se sve odradi kako treba)
  3. One koje se uopšte ne mogu ponovo iskoristiti. Na ovakve slučajeve jedva da smo i nailazili, ali ovo se može desiti kod izmena dizajna. Ukoliko do toga dođe, budite spremni da nađete adekvatnu zamenu za ovaj kod, ukoliko je to zaista neophodno. – vidi korak 3
  4. Klase, funkcije ili svojstva koja je moguće ponovo koristiti uz promenu imena (mapiranje od stare ka novoj verziji bi trebalo da vam je već pri ruci, pa je proces zamene jednostavniji) – vidi korak 4

2) Mapirati klase i metode za novi dizajn

Logično je da niko nema jasan pregled kakva vrsta klase ili šeme će se menjati novim pristupom. Ipak, želeo sam da pomenem jedan lak pristup za kodiranje, koji se naročito odnosi na korake 2 i 3: Moramo da mapiramo stare tipove vrednovanja na novim. Zamislite strukturu nekog projekta gde su potrebne klase prosto izbrisane ali se njihovi tipovi još uvek koriste u funkcijama. Rezultat bi bio prilično očigledan: Greške u kodiranju.

Uz pomoć LLVM strukture za kodiranje omogućili smo vam praktičan pristup mapiranju starih tipova klasa na nove definisanjem jednostavnih makro jezika:

#define oldClassModel newClassModel

Onaj koji kodira ne bi bio svestan tipa klase (thisIsMyOldClass), jer bi ovaj bio mapiran preko makro jezika, koji ima referencu za novi tip klase (newClassModel).

Naravno, ipak bi se morale zameniti veze koje se “teško” kodiraju, a koje sadrže taj ‟oldClassModel” – koji dolazi od same klase.

3) Zabeležiti one koji bi bile nepodesne zbog novog dizajna

Najviše smo se bavili klasama, funkcijama i svojstvima koji će u potpunosti biti uklonjeni iz osnove koda – na poseban način.

Imali smo poseban odeljak za ove zastarele elemente.

Klase

Zastarele klase smo jednostavno mapirali na osnovu klase NSObject, koja je jedna od primarnih korenskih klasa u Cocoa sistemu.

Funkcije i svojstva

Funkcije smo dodali posebnoj kategoriji starije klase i označili kako bi se jasno videlo da su zastarele. Zatim smo uveli jedno prazno funkcionalno telo i konstantno smo vraćali (u slučaju da se radilo o tipovima koji se vraćaju) nil/null ili 0

Da bismo to postigli, možemo da koristimo dodatke poput Clang Language Extensions koje bi nas izveštavale o što boljem održavanju naših standardnih prepravki.

Naravno, morali bismo da zadržimo i stari kod. Ali: zašto bismo se uopšte maltretirali da kopiramo stari kod kada bismo samo mogli da obavestimo sistem za kodiranje i naše inženjere da više ne koriste stari metod?

Kod svojstava smo se koristili istim pristupom

 

Redovno Odr Avanje I Unapre Ivanje Mobilnih Aplikacija

Sam rezultat je fina podrška svakom programeru 🙂

U kodu:

Redovno Odr Avanje I Unapre Ivanje Mobilnih Aplikacija

 

 

 

Nakon kodiranja:

Redovno Odr Avanje I Unapre Ivanje Mobilnih Aplikacija

 

 

 

 

 

 

 

4) Pronaći preciznu  funkciju (koja može lako da se prevede i ugradi) i promeniti svojstva

Mapiranje će se ubrzo tretirati kao dodatak funkciji, pa će inženjer biti svestan ovog upozorenja (vidi korak 3 za ovo).

Štaviše, registrovanje koda će pomoći inženjerima da prikažu dodatne informacije o ovom zastarelom metodu i kako dalje postupati sa njim.

Redovno Odr Avanje I Unapre Ivanje Mobilnih Aplikacija

 

 

 

 

 

 

Kao rezultat kratke registracije koda, IDE softverskim inženjerima preporučuje jednu alternativu umesto zastarele funkcije.

Redovno Odr Avanje I Unapre Ivanje Mobilnih Aplikacija

 

 

 

5) Dodaj Biblioteku projektu

Dakle, pre nego što uklonite vaš stari radni kod, postarajte se da se biblioteka koju želite da koristite uklapa u projekat. Popravite probleme sa referencama u biblioteci pre nego što uklonite delove starog koda, jer će se u suprotnom pojaviti pregršt kodova i projekatskih grešaka. Kako nismo želeli da ubacujemo istu klasu dva puta, već smo umesto toga iskoristili kategorije za zastarele funkcije koda ili mapere za klase, nećemo imati problema sa dupliranjem definicija interfejsa.

6) Uklontii stari kod iz projekta

Sa uživanjem obrišite sve stare klase i funkcije koje ste prepoznali u koraku 1 i u međuvremenu.

7) Iskoristiti našu metodologiju zamene i završiti refaktorisanje osnove sopstvenog koda

Ne brinite. Projekat bi trebalo da je još u saglasnosti sa mnoštvom novih upozorenja, koje smo mi sami osmislili. Sam softver vervatno još uvek neće raditi kako je planirano (prazne funkcije su zamenile stari kod). Još moramo da iskoristimo naša obaveštenja za kodiranje u skladu sa zastarelom funkcijom i njenom izmenjenom metodom. Prođite kroz ovih 1.000 upozorenja i ponovo pokrenite projekat. Bez obzira na to da li izmene unosite od vrha ka dnu ili prvo refakturišete zasebne delove koda (npr. prvo model objekta, pa metode komunikacije, itd.) ili tako što se koristite svojim User Story uputstvima u aplikaciji (počnite sa procesom registracije, nastavite sa prijavom, itd.), odluka je na vama.

Ukoliko želite da uradite uporedno testiranje, preporučujem vam najpre metod sa refaktorisanjem problema povezanih sa User Story metodom. Ukoliko želite da se posao odradi za vas, preporučujem refaktorisanje delova koda istog tipa (npr. najpre refaktorišite delove u vezi sa modelom objekta).

Share

Prijavi se da prvi dobijaš nove blogove i vesti.

Оставите одговор

Tobias Baube

Senior software engineer @Namics
mm

Senior softver inženjer, koji tri godine radi u švajcarskoj softverskoj agenciji Namics. Njegove sfere interesovanja su: agilne metodologije, programski jezici Java i JavaScript, aplikacije za mobilne telefone, User Story metode, E-trgovina, Scrum pristup, informatički dizajn, sistemi CSS, HTML, MySQL i softversko programiranje.

Prijavi se da prvi dobijaš nove blogove i vesti.

Категорије