Kio estas YAGNI?
Inĝeniera kulturo kaj programara praktiko
YAGNI estas mallongigo de "You aren't gonna need it" (Vi ne bezonos tion). Ĝi estas principo de programara dezajno, kiu diras ke oni ne konstruu funkcion, abstraktadon aŭ etendpunkton antaŭ ol ekzistas reala, aktuala bezono por ĝi. La ideo devenas el Extreme Programming kaj puŝas teamojn for de spekulativa dezajno. Ne temas pri malatento aŭ mallongvida pensado. Temas pri teni la programaron simpla nun, por ke ĝi povu ŝanĝiĝi pli facile kiam la estonteco fine alvenos.
Reviziita de Jackie, Estro de Lernado kaj Disvolviĝo, Levellers - Laste reviziita la 8-an de junio 2026
Kion tio signifas
YAGNI estas la kultura permesilo, kiun multaj inĝenieroj bezonas kiam ili estas tentitaj konstrui por imagitaj estontecoj. Anstataŭ demandi "kion ĉi tiu sistemo eble bezonos iam?", ĝi demandas "kion ni scias, ke ni bezonas nun?" Tio sonas preskaŭ tro simpla, kio parte klarigas kial la frazo daŭre vivis.
La principo estas rekta, ĉar trotruismo estas ofta. Teamoj ofte aldonas opciojn, hokojn, rolojn, ĝeneralajn datummodelojn aŭ arkitekturon "por poste". Poste eble alvenos, sed same ofte ne. Dume, ĉiuj pagas la koston de portado de kodo, kiu hodiaŭ nenion utilan faras.
YAGNI ne signifas pretendi, ke la estonteco ne ekzistas. Ĝi signifas rifuzi komplikigi la nunan momenton pli ol necese surbaze de konjektoj.
Kial ĝi gravas
YAGNI gravas ĉar programaro estas plena de allogaj eblecoj. Eble ni bezonos kvin pagajn provizantojn. Eble ni dividos tion en multajn malgrandajn servojn. Eble klientoj volos proprajn laborfluksojn, altnivelajn permesojn, kromaĵojn, ŝablonojn kaj amasan importon. Kapo plena de eblecoj povas transformi unu modestan produkton en storejon de nepruvitaj funkcioj.
Tio havas praktikajn sekvojn. Ekstra kodo devas esti reviziita, testita, klarigita, sekurigita, monitorita kaj ŝanĝita. Eĉ kiam neniu uzas la funkcion, la teamo ankoraŭ devas kompreni la meĥanismon ĉirkaŭ ĝi. La programaro peziĝas antaŭ ol ĝi saĝiĝas.
Por gvidantoj kaj produktaj homoj, YAGNI estas valora ĉar ĝi protektas la lernadrapidecon. Ĝi ŝanĝas la klopodon for de imagitaj estontecoj kaj reen al la sekva afero, kiun la teamo efektive povas liveri, observi kaj plibonigi. En juna produkto aŭ ŝanĝiĝanta merkato, tio ofte estas la diferenco inter impulso kaj drivo.
Kiel ĝi funkcias
De kie venas la frazo
YAGNI kreskis el Extreme Programming, ofte mallongigita kiel XP, en la malfruaj 1990-aj jaroj. Martin Fowler spuras la frazon al frua konversacio inter Kent Beck kaj Chet Hendrickson en la projekto Chrysler C3. La slogano restis ĉar ĝi estis memorinda, iomete petola kaj ĝene efika.
Ĝi sidas apud alia XP-frazo: "Faru la plej simplan aferon, kiu eble funkcius". Kune, tiuj ideoj kuraĝigas teamojn solvi la problemon efektive sur la tablo, ne la pli grandan kaj pli glamuran problemon, kiu eble aperos poste.
Kial atendi estas ofte pli malmultekosta
La principo aspektas konservativa, sed ĝi vere temas pri ekonomiko. Konstrui ion frue kreas almenaŭ tri kostojn.
Unue, estas la rekta konstrukosto. Iu devas dezajni ĝin, kodi ĝin, testi ĝin kaj klarigi ĝin.
Due, estas la prokrastkosto. Tempo pasigita konstruante estontan funkcion estas tempo ne pasigita liverantante tion, kion uzantoj bezonas nun. Teamo povas esti tre okupata kaj tamen malfrui al la valora parto.
Trie, estas la portadkosto. Ĉiu ekstra branĉo, klaso, agordo kaj interfaco malfaciligas la komprenon de la kodbazo. Eĉ se tiu estonta funkcio neniam estas ŝaltita, ĝi ankoraŭ okupas lokon en la mensoj de homoj. Fowler kadrigas tion kiel la koston de portado de ekstra komplekseco, kaj tio estas unu kialo kial YAGNI temas pri pli ol nur pli rapida livero.
Kiel YAGNI travivas kontakton kun realeco
La kutima objekcio estas evidenta: kio se la estonteco efektive alvenas? Kio se la afero, kiun vi preteratentis, rezultas bezonata post ĉio?
Tio povas okazi. YAGNI ne estas promeso, ke atendi estas ĉiam senkosta. Ĝi estas juĝo, ke spekulativa dezajno kutime kostas pli ol ĝi ŝparas, kondiĉe ke la teamo tenas la kodon facile ŝanĝebla. Tial YAGNI dependas de refaktorado, signifante plibonigon de la interna strukturo de kodo sen ŝanĝi tion, kion uzantoj vidas. Ĝi ankaŭ dependas de testoj, kontinua integrado, kaj kulturo, kiu traktas dezajnon kiel ion, kio evoluas, anstataŭ ion, kion oni devas diveni perfekte en la unua tago.
Alivorte, YAGNI ne estas simple principo de sindeteno. Ĝi estas interkonsento. Ni ne konstruos la funkcion de morgaŭ hodiaŭ, kaj kontraŭe ni tenos la kodon de hodiaŭ sufiĉe fleksebla por ŝanĝiĝi morgaŭ.
Kiel ĝi aspektas en praktiko
Teamo konstruanta retan vendejon komencas per unu impostregimo anstataŭ universala regulomotoro por ĉiu lando sur la tero. Kompanio kun unu aplikaĵo tenas ĝin kiel unu deplojeblan unuon anstataŭ dividi ĝin en multajn malgrandajn servojn antaŭ ol la komercmodelo estas pruvita. Raportila ilo havas unu eksportformaton ĉar tio estas kion klientoj petis, ne ses ĉar "iu verŝajne volos ilin". Permesmodelo komencas per administranto kaj normala uzanto, ne katedralo de nestitaj roloj.
YAGNI ankaŭ aplikas al koda reuzado kaj abstraktado. Inĝenieroj ofte vidas ripetajn ŝablonojn unu aŭ du fojojn kaj estas tentitaj salti rekte al majstra kadro. Bonaj teamoj atendas la trian aŭ kvaran realan ripeton antaŭ ol ili ĝeneraligos. Tiel, la komuna formo estas malkovrita el sperto anstataŭ inventita en espero.
Ĉi tie YAGNI diferencas de simpla ŝparemo. Ne temas pri "faru malpli ĉar malpli estas malmultekosta". Temas pri "faru malpli ĉar la realeco instruos al vi, kio meritas ekzisti".
Kio YAGNI ne estas
YAGNI ne estas instrukcioj konstrui malfortikan rubon. Ĝi ne pardonas malbonan nomumaron, malfortajn testojn, malatenteman sekurecon aŭ ignoradon de malfacilaj postuloj. Se via produkto devas plenumi juran regulon, alireblecan normon, konatan trafikan nivelon aŭ latenteccelon, tiam tiu laboro ne estas spekulativa. Ĝi estas parto de la aktuala postulo.
Nek estas YAGNI kontraŭdezajna. Teamoj ankoraŭ dezajnas. Ili simple faras tion en pli malgrandaj, pli reversiblaj paŝoj. Anstataŭ desegni grandan mapon por ĉiu estonta kvartalo en la urbo, ili faras unu straton facile etendebla kiam la sekva kvartalo fariĝas reala.
Tial la Boy Scout Rule apartenas proksime. Se ĉiuj lasas la kodon iomete pli klara ĉiufoje kiam ili tuŝas ĝin, atendi fariĝas malpli timiga. Sen tiu konstanta ordigo, YAGNI povas soni kuraĝa sur papero kaj sentiĝi senprudenta en realeco.
Ekzemploj
Produkta teamo konstruas rezervan aplikaĵon por lokaj kursoj. Ili scias, ke iam ili eble pritraktos abonojn, donackarton, agentejajn ensalutojn kaj merkatajn elpagiĝojn. Anstataŭ modeli ĉiun el tiuj kazoj de la komenco, ili konstruas unuopajn eventorezervaĵojn kaj unu pagflukson. La aplikaĵo lanĉiĝas. Realaj klientoj uzas ĝin. Ses semajnojn poste, la teamo ekscias, ke atendolistoj gravas multe pli ol donactkartoj. YAGNI protektis la atenton.
Inĝeniera teamo supozas, ke sukcesa produkto eventuale bezonos multajn malgrandajn servojn. Anstataŭ dividi la sistemon tuj, ili konstruas unu bone organizitan aplikaĵon kun klaraj modullimoj. Jaron poste, ili havas realajn uzadpadronojn kaj povas vidi, kiuj limoj estas sufiĉe stabilaj por apartigi kaj kiuj estis nur dezirema pensado.
Programisto aldonas dosiersuŝargojn. Dum laborado, li imagas, ke estontaj klientoj eble volos suŝargojn el lokaj dosieroj, nuba stokado, retpoŝto, poŝtelefona fotilo kaj publika programada interfaco. YAGNI diras: subtenu la vojon, kiun uzantoj bezonas nun, tenu la kodon ordigita, kaj atendu ĝis la dua vojo estas fakto anstataŭ fantazio.
Oftaj miskomprenoj
Ofta miskomprenado estas, ke YAGNI signifas "faru la plej stultan aferon eblan". Ne tiel. La principo petas la plej simplan aferon, kiu bone plenumas la aktualan bezonon, ne la plej malfortikan aferon, per kiu teamo povas eskapi.
Alia miskomprenado estas, ke YAGNI malpermesas ĉian antaŭvidon. Ne tiel. Bonaj inĝenieroj ankoraŭ rimarkas kie ŝanĝo estas verŝajna. Ili simple rezistas transformi tiun intuicion en permanentan strukturon antaŭ ol ĝi meritas sian lokon.
Kelkaj homoj pensas, ke YAGNI signifas, ke kodo neniam estu reuzebla. La principo estas pli milda ol tio. Reuzado estas bonvena kiam ripetaj realaj bezonoj malkaŝas la formon de io komuna. Estas spekulativa reuzado, kiu kaŭzas problemojn.
Ekzistas ankaŭ mito, ke YAGNI konfliktas kun dezajno. En sanaj teamoj ĝi kutime akras la dezajnon. Per forigo de imagitaj postuloj, ĝi devigas la teamon kompreni la realan problemon pli klare.
Riskoj kaj limoj
YAGNI povas esti trotrudita. Teamo eble kaŝiĝas malantaŭ ĝi por eviti malfacilajn sed genuajn postulojn. Se sekureco, konformeco, alirebleco, datumkonservado aŭ konataj rendimentpostuloj jam estas parto de la tasko, ili ne estas "poste". Ili estas nun.
Ĝi ankaŭ povas malsukcesi kiam kodo estas malfacile ŝanĝebla. Se teamo preteratentis estontecan dezajnon sed ankaŭ neglektis testojn, refaktoradon kaj bazan strukturon, ĝi ne sentiĝos lerta poste. Ĝi sentiĝos kaptita en angulo. YAGNI estas sekura nur kiam la teamo investas en ŝanĝebleco.
Ekzistas ankaŭ kazoj kie frua decido estas genuaj multekosta por inversigi, precipe en vaste uzataj publikaj interfacoj aŭ infrastrukturo kun longdaŭraj kontraktoj. En tiaj kazoj, iom pli da antaŭvido povas esti saĝa. La limo ne estas "neniam pensu antaŭen". La limo estas: ne faru la kodon de hodiaŭ servi la konjektojn de morgaŭ, krom se la kosto de atendado estas vere pli alta.
Kion fari poste
Se via teamo daŭre konstruas por imagitaj estontecoj, komencu per videbligado de ne-celoj. Skribu, kion la aktuala eldono ne provas fari. Tio sonas baza, sed ĝi havas kvietigan efikon sur ĉambro plena de entuziasmaj inĝenieroj.
Kiam propono aperas por ekstra fleksebleco, demandu tri demandojn. Kiun aktualan bezonon ĉi tio servas? Kiun kompleksecon ĝi aldonas nun? Kion ĝi efektive kostus aldoni poste, se la bezono fariĝas reala? Tiuj demandoj transformas YAGNI el slogano en decidkutimon.
Protektu la praktikojn, kiuj faras YAGNI sekura. Tenu testojn sanaj. Faru refaktoradon normala. Kuraĝigu malgrandajn, reversiblajn dezajnpaŝojn. Rekompencas teamojn por livero de utilaj ŝanĝoj kaj por forigo de kodo, kiu ekzistas nur por imagitaj estontecoj.
Precipe, ĉesu egali videblan kompleksecon kun seriozeco. Maturaj teamoj ne estas tiuj, kiuj antaŭkonstruas ĉiun estontecon. Ili estas tiuj, kiuj povas adaptiĝi rapide kiam la estonteco fine elektas unu.
Ĉu vi havas demandon aŭ sugeston, aŭ volas kompreni kiel ni esploras kaj reviziis ĉi tiujn gvidilojn? Legu pri niaj redakciaj normoj kaj kiel kontakti nin.
Oftaj demandoj
Kion YAGNI efektive signifas?
Ĝi signifas "You aren't gonna need it" (Vi ne bezonos tion). La frazo diras, ke kapablo ne estu konstruita ĝis ekzistas reala bezono por ĝi.
Ĉu YAGNI estas la sama kiel konstrui MVP?
Ili estas rilataj, sed ne identaj. MVP temas pri lernado el la plej malgranda utila produkto. YAGNI estas dezajnkutimo, kiu rezistas spekulativajn funkciojn kaj abstraktadojn.
Ĉu YAGNI signifas, ke ni neniam planu antaŭen?
Ne. Ĝi signifas, ke planoj ne aŭtomate fariĝu kodo. Vi povas rekoni verŝajnajn estontajn bezonojn sen konstrui ĉiujn el ili hodiaŭ.
Kio faras YAGNI sekura?
Kodbazo facile ŝanĝebla. Testoj, refaktorado, klara strukturo kaj konstanta koda revizio estas tio, kio faras prokrastitajn decidojn praktikaj.
Ĉu YAGNI estas kontraŭ arkitekturo?
Ne. Ĝi estas kontraŭ spekulativa arkitekturo. Teamoj ankoraŭ dezajnas, sed en pli malgrandaj paŝoj kaj kun pli da preteco revizii.
Kiam ni ignoru YAGNI?
Kiam la postulo jam estas reala kaj multekosta prokrasti, kiel konformecaj reguloj, konataj skalceloj, striktaj rendimentbezonoj aŭ longdaŭraj publikaj kontraktoj.