Šta se dešava posle lansiranja: održavanje mobilne aplikacije

Veb sajt prepušten sam sebi dve godine je zastareo. Mobilna aplikacija prepuštena sama sebi dve godine često je pokvarena, ponekad uklonjena iz prodavnice, a povremeno je nemoguće ponovo je izbuildovati bez nedelju dana posla pre nego što iko napiše ijednu liniju novog koda.

Razlika je u tome što aplikacija stoji na dve platforme koje se stalno kreću. I Apple i Google svake godine objavljuju veliku verziju operativnog sistema i menjaju pravila svojih prodavnica i češće od toga. Vaša aplikacija ne mora da se promeni da bi se njen položaj promenio.

Održavanje nije isto što i popravljanje grešaka

Većina osnivača održavanje zamišlja kao popravljanje onoga na šta se korisnici žale. To je deo posla, i obično manji deo.

Veći deo je održavanje kompatibilnosti aplikacije sa okruženjem koje se menja ispod nje. Ništa od tog posla korisnici ne vide. Kada se dobro uradi, niko ništa ne primeti - i upravo zato je to prvo što se izbaci iz budžeta i prvo što napravi problem.

Održavanje je posao koji aplikaciju drži tačno tamo gde jeste dok se sve oko nje pomera.

Od čega se održavanje zaista sastoji

Šest poslova koji se ponavljaju pokrivaju gotovo sve.

Dva od njih imaju fiksne rokove. Sertifikati ističu na tačno određen datum, a zahtevi prodavnica dolaze sa krajnjim rokom posle kog uopšte ne možete da objavite ažuriranje. Propuštanje bilo kog od njih nije pogoršanje, već zaustavljanje.

Šta se dešava sa aplikacijom prepuštenom samoj sebi

Neko vreme ništa. Zbog toga ga je lako odlagati.

Onda stigne nova verzija operativnog sistema i neka funkcija počne čudno da se ponaša na najnovijim telefonima - često nešto konkretno, kao tok kamere, obaveštenje ili ekran koji se odjednom pogrešno prikazuje na novoj veličini uređaja. Stižu zahtevi za podršku, i svi su od korisnika sa novijim uređajima.

U međuvremenu su se zahtevi prodavnica pomerili. Da biste objavili popravku, sada morate da ciljate noviju verziju SDK-a, što zahteva ažuriranje zavisnosti od kojih je svaka otišla nekoliko verzija napred, neke sa nekompatibilnim izmenama. Ono što je trebalo da bude popravka od jednog dana ima pred sobom nedelju dana posla na nadogradnji.

A zavisnosti bez zakrpa su i bezbednosno pitanje, a ne samo pitanje kompatibilnosti. Biblioteka sa poznatom ranjivošću je javno objavljen opis slabosti u vašoj aplikaciji koji svako može da pronađe.

Gde se te slabosti obično pojavljuju, posebno u kodu koji je brzo sklopljen, objašnjavamo u tekstu o bezbednosnim propustima u kodu koji generiše AI.

Problem koji se nagomilava

Odloženo održavanje ne ostaje iste veličine. Svako preskočeno ažuriranje otežava sledeće, jer nadogradnje koje bi bile postepene postaju jedan veliki skok preko više nekompatibilnih izmena odjednom.

Baza koda koja se ažurira na svakih nekoliko meseci svaki put je rutinski posao. Ista baza koda ažurirana posle dve godine tišine je projekat, sa sopstvenim testiranjem i sopstvenim rizikom od regresija - i mora da se uradi pre nego što ijedna nova funkcija može da se isporuči.

To je običan tehnički dug, nagomilan nečinjenjem, a ne prečicama.

Kako to funkcioniše i kako odlučiti šta vredi otplatiti, objašnjavamo u tekstu šta je tehnički dug.

Kako dobro održavanje izgleda u praksi

To nije paušal sa neodređenim brojem sati. To je mali skup konkretnih obaveza.

• Zavisnosti se pregledaju i ažuriraju u redovnom ritmu, a ne kada se nešto pokvari.
• Kompatibilnost sa svakim novim izdanjem iOS-a i Android-a proverava se tokom beta perioda, pre nego što ga korisnici dobiju.
• Prijavljivanje padova i nadzor grešaka su postavljeni, a neko ih zaista čita.
• Datumi isteka sertifikata i ključeva se prate, uz podsetnik dovoljno pre roka.
• Promene pravila prodavnica se prate, pa se rokovi poštuju umesto da se otkrivaju.
• Navedeno vreme reakcije za sve što korisnicima onemogućava da obave glavni zadatak aplikacije.

Primetite koliko je toga planiranje, a ne inženjering. Veliki deo propusta u održavanju su propusti u kalendaru.

Ko bi trebalo da ga radi

Tri modela, svaki razuman u drugačijim okolnostima.

Zadržavanje održavanja kod tima koji je napravio aplikaciju najefikasnija je opcija dok se proizvod još razvija, jer niko ne mora ponovo da otkriva razloge iza koda. Najbolje funkcioniše kada je obim zapisan, a ne pretpostavljen.

Rad po potrebi odgovara stabilnim aplikacijama koje se zaista malo menjaju, pod uslovom da je godišnji posao oko kompatibilnosti i dalje namerno zakazan. Rad po potrebi u praksi često znači da se ništa ne dešava dok se nešto ne pokvari, a to je skupa varijanta.

Prebacivanje u sopstveni tim ima smisla kada je aplikacija dovoljno važna da opravda stalnog inženjera. Prelaz zahteva pravu predaju - repozitorijum, naloge, dokumentaciju i prolazak kroz arhitekturu - a ne samo pristupne podatke poslate imejlom.

Šta god da izaberete, nalozi i kod treba već da budu na vaše ime. To je ono što promenu modela čini odlukom, a ne pregovorima.

Ako je vaša aplikacija već zaostala

Mnogo aplikacija je u ovoj situaciji: dostupne su, i dalje se koriste, a niko nije dirao kod godinu dana ili duže. Situacija je rešiva, i vredi znati veličinu posla pre nego što se na njega obavežete.

Razuman prvi korak je procena, a ne spasavanje - da li se trenutna baza koda još može izbuildovati i objaviti, koliko zavisnosti kasne, šta prodavnica sada zahteva i da li nešto uskoro ističe. Tako dobijate stvarnu odluku između ažuriranja onoga što postoji i zamene dela toga, umesto nagađanja.

Upravo takvu procenu radi naša usluga revizije i preuzimanja aplikacija.

Česta pitanja