
Návrhové vzory v praxi. Kedy pomáhajú a kedy komplikujú kód
Strategy, Adapter a Factory riešia odlišné druhy zmien. Zistite, kedy si každý vzor zaslúži miesto v kóde a kedy je lepšia priama funkcia.
Čo musí IT firma zvládnuť pri dodaní súdneho systému. Na konkrétnych situáciách ukazujeme, čo preveriť pred ponukou a kde sa môže rozrásť práca.

Pri zákazke IS Rozhodnutia NS SR treba naceniť viac než web, na ktorom si človek vyhľadá súdne rozhodnutie. Dodávateľ musí preniesť existujúce dokumenty a postrážiť, aby sa interné materiály nedostali na verejnosť. Práve práca, ktorú na hotovej stránke nevidno, môže zmeniť rozsah celej dodávky.
Zákazku sme vybrali z tipov, ktoré nám poskytol Tender.sk po konzultácii so svojím dátovým tímom. Do plánovanej spoločnej témy IT tender pod lupou prinášame pohľad Rise.sk na to, čo by dodanie systému obnášalo.
Čítali sme revidovaný opis zákazky v prílohe 1A spolu s katalógom požiadaviek a vysvetleniami obstarávateľa. Systém sme nedodávali. Pri kontrole záznamu v EVO 19. októbra 2026 bola súťaž aktívna a lehota na ponuky bola 19. novembra 2026 o 10:00.
Predstavte si rozhodnutie, ktoré sa po presune do nového systému otvorí bez problémov. Chýba mu však údaj o súdnom kolégiu. Človek, ktorý ho hľadá cez tento filter, ho nenájde. Prenos súboru prešiel, no výsledok nie je v poriadku. Je to modelový príklad toho, čo má zachytiť kontrola migrácie.
Zákazka počíta s prenosom starších aj aktuálnych rozhodnutí z úložiska NUXEO. Výslovne to žiada katalóg požiadaviek v bode FR_038. Opis zákazky v časti 2.4.5 k tomu pridáva kontrolu kvality dát.
Začali by sme vzorkou exportu. Tá ukáže, aké dokumenty a ich verzie treba preniesť a ktoré sprievodné údaje chýbajú. Potom sa dohodne, kam každý údaj v novom systéme patrí. Osobitne treba schváliť pravidlá jeho úprav. Chýbajúce kolégium sa nedá doplniť odhadom.
Až potom má zmysel skúšobný prenos. Musí sa dať zopakovať bez vzniku duplicít. Pri odmietnutom zázname potrebuje tím poznať dôvod a vedieť ho dohľadať v pôvodnom úložisku. Pracovník súdu, ktorý pozná obsah rozhodnutí, má overiť dohodnutú vzorku. Pred ostrým prechodom treba zachytiť aj dokumenty zmenené od skúšobného prenosu.
Pre dodávateľa z toho vyplýva konkrétna práca navyše. Do odhadu patrí kontrola dát a čas na riešenie rozdielov s ich vlastníkom. Samotný počet prenesených súborov nestačí.
Pri hľadaní podľa spisovej značky sa dá výsledok overiť pomerne ľahko. Pri otázke "zodpovednosť štátu za prieťahy v konaní" už treba človeka, ktorý vie posúdiť právnu súvislosť nájdených rozhodnutí.
Katalóg požiadaviek opisuje fulltextové vyhľadávanie s filtrami aj súvisiace rozhodnutia a textovú podobnosť. Automaticky z toho nevyplýva, že systém má písať právne odpovede pomocou jazykového modelu.
Navrhujeme pripraviť dve odlišné skúšky. Prvá overí, či vyhľadávanie nájde presný výraz z dokumentu a správne použije filtre. Druhá preverí, či nájde vecne súvisiace rozhodnutia, aj keď otázka používa iné slová. Očakávané výsledky musí potvrdiť človek so znalosťou súdnej agendy. Vývojár sám ich právnu relevantnosť neposúdi.
Pred ponukou zostáva dôležité vyjasniť, komu sú niektoré funkcie určené. V tom istom katalógu má FR_008 kategóriu pre verejnosť, ale označenie Private. Pri FR_004 a FR_028 sa objavujú stavy spracovania alebo neanonymizované dáta. Dodávateľ si musí potvrdiť ich rozsah. Takýto zápis sám osebe neoprávňuje údaje zverejniť.
Predstavme si rozhodnutie, ktoré má prevziať ďalší systém. Nestačí, že si stiahne XML súbor. Potrebuje správne rozpoznať jeho obsah a odkazy na súvisiace predpisy. Aj preto má zadanie osobitné pravidlá pre právne dokumenty.
Príloha 1A v časti 2.2 požaduje REST API s JSON/XML a prepojenie na Register NS SR aj systémy rozhodnutí iných súdov. Pri IS CSSR ide o pripravenosť na budúce prepojenie. Vysvetlenie č. 2 v odpovedi 15 uvádza RESS a odkazuje na otvorené dáta Ministerstva spravodlivosti. Dostupné rozhranie a budúce napojenie nemožno v odhade považovať za rovnako pripravené.
CEN MetaLex určuje pravidlá strojového zápisu právnych dokumentov. Odpovede 13 a 14 v tom istom vysvetlení rozlišujú prototyp a hotový systém. Prototyp má použiť schému zo Slov-Lexu. Pre cieľové rozhodnutia a stanoviská má dodávateľ navrhnúť vlastnú schému podľa zadania. Tieto pravidlá sa týkajú právnych dokumentov s ich väzbami, nie každej správy medzi systémami.
Začali by sme jedným vzorovým rozhodnutím. Previedli by sme ho do dohodnutého zápisu a overili, či ho druhý systém správne prečíta. Pri odkaze do Slov-Lexu treba skontrolovať aj správne znenie predpisu. Úspešná ukážka prototypu ešte neznamená, že je hotový dátový model celého riešenia.
API zároveň potrebuje pravidlá prístupu. Katalóg požaduje prihlásenie cez OAuth 2.0 a oprávnenia podľa rolí. Verejná dokumentácia rozhrania neznamená neobmedzený prístup ku všetkým dátam.
Rozhodnutie sa opraví, ale cez starý odkaz sa stále dá stiahnuť pôvodný súbor. To je ďalší modelový prípad, ktorý by sme pri prevzatí skúšali. Nestačí vidieť novú verziu na stránke.
Opis zákazky v častiach 2.2 a 2.4.1 predpisuje fyzicky oddelenú internú a verejnú časť. Každá má vlastnú správu dokumentov aj fulltext. Prenos smeruje z internej časti do verejnej. Naša ilustrácia ukazuje túto hranicu.

Verejná časť má dostať iba schválené dokumenty a údaje. Ilustrácia Rise.sk podľa verejných podkladov.
Podklad k schéme, revidovaná príloha 1A ÚVONavrhujeme, aby oprávnený pracovník najprv určil verziu na zverejnenie. Potom sa prenesie dokument s povolenými údajmi a aktualizuje vyhľadávanie. Ak niektorý krok zlyhá, musí to tím vidieť. Pri oprave alebo stiahnutí by skúška preverila aj priame stiahnutie súboru, API a uložené kópie vo vyrovnávacej pamäti.
Interní používatelia sa majú podľa katalógu a bezpečnostných požiadaviek napojiť na LDAP/Active Directory súdu. Opis zákazky žiada aj viacfaktorové overenie a obmedzenie prístupu podľa pracovnej roly. V našom návrhu skúšok by sme preto overili aj odobratie oprávnenia. Skryté tlačidlo ešte nedokazuje, že sa k dokumentu nedá dostať inou cestou. Takéto situácie má zmysel prejsť už pri technickej konzultácii zadania.
Systém pri prezentácii funguje. Čo sa však stane, keď ho má prevziať nový prevádzkovateľ alebo obnoviť po výpadku? Aj toto je práca, ktorú treba zahrnúť do ponuky.
Príloha 1A v časti 2.4.1 predpisuje mikroservisy a kontajnery. Ide o požiadavku zadania. Naším odporúčaním je pripraviť nasadenie tak, aby ho prevádzkovateľ vedel zopakovať, a obnovu predviesť v skúšobnom prostredí. Katalóg žiada dokumentáciu a napojenie na bezpečnostné aj prevádzkové nástroje vrátane plánovaného centrálneho monitoringu.
Pred odhadom zostávajú otvorené rozdiely v podkladoch. Katalóg uvádza v NFR_013 najmenej 320 súčasných používateľov, ale v NFR_025 rozlišuje 320 používateľov a 100 súčasných prístupov. Treba potvrdiť, koľko ľudí bude naraz čo robiť a s akými veľkými dokumentmi. Bez toho dodávateľ odhaduje výkon naslepo.
Rozdiel je aj v dostupnosti. Katalóg uvádza 99 %, kým kapitola 6 opisu žiada 99,5 % mimo plánovaných servisných okien. Návrh zmluvy v článku XIX počíta s 99,5 % za kalendárny mesiac. Tieto hodnoty nemožno potichu zjednotiť. Potrebný je záväzný výklad aj spôsob merania.
Pri prototype vysvetlenie v odpovedi 16 stanovuje 30 dní od doručenia výzvy na plnenie, zatiaľ čo článok VII zmluvy používa jeden mesiac. Termín treba potvrdiť spolu s harmonogramom. Dodávateľ si musí preveriť, čo už jeho existujúci produkt vie predviesť. Prototyp môže byť u neho, ale iba s verejnými alebo anonymizovanými dátami.
Pri prevzatí treba podľa zmluvy overiť obnovu a odovzdať kód vytvorený na mieru spolu s dátovým modelom. Pri štandardnom softvéri a open-source komponentoch platia licenčné výnimky. Článok IX zmluvy požaduje päťročnú podporu výrobcu použitého softvéru tretích strán zahrnutú v cene diela, oddelene od voliteľného 12-mesačného paušálu služieb. Objednávateľ tento paušál nemusí objednať.
Pre vývoj softvéru na mieru by sme odhad rozdelili na nasledujúce balíky. Je to náš pracovný návrh, nie predpísané zloženie tímu.
Na menšej obrazovke posuňte tabuľku vodorovne.
| Časť práce | Čo potrebujeme na začiatku | Čo má tím odovzdať |
|---|---|---|
| Návrh a prototyp | Scenáre a prehľad funkcií existujúceho produktu | Dohodnutý návrh a overenú ukážku |
| Prenos dát | Vzorku exportu a pravidlá opráv | Prenesené dáta s dohľadateľnými rozdielmi |
| Portál a vyhľadávanie | Príklady dotazov a očakávané zaťaženie | Použiteľné rozhranie s overenými výsledkami |
| Prepojenia a bezpečnosť | Popisy rozhraní a testovacie prístupy | Fungujúce prepojenia a skúšky oprávnení |
| Prevzatie a prevádzka | Dostupné prostredia a licencie | Dokumentáciu a predvedenú obnovu |

Kto dodá podklady a kto prevezme hotovú prácu? Náš návrh rozdelenia úloh. Konkrétne zodpovednosti určí zmluva.
Verejné súťažné podklady ÚVOPri každom balíku treba vedieť, kto za súd prevezme výsledok a kto dodá potrebné vstupy. Ďalšie otázky k odovzdaniu nájdete v našom kontrolnom zozname bezpečnosti a vlastníctva softvéru.
Rozhodnutie o ponuke má aj obstarávaciu stránku. Spĺňame podmienky účasti a oplatí sa nám ponuku pripravovať? S tým pomáha analýza zákaziek Tender.sk. Ich verejná ponuka zahŕňa posúdenie podmienok účasti. AI asistent odpovede prepája s dokumentmi a pri nejasnostiach je dostupný odborník na verejné obstarávanie. Náš rozbor dopĺňa otázku, či riešenie vieme dodať a čo musí obsahovať odhad.
Titulnú ilustračnú fotografiu vytvoril Mikhail Nilov na Pexels.
Pripravené s AI podporou. Technický rozbor verejných podkladov, nie referencia dodaného systému.

Strategy, Adapter a Factory riešia odlišné druhy zmien. Zistite, kedy si každý vzor zaslúži miesto v kóde a kedy je lepšia priama funkcia.

Porovnajte Next.js s Axum, Askama a htmx podľa stavu v prehliadači, kontraktov, cache, nasadenia, bezpečnosti, mobilných klientov a odovzdania.

Kontrolný zoznam pre kupujúceho softvéru. Pokrýva bezpečnosť, integrácie, roly pri dátach, vlastníctvo, podporu a odovzdanie pred podpisom zmluvy.