MVP batek bere funtzioa betetzen du eskatu zitzaiona lortzen duenean: ideia bat benetako erabiltzaileekin ahalik eta lasterren balidatzea. Arazoa gero iristen da, funtzionatzen duenean. Erabiltzaileak iristen dira, datuak iristen dira, inork aurreikusi ez zituen kasuak iristen dira, eta presaka muntatutako arkitektura karraskatzen hasten da. Galdera orduan ez da "botatzen dugu eta berregiten dugu?", nola eskalatu MVP bat hutsetik berridatzi gabe baizik. Ia beti ahal da.
Zergatik hiltzen diren MVP asko funtzionatzen hasten diren unean bertan
Paradoxa deseroso bat dago MVP baten bizi zikloan: azkar jaiotzea eragiten duena da bera hazten denean hiltzen duena. Azkar balidatzeko lasterbide legitimoak hartzen dira: behin-behineko datu egiturak, une hartan zegokion tokian sartutako logika, "gero konponduko dugu" erabakiak. Hamar erabiltzaile dauden bitartean, denak eusten du. Hamar mila daudenean, ez.
Kausa gutxitan da bakarra. Normalean hiru gauzaren batura izaten da:
- Metatutako zor teknikoa. Jakinaren gainean hartutako baina inoiz itzuli ez ziren lasterbideak. Ez dira akats bat; mailegu bat dira. Arazoa ez erregistratu izana eta garaiz ez ordaindu izana da.
- Dokumentatu ez zen ezagutza. Hartu zituenaren buruan bizi ziren erabakiak. Pertsona hori joaten denean, edo sei hilabete pasatzen direnean besterik gabe, sistema kutxa beltz bihurtzen da bere talde beraren aurrean.
- Hazteko diseinatu ez zen arkitektura. Erabilera kasu baterako pentsatutako datu base bat, erregistro gutxirekin funtzionatzen eta milioika direnean erortzen diren kontsultak, weba dagoen leku berean exekutatzen diren eta baliabide berberengatik lehiatzen diren prozesuak.
Hiru gauza hauetako bat ere ez da berez hilgarria. Hilgarria da haiei ez ikusiarena egitea sistema ordu puntan erori arte eta inork zergatik ez dakien arte.
MVParen zein erabakik baldintzatzen duten eskalatzea
MVP baten hazteko gaitasuna ez da eskalatzeko unean erabakitzen: eraikitzean erabakitzen da. Lau erabakik gainerakoak baino askoz gehiago pisatzen dute, eta komeni da haiek ulertzea MVPa eginda baduzu ere, hurrengo urratsa zein garestia izango den zehazten baitute.
Datu eredua
Gero aldatzen zailena da. Gaizki diseinatutako taula batek edo bereizita egon beharko luketen kontzeptuak nahasten dituen eskema batek urteetan arrastatzen du. Datuak produkzioan migratzea, erabiltzaile aktiboekin, existitzen diren eragiketarik delikatuenetakoa da. MVPak hemen asmatu bazuen —modu sinplean izan arren—, eskalatzea askoz merkeagoa da.
Geruzen arteko bereizketa
Negozio logika interfazearekin eta datuen sarbidearekin nahastuta duen MVP bat osorik bakarrik uki daitekeen bloke bat da. Geruza horiek bereizita dituen batek, oinarrizko moduan bada ere, pieza bat aldatzea ahalbidetzen du besteak hautsi gabe. Ez da gaininjeniaritzarik behar: nahikoa da gauza bakoitza bere lekuan egotea.
Testak, gutxienekoak izanda ere
Testik gabeko MVP bat konfiantzaz alda ezin daitekeen MVP bat da. Ez gara %90eko estalduraz ari —hori neurriz kanpokoa litzateke balidazio fasean—, fluxu kritikoetako testez baizik: izena ematea, ordainketa, benetan hautsi ezin dena. Test horiek dira gero beldurrik gabe refactorizatzeko aukera ematen dizun sarea.
Behagarritasuna
Neur ezin daitekeen MVP bat itsu doan MVP bat da. Logik gabe, metrikarik gabe, zein kontsultak denbora behar duen edo zein endpoint-ek huts egiten duen jakin gabe, eskalatzeko unea iristen denean ez duzu jakingo zer eskalatu. Hasieratik oinarrizko arrastoak gehitzeak gutxi kostatzen du eta urrea balio du zerbait geldo doan eta kausa aurkitu behar den egunean.
Eskalatzeko unea dela adierazten duten seinaleak (eta ez gehiago itxaron)
Garaia baino lehen eskalatzea dirua xahutzea da erabiliko dela frogatu ez duen zerbait optimizatuz. Berandu eskalatzea erabiltzaileak galtzea da sistema erortzen den bitartean. Gakoa seinaleak garaiz irakurtzea da. Hauek dira axola dutenak:
- Erantzun denborak modu jarraituan igotzen dira datuak edo erabiltzaileak hazi ahala. Ez gailur isolatu bat: joera bat.
- Lehen existitzen ez ziren gorabeherak agertzen dira: erorketak ordu puntan, zintzilik geratzen diren prozesuak, erreproduzitzen zailak diren akats etenak.
- Aldaketa txiki bakoitzak beste nonbait zerbait hausten du. Gehiegizko akoplamenduaren eta test faltaren sintoma klasikoa da.
- Taldeak gero eta gehiago behar du gauza bera entregatzeko. Garapen abiadura jaisten da kodea hauskor bihurtu delako eta inork ez duelako ukitzeko ausardiarik.
- Badira jada kabitzen ez diren zereginak egungo ereduan: sor ezin daitezkeen txostenak, kabitzen ez diren integrazioak, sistemak kontuan hartzen ez dituen negozio kasuak.
Seinale hauetako hiru edo gehiago ezagutzen badituzu, ez da iritzia: sistema bilakatzeko eskatzen ari zaizu.
Nola eskalatu faseka kodea bota gabe
Berri ona da eskalatzea ia inoiz ez dela ekintza bakar eta heroiko bat. Urrats neurgarrien sekuentzia bat da, bakoitza bere itzulkinarekin. Hau da kasu gehienetan zentzua duen ordena.
- Neurtu ukitu aurretik. Instrumentatu sistema zer doan geldo eta zergatik jakiteko. Daturik gabe, edozein optimizazio asmakizuna da. Hemen uzten dio behagarritasunak luxu izateari.
- Eraso benetako botila-lepoari, ez imajinatuari. Arazoa ia beti leku zehatz batean dago —indizerik gabeko kontsulta bat, blokeatzen duen prozesu bat—, ez "denean". Benetan min egiten duena konpontzeak jauzirik handiena ematen du ahalegin txikienarekin.
- Bereizi baliabideengatik lehiatzen dena. Mugitu prozesu astunak erabiltzailearen bidetik kanpo: ilarak, atzeko planoko lanak, programatutako zereginak. Webak txostenekin borrokatzeari uzten dio.
- Refactorizatu eremu hauskorrak, banan-banan. Aldaketa bakoitza babesten duten testekin, kode problematikoa isolatzen eta garbitzen joaten da negozioa gelditu gabe. Inoiz ez dena batera.
- Eskalatu azpiegitura kodea osasuntsu dagoenean. Gaizki diseinatutako sistema bati makinak gehitzea arazo beragatik gehiago ordaintzea da. Lehenik kodea konpontzen da; gero muskulua ematen zaio.
Fase bakoitzean sistemak produkzioan jarraitzen du, zerbitzua ematen jarraitzen du eta diru sarrerak sortzen jarraitzen du. Ez dago "berrabiarazte handi" bat non hilabetez ezer berririk entregatzen ez den.
Noiz BAI berridatzi behar den eta noiz den refactor bat besterik ez
Zintzoa izan behar da: batzuetan berridaztea da erabaki zuzena. Baina salbuespena da, ez araua, eta komeni da bi kasuak ondo bereiztea.
Refactor bat da —dagoena bilakatzea— datu eredua zentzuzkoa denean, negozio logika baliozkoa denean eta arazoa errendimenduarena, antolaketarena edo akoplamenduarena denean. Hau da, huts egiten duena nola eraikita dagoen denean, ez zer egiten duen. Hau da kasuen gehiengo handia.
Berridazketa bat da oinarria erabilezina denean: benetako negozioa irudikatzen ez duen datu eredu bat, laguntzarik eta etorkizunik gabeko teknologia bat, edo produktuak orain egin behar duena fisikoki eragozten duen arkitektura bat. Hemen bilakatzea eusten ez duten zimenduen gainean adabakiak jartzea litzateke.
| Egoera | Erabaki zentzuduna |
|---|---|
| Geldo doa baina logika zuzena da | Refactor + faseka eskalatzea |
| Datu ereduak ez du negozioa irudikatzen | Datuen migrazioa, berridazketa partzial posiblea |
| Teknologia zaharkitua edo laguntzarik gabekoa | Berridazketa moduluka, ez kolpetik |
| Aldaketa bakoitzak hiru gauza hausten ditu | Testak + eremu akoplatuen refactor-a |
| Kodea inork ez du ulertzen eta ez dago dokumentaziorik | Dokumentatu eta refactorizatu erabaki aurretik |
Eta ñabardura garrantzitsu bat: berridatzi behar denean ere, ia inoiz ez da dena batera egiten. Moduluz modulu berridazten da, zaharrarekin batera bizituz, pieza bat bestearen ondoren ordezkatu arte. Berridazketa osoa —funtzionatzen duena itzaltzea hilabete geroago zerbait berria pizteko— softwarean existitzen den apusturik arriskutsuenetakoa da.
Benetako kostua: berridaztea bilakatzearen aurka
Hutsetik hasteko tentazioa handia da. Kode zaharrak nagia ematen du, berriak dotorezia agintzen du. Baina zenbakiek gutxitan laguntzen dute intuizio hori.
Hutsetik berridazteak dagoeneko funtzionatzen zuen guztia berriz eraikitzea esan nahi du, egungo sistemak dagoeneko ebazten dituen eta inork programatu izana gogoratzen ez duen ehunka muga kasuak barne. Hilabetez ez duzu balio berririk entregatzen: dagoeneko zenuena berdintzen saiatzen zara besterik ez. Eta bitartean negozioak jarraitzen du, erabiltzaileek jarraitzen dute, lehiakideek jarraitzen dute. Biderik garestiena eta arrisku handienekoa da.
Faseka bilakatzeak kostua banatzen du, sistema bizirik mantentzen du eta urrats bakoitzean itzulkina ikusten uzten du. Ez da hutsetik hastea bezain kitzikagarria, baina kasuen gehiengo handian zentzua duena da. Ondo eraikitako MVP bat ez da erabili eta botatzeko prototipo bat: gainean eraikitzen den lehen bertsio bat da, kutxa beltzik gabe eta inori lotu gabe.
Diagnostikoa erabaki aurretik
Kode lerro bat bota edo "dena berregiteko" aurrekontua eskatu aurretik, urrats zintzoa diagnostiko bat da: non egiten duen min benetan neurtzea, datu ereduak zer baldintzatzen duen, zer den zor berreskuragarria eta zer zimendu erabilezina. Ia beti emaitza da bilaka daitekeela, faseka, sistema martxan dela eta itzulkin neurgarriarekin, hutsetik hasteko apusturik gabe.
Hori da zehazki MVPen eskalatze proiektu batean egiten duguna: proposatu aurretik diagnostikatzen dugu, zein erabakik baldintzatzen duten hazkundea azaltzen dizugu eta uler, neur eta manten ditzakezun sistemak eraikitzen ditugu. Zure MVPak dagoeneko funtzionatzen badu eta karraskatzen hasi bada, hitz egin dezagun zure sistemaz eta zintzotasunez esango dizugu refactor bat, eskalatzea edo —benetan behar bada bakarrik— berridazketa dagokion.