Revizija i spašavanje aplikacije · Procjena
Šta prvo popraviti u aplikaciji koju sada koriste pravi korisnici
Za aplikaciju napravljenu na brzinu u Lovableu, Boltu ili Cursoru, ili onu čiji je tim otišao: dvosedmična pisana procjena koja kaže šta prvo popraviti, a šta zadržati.
FormatPisana procjena
Rok2 sedmice
CijenaProcjena po fiksnoj cijeni · rad po satu
Dokaz3 projekta
Procjena u 4 dijela
01 · Kada vam treba
Ako su dvije od ovih tačne, ovo vam odgovara.
- Nastala je u Lovableu, Boltu ili Cursoru, ili ju je pravio tim kojeg više nema
- Radila je dok nisu stigli pravi korisnici
- Niko u timu ne čita kod koji ide u produkciju
- Svaka izmjena pokvari nešto drugo, a pristup podacima nikad nije provjeren
- Podaci su na Supabaseu, a RLS politike je napisao isti alat koji je napravio aplikaciju
02 · Šta dobijate
Za dvije sedmice dobijete dokument u kojem piše:
- Šta je hitno: ko može pristupiti kojim podacima, kako se korisnici prijavljuju i koji su tajni ključevi završili u klijentu. To ide na početak jer je to jedino što ne može čekati.
- Koji su problemi skupi, a koji samo ružni. To dvoje se obično pomiješa, a popravlja se na sasvim različite načine.
- Za svaki dio aplikacije preporuka treba li ga spašavati ili prepisati, pa ne morate odlučivati o cijeloj aplikaciji odjednom.
- Pravila koja treba uvesti prije sljedeće funkcionalnosti, da novi kod, bilo da ga piše čovjek ili alat, ne vrati iste probleme.
03 · Kako odlučujemo
KORAK 01Počinjemo od pristupa podacima.Provjeravamo ko može vidjeti podatke koji pripadaju drugima i šta ga u tome sprječava. U aplikacijama napravljenim na brzinu to je najčešći i najskuplji propust, a pritom ne izaziva nikakvu grešku.
KORAK 02Zatim gledamo model podataka.Ako je model nekoherentan, taj dio se prepisuje. Ako je dobro postavljen, skoro sve ostalo se može spasiti.
KORAK 03Prvo stabilizujemo, tek onda prepisujemo.Korisnici i dalje koriste verziju koja radi, a mi za to vrijeme popravljamo rizične dijelove. Ako treba prepisivati, to dolazi kasnije, dio po dio.
KORAK 04Novi kod prolazi iste provjere.Od pravila pravimo provjere, pa build padne čim neka izmjena prekrši pravilo. Generisani kod tako prolazi iste provjere kao kod koji je napisao čovjek, a pregled mu traje kraće.
04 · Ako ništa ne nađemo
Onda dokument objašnjava zašto je aplikacija dovoljno dobra da se na njoj nastavi graditi. I u tom slučaju navodi pravila za novi kod koja treba uvesti prije sljedeće funkcionalnosti.
Dokaz
Gdje smo ovo već radili
Projekat 04 · MarketplaceNula prekida radaAmerički marketplace koji je redovno padao: PHP na hostingu koji se nije mogao skalirati, a produkcija je bila otvorena za SQL injection. Tokom dva mjeseca stabilizacije, prije nego što je prepisan ijedan red koda, ubrzali smo dvadeset najsporijih upita za 90% i zatvorili sigurnosne propuste. Nova verzija pravila se u naredne dvije godine.Pročitajte više o projektu →Projekat 03 · Platforme~50%U timu koji kod piše uz Claude Code pre-commit hook i CI provjeravaju pravila kao što su ova: nijedna komponenta ne smije imati više od 200 linija, any u TypeScriptu nije dozvoljen, a svaki API poziv mora imati deklarisan tip zahtjeva i tip odgovora.Pročitajte više o projektu →Projekat 15 · Poslovni sistemiProdanoU zdravstvenoj i finansijskoj aplikaciji za sastanke na daljinu server određuje ko smije otvoriti koji fajl tako što prati veze između ljudi, sastanaka, dokumenata i potpisa.Pročitajte više o projektu →
Česta pitanja
Pitanja o ovoj usluzi
Pristup repozitoriju i opis kako ljudi koriste aplikaciju. Dvije sedmice počinju teći kad dobijemo pristup kodu, a radimo bez produkcijskih podataka.
Ne nužno. Dokument za svaki dio posebno preporučuje spašavanje ili prepisivanje, a ako je model podataka dobar, veći dio aplikacije može ostati.
Možemo. Počinjemo od onoga što je u dokumentu označeno kao hitno, a taj posao plaćate po satu.
Sljedeći korak
Opišite problem i javit ćemo vam se s tri opcije.
Prvi poziv traje 30 minuta i ni na šta vas ne obavezuje.