1. Analýza a požadavky
Cíl kapitoly: Naučit se převést mlhavé zadání na sadu ověřitelných požadavků dřív, než napíšeš první řádek kódu.
1.1 Proč analýza
Chyba v požadavcích, kterou odhalíš při analýze, tě stojí hodinu diskuse. Ta samá chyba odhalená v produkci stojí dny debugování, hotfix release a důvěru uživatelů. Cena chyby roste řádově s každou fází, ve které přežije. Analýza je proto nejlevnější místo, kde dělat chyby — a proto se vyplatí v ní chyby aktivně hledat.
Praktický důsledek: když dostaneš zadání, tvoje první práce není psát kód. Tvoje první práce je klást otázky, dokud nedokážeš zadání převyprávět vlastními slovy tak, že zadavatel řekne „ano, přesně tohle". Zkus si to hned na zadání paste serveru: dokážeš vlastními slovy popsat decrement-LRU cyklus (zadání, sekce 3), včetně případu, kdy první kandidát po snížení nespadne na nulu? Pokud ne, našel jsi první otázku k položení — před kódem, ne po něm.
1.2 Funkční vs. nefunkční požadavky
Funkční požadavky říkají, co systém dělá. V zadání paste serveru jsou to sekce 1–3: vytvoření paste (formulář i JSON, sekce 1), zobrazení podle mimetype (sekce 2), evikce při plné kapacitě (sekce 3).
Nefunkční požadavky (NFR) říkají, jak dobře a za jakých omezení to dělá. Juniorská chyba číslo jedna je NFR ignorovat — přitom právě ony určují architekturu. Rozdíl mezi paste serverem pro 10 uživatelů a pro 10 000 uživatelů není ve funkcích, ale v NFR.
Pro každý projekt si vynuť odpovědi minimálně na tyto kategorie — v závorce, jak na ně odpovídá zadání paste serveru:
- Kapacita — kolik dat, kolik záznamů, jaký růst? (
MAX_PASTES, konfigurovatelný limit; překročení řeší evikce, ne odmítnutí) - Latence — jaká odezva je přijatelná? p50 vs. p99. (Zadání ji neřeší a výslovně akceptuje O(n) lookup — všimni si, že i „výkon není cíl" je nefunkční požadavek, který musí zaznít)
- Dostupnost / persistence — co se smí stát při restartu? (Čistě in-memory, ztráta dat restartem je akceptovaná — zadání, sekce 4)
- Souběžnost — kolik současných klientů, jaký model přístupu ke stavu? (Sdílený stav za
Mutex, záměrně bez lock-free/sharded přístupů — zadání, sekce 4) - Bezpečnost — kdo smí co, jaké limity vstupů? (Bez autentizace; nesanitizované HTML je pojmenovaná known limitation; limit velikosti paste je v bonusu)
- Vynucená omezení — technologická a výuková. (Pouze
Vec, žádné asociativní kolekce — AK-5. Omezení „proč" nemusí být technické; tady je pedagogické, ale pořád tvaruje návrh)
NFR piš měřitelně. „Server má být rychlý" není požadavek. „p99 latence čtení < 50 ms při 100 RPS" je požadavek — dá se ověřit testem.
1.3 Doménový slovník (ubiquitous language)
Než začneš modelovat, sepiš slovník pojmů domény a používej ho konzistentně v zadání, v kódu i v testech. Když zadání říká „paste", struct se jmenuje Paste, ne Entry ani Item. Slovník paste serveru by vypadal takhle:
| Pojem | Definice |
|---|---|
| Paste | Uložený obsah s UUID, mimetype a LRU metadaty |
| Hit | Zobrazení paste; zvyšuje hits a aktualizuje last_seen_tick |
| Tick | Globální generace přístupů; logické hodiny store |
| Kandidát evikce | Paste s nejnižším last_seen_tick (nejdéle neprohlížená) |
| Decrement-LRU | Evikční cyklus: kandidátovi se snižuje hits, evikuje se až při nule |
| Evikce | Odstranění paste kvůli kapacitě (≠ smazání uživatelem, které je v bonusu) |
Všimni si posledního řádku: slovník zachycuje rozlišení, která by jinak žila jen v něčí hlavě. „Evikce" a „smazání" jsou různé operace s různými pravidly — když to řekneš v tabulce, nikdo je neslije do jedné metody. Tohle je jádro myšlenky ubiquitous language z Domain-Driven Designu: jeden jazyk sdílený zadavatelem, dokumentací a kódem. Každý překlad mezi „jazykem byznysu" a „jazykem kódu" je místo, kde vznikají chyby.
1.4 User stories a akceptační kritéria
User story je formát pro zachycení požadavku z pohledu uživatele:
Jako anonymní uživatel chci vložit text a dostat URL s UUID, abych mohl sdílet log s kolegou.
Dobrá story splňuje kritéria INVEST: Independent (nezávislá na jiných), Negotiable (detail je k diskusi), Valuable (má hodnotu pro uživatele), Estimable (dá se odhadnout), Small (zvládnutelná v jedné iteraci), Testable (dá se ověřit).
Poslední bod je nejdůležitější: ke každé story patří akceptační kritéria. Zadání paste serveru jich definuje šest (AK-1 až AK-6); klíčové scénáře si rozepiš do Given/When/Then podoby — tady AK-3 + AK-4, zobrazeno jako sekvenční diagram interakce klienta se store:
A hned scénář, který z prostého přečtení zadání snadno unikne — vícekolový decrement cyklus:
Všimni si: tahle kritéria jsou zároveň hotové testy — zadání je v sekci Testování výslovně vyžaduje („opakovaný decrement cyklus, kdy první kandidát nespadne na 0"). Analýza a testování nejsou oddělené fáze; dobrá analýza produkuje testy zadarmo. Grafický souhrn případů užití (use case diagram) najdeš v kapitole 2.4.
1.5 Hranice systému
Nakresli (klidně rukou) hranici: co je uvnitř systému, co je venku, a jaká rozhraní hranici protínají. Pro paste server: uvnitř je HTTP API, store s evikční logikou a rendering; venku je klient (curl/prohlížeč). Za povšimnutí stojí, že zadání drží čas uvnitř jako logické hodiny (tick) místo závislosti na systémovém čase — díky tomu je evikce deterministická a testovatelná.
Explicitní hranice ti odpoví na otázky typu: „Má server řešit autentizaci, nebo ji řeší reverse proxy před ním?" Každá nejasná hranice je budoucí spor o to, čí je to zodpovědnost. Stejně cenná je hranice scope: zadání má sekci Bonus (mazání, limit velikosti, konfigurace) — to je formalizované „out of scope, ale víme o tom", které brání jak zbytečné práci, tak výčitce „na tohle jsi nemyslel".
1.6 Výstupní artefakty fáze
Analýza není hotová, dokud nemáš sepsáno (stačí jeden markdown soubor v repu, např. docs/requirements.md):
- Doménový slovník — pojmy a jejich definice (viz 1.3)
- Funkční požadavky — číslované (FR-1, FR-2…), aby se na ně dalo odkazovat z testů, commitů a ADR
- Nefunkční požadavky — měřitelné, včetně vynucených omezení (NFR-1…)
- Akceptační kritéria — klíčové scénáře (klidně jako sekvenční diagramy), včetně těch záludných (vícekolový decrement)
- Hranice systému — co je uvnitř, co venku, co je out of scope
- Otevřené otázky — co ještě nevíš; nepředstírej, že seznam je prázdný
U paste serveru dostáváš body 2–5 v zadání téměř hotové — tvoje analytická práce je slovník (1), rozepsání záludných scénářů (4) a otázky (6).
Zdroje
- Karl Wiegers, Joy Beatty: Software Requirements (3rd ed., Microsoft Press) — referenční kniha o požadavcích, kapitoly o NFR a testovatelnosti
- Scott Wlaschin: Domain Modeling Made Functional (Pragmatic Bookshelf) — ubiquitous language a modelování domény typy; ačkoliv používá F#, přenositelnost do Rustu je téměř 1:1
- Bill Wake: INVEST in Good Stories — xp123.com/articles/invest-in-good-stories-and-smart-tasks
- Gherkin Reference (Cucumber) — cucumber.io/docs/gherkin/reference — formát Given/When/Then, myšlenkový základ pro akceptační kritéria výše
- Eric Evans: Domain-Driven Design (Addison-Wesley) — kapitola 2 (Communication and the Use of Language); zbytek knihy je na juniora těžký, ale tahle kapitola stojí za to