Tehnički due diligence za naslijeđene web i mobilne aplikacije: kontrolna lista za audit, bodovanje rizika i plan modernizacije

# Što ćete naučiti#

Tehnički due diligence za naslijeđenu web ili mobilnu aplikaciju nije code review. To je strukturirana procjena koja odgovara na tri pitanja važna za vodstvo: je li sustav siguran, je li održiv i koliko će koštati njegov daljnji razvoj.

Ovaj vodič prikazuje proces korak po korak za provođenje audit naslijeđenog koda web mobile za Next.js i React aplikaciju ili Flutter aplikaciju. Dobit ćete kontrolnu listu, rubriku za bodovanje rizika i način kako nalaze pretvoriti u fazni plan modernizacije koji vodstvo može financirati.

# Kada vam due diligence zaista treba#

Ovaj audit obično vam treba kada se dogodi jedan od ovih okidača:

1. 1
   Due diligence za akviziciju ili investiciju, gdje tehnički rizik utječe na valuaciju.
2. 2
   Preuzimanje od strane nove agencije ili internog tima, kada trebate predvidljive rokove isporuke.
3. 3
   Roadmap je blokiran bugovima, regresijama ili sporim releaseovima.
4. 4
   Povećali su se sigurnosni ili compliance zahtjevi, uključujući SOC 2, ISO 27001 ili PCI-kontrole.

U praksi timovi podcjenjuju kumulativni trošak održavanja. Više industrijskih benchmarkova godišnje održavanje procjenjuje na otprilike 15 do 25 posto početnog troška izrade, a naslijeđeni sustavi idu prema gornjoj granici kada su test coverage i “dependency hygiene” slabi. Cilj ovog audita je kvantificirati rizik, a ne samo prigovarati na stari kod.

# Opseg i isporuke: definirajte što znači “gotovo”#

Prije nego što uopće otvorite repo, postavite konkretan opseg kako se audit ne bi pretvorio u otvorene savjete za refaktoring bez kraja.

Kontrolna lista opsega audita#

Minimalne isporuke koje dionici razumiju#

• Jednostranični sažetak rizika s numeričkim rezultatom i top 10 problema.
• Prioritizirani backlog s procjenama i acceptance kriterijima.
• Fazni roadmap modernizacije s vremenskim okvirima i opcijama “bez rewritea”.
• Kratko tehničko izlaganje, idealno 45 minuta s Q&A.

ℹ️ Napomena: Due diligence izvještaj bez procjena i sekvenciranja nije primjenjiv. Ako ne možete dati barem okvirnu veličinu, vodstvo ne može budžetirati niti planirati release vlak.

# Proces audita korak po korak za naslijeđeni Next.js, React i Flutter#

Ovaj proces je osmišljen za 5 do 10 dana. Ako je aplikacija velika, zadržite iste korake, ali ograničite vrijeme po koraku kako ne biste “kuhali ocean”.

# Korak 1: Pristup, inventar i reproducibilni buildovi#

Prvi cilj je odgovoriti na jedno pitanje: može li novi inženjer buildati i pokrenuti aplikaciju za manje od 60 minuta.

Što prikupiti prvog dana#

Brze provjere reproducibilnosti builda#

Za Next.js i React:

node -v
npm -v
npm ci
npm run build
npm run test

Za Flutter:

flutter --version
flutter doctor -v
flutter pub get
flutter test
flutter build apk --debug

Ako bilo koji korak padne, zabilježite error i utrošeno vrijeme. To vrijeme postaje dio vašeg maintainability rezultata.

💡 Savjet: Zamolite developera koji nikada nije radio na projektu da setup odradi od nule uz snimanje ekrana. Dobit ćete precizan popis nedostajuće dokumentacije, implicitnih pretpostavki i flaky koraka.

# Korak 2: Arhitektura i mapa codebasea#

Želite brzo razumjeti gdje je promjena sigurna, a gdje rizična.

Što dokumentirati#

Za Next.js i React:

• Routing model i obrasce dohvaćanja podataka kroz stranice i komponente.
• Pristup upravljanju stateom, uključujući gdje žive server state i UI state.
• Konvencije API sloja i obradu grešaka.
• SSR, SSG i caching odluke, uključujući edge deployment ako se koristi.

Za Flutter:

• State management biblioteku i njezine granice.
• Strukturu navigacije i obradu deep linkova.
• Slojevitost, npr. presentation, domain, data.
• Platform channels i dodirne točke s native kodom.

Signali skrivene složenosti#

# Korak 3: Kontrolna lista sigurnosnog audita za web i mobile#

Sigurnost je često dio tehničkog due diligencea s najvećim utjecajem jer može stvoriti trenutni poslovni rizik. Cilj nije pronaći svaku sitnicu, nego prepoznati sustavnu izloženost.

Koristite ovo kao dopunu našem detaljnijem vodiču: Web Application Security Checklist.

Web: sigurnosna kontrolna lista za Next.js i React#

Praktične provjere koje možete pokrenuti:

npm audit --audit-level=high
npx depcheck
npx license-checker --summary

Mobile: sigurnosna kontrolna lista za Flutter#

Brzi scan ovisnosti:

flutter pub deps --style=compact
flutter pub outdated

⚠️ Upozorenje: Čest due diligence promašaj je auditirati samo client kod. Ako su API i identity provider izvan opsega, izričito dokumentirajte pretpostavke, jer je većina stvarnih authorization bugova server-side.

# Korak 4: Audit performansi s realnim metrikama, a ne mišljenjima#

Nalazi o performansama trebaju biti vezani uz brojke. Na webu su najobrativije metrike Core Web Vitals i veličine bundlea. U Flutteru fokusirajte se na jank, memoriju i startup time.

Za dublje taktike i alate: Website Performance Optimization.

Web metrike koje treba zabilježiti#

Brze Next.js provjere:

npm run build
npx next build --profile
npx @next/bundle-analyzer

Ako ne možete pokrenuti bundle analyzer, barem zabilježite veličine outputa u /_next/static i broj chunkova.

Flutter metrike koje treba zabilježiti#

Osnovna naredba za profiliranje:

flutter run --profile

🎯 Ključna poruka: Audit performansi je vjerodostojan kada date baseline, popis top 5 bottleneckova i procjenu očekivanog poboljšanja, npr. “smanjiti inicijalni JS za 35 posto uklanjanjem nekorištenih ovisnosti i splitanjem ruta”.

# Korak 5: Audit developer experiencea i delivery pipelinea#

DX problemi nisu “nice to have”. Oni se pretvaraju u dulje cikluse, više regresija i veći trošak kadrova.

Što mjeriti#

Praktične provjere:

• Je li TypeScript strict mode uključen u React i Next.js aplikaciji.
• Postoji li single source of truth za environment varijable.
• Jesu li Flutter build flavori dokumentirani i reproducibilni.
• Je li code generation stabilan i jesu li generirani fileovi commitani ili ne, konzistentno.

# Korak 6: Zdravlje ovisnosti i rizik nadogradnje#

Naslijeđene aplikacije često akumuliraju “dependency debt”. Jedan neodržavani paket može blokirati velike nadogradnje, a velike nadogradnje mogu blokirati sigurnosne patcheve.

Kontrolna lista zdravlja ovisnosti#

Naredbe koje daju primjenjiv output:

npm outdated
npm ls --depth=0

flutter pub outdated --mode=null-safety

Ako Flutter aplikacija još ima non-null-safe ovisnosti, tretirajte to kao prioritet modernizacije. Migracija na null safety smanjuje runtime crashove i poboljšava tooling, a većina aktivnih paketa to podržava godinama.

# Korak 7: Strategija testiranja i signali kvalitete#

Ne ciljate na 100 posto test coveragea. Ciljate na “sigurnu promjenu” u područjima najvećeg rizika.

Minimalna test baza za naslijeđene aplikacije#

Dobar due diligence output je popis “test gapova” vezan uz roadmap. Primjer: “Dodati E2E pokrivenost za checkout login flow prije refaktoriranja autha”.

# Rubrika za bodovanje rizika: učinite nalaze usporedivima#

Risk score pretvara subjektivne brige u alat za donošenje odluka. Koristite ponderirani model kako bi vodstvo vidjelo što gura rezultat.

Model bodovanja#

Ocijenite svaku kategoriju od 0 do 5, zatim pomnožite s težinom. Veće je gore.

Formula ukupnog risk scorea:

Risk Score = sum(category_score * weight) / sum(weights)

Matrica severityja i efforta za svaki nalaz#

Uz ukupni score, svaki problem treba imati dvije ocjene:

• Impact od 1 do 5, gdje je 5 rizik za korisničke podatke ili utjecaj na prihod.
• Effort od 1 do 5, gdje je 5 promjena kroz više sprintova uz koordinaciju između timova.

To omogućuje prioritizaciju po “impact per effort”.

Primjer risk scorecarda#

Overall Risk Score = 350 / 100 = 3.5

Tumačenje:

# Pretvaranje nalaza u fazni roadmap modernizacije#

Roadmap je mjesto gdje većina audita zakaže. Trebate sekvenciranje koje rano smanjuje rizik, a pritom proizvod nastavlja isporučivati.

Faza 0: Stabilizirajte i učinite promjene sigurnima, 1 do 3 tjedna#

Ciljevi:

• Učiniti buildove reproducibilnima.
• Dodati osnovni monitoring i crash reporting.
• Patchati ranjivosti visokog severityja s poznatim exploitima.

Tipični zadaci:

Isporuka: “zeleni pipeline” i baseline vidljivosti incidenata.

Faza 1: Sigurnost i zdravlje ovisnosti, 2 do 6 tjedana#

Ova faza smanjuje rizik da vas buduće nadogradnje blokiraju.

Za Next.js i React:

• Nadograditi Node.js na aktivni LTS i uskladiti Next.js i React verzije.
• Zamijeniti abandoned biblioteke, posebno auth, routing i form libove ako nisu održavani.
• Dodati security headere i provoditi server-side authorization provjere.

Za Flutter:

• Migrirati na moderni Flutter i Dart baseline koji vaši pluginovi podržavaju.
• Zamijeniti deprecated plugine i ukloniti neodržavane platform wrappere.
• Standardizirati secure storage i network stack.

Isporuka: status “supported stack” plus playbook za dependency nadogradnje.

Faza 2: Poboljšanja performansi i UX-a, 2 do 8 tjedana#

Ovo je faza u kojoj timovi vide vidljiv utjecaj na korisnike.

Za Next.js i React:

• Splitati bundleove po ruti i ukloniti nekorištene ovisnosti.
• Popraviti waterfall requestove i rupe u cachingu.
• Uvesti optimizaciju slika i predvidiva SSR i SSG pravila.

Za Flutter:

• Ukloniti skupe pattern-e rebuildanja i izolirati widgete.
• Optimizirati liste, slike i JSON parsing.
• Smanjiti posao na startu i lazy-loadati teške featuree.

Isporuka: izmjerena poboljšanja, npr. “LCP poboljšan s 3.8 sekundi na 2.3 sekunde” ili “cold start smanjen za 35 posto”.

Faza 3: Modernizacija arhitekture, kontinuirano#

Ovo radite zadnje, nakon što možete sigurno mijenjati stvari.

Primjeri:

• Uvesti feature-based strukturu modula u React i Next.js.
• Standardizirati state management i API granice.
• Izvući shared domain logiku i dodati contract testove.
• Za Flutter, provoditi clean architecture granice tamo gdje je bitno, ne posvuda.

Isporuka: kraće lead timeove po featureu i manju stopu defekata.

💡 Savjet: Koristite “strangler” pristup: modernizirajte jedan flow po jedan iza stabilnih sučelja. Tako rizik ostaje lokalan i izbjegava se višemjesečna rewrite zamka.

# Kako procijeniti trošak i vremenski plan iz audit podataka#

Vodstvu trebaju procjene reda veličine, ne savršeni brojevi.

Praktična metoda procjene#

1. 1
   Grupirajte nalaze u epic-e po fazama.
2. 2
   Za svaki epic, procijenite “small, medium, large” vezano uz tjedne.
3. 3
   Dodajte faktor koordinacije ako je uključeno više repozitorija ili timova.

Primjer modela veličine:

Ako je due diligence za outsourcing ili handover, uključite i plan tranzicije. To smanjuje “unknown unknowns” koji često napuhuju rokove isporuke nakon preuzimanja. Za praktičan framework pogledajte Outsourcing Web Development Guide.

# Preporučeni audit artefakti koje možete ponovno koristiti#

U budućim auditima ići ćete brže ako standardizirate predloške.

Artefakti koje treba izraditi#

Dobar redak u risk registeru treba uključivati:

• Sažetak nalaza
• Impact i likelihood
• Dokaz, uključujući putanje fileova ili metrike
• Preporuku
• Procjenu efforta
• Ownera i fazu

# Česte zamke u due diligenceu naslijeđenih aplikacija#

1. 1
   Bez runtime validacije — pregledavanje koda bez pokretanja flowova propušta stvarne bottleneckove i crashove.
2. 2
   Oslanjanje samo na statičke skenere — alati nalaze simptome, ne sustavne uzroke.
3. 3
   Tretiranje modernizacije kao rewritea — gubite momentum i obično isporučite kasnije uz iste nepoznate rizike.
4. 4
   Ignoriranje observabilityja — bez logova i metrika ne možete dokazati poboljšanja niti uhvatiti regresije.
5. 5
   Preskakanje prezentacije dionicima — ako vodstvo ne razumije rizik, backlog neće biti financiran.

# Ključne poruke#

• Ograničite audit naslijeđenog koda web mobile na 5 do 10 dana i postavite reproducibilne buildove kao prvi gate.
• Bodujte rizik ponderiranom rubrikom kako sigurnost, pouzdanost i zdravlje ovisnosti ne bi bili potisnuti subjektivnim dojmovima.
• Nalaze o performansama vežite uz mjerljive baselineove poput Core Web Vitals za web te startup i jank metrika za Flutter.
• Pretvorite nalaze u faze: prvo stabilizacija, zatim sigurnost i ovisnosti, pa performanse, pa modernizacija arhitekture.
• Isporucite roadmap s procjenama i acceptance kriterijima, inače audit neće postati financirani posao.

# Zaključak#

Tehnički due diligence je najbrži način da naslijeđenu Next.js, React ili Flutter aplikaciju pretvorite iz “rizične i skupe” u “predvidljivu i nadogradivu”. Strukturirani audit uz bodovani risk register daje vodstvu jasnoću, a fazni plan modernizacije izbjegava rewrite zamku, dok i dalje isporučuje mjerljiva poboljšanja.

Ako želite da Samioda odradi audit naslijeđenog koda i isporuči roadmap modernizacije koji vaš tim može provesti, kontaktirajte nas uz repo pristup i staging build. Vratit ćemo bodovani izvještaj, prioritizirani backlog i fazni plan usklađen s vašim release rasporedom.