Architecture-first konzultace: co to vlastně znamená

„Architecture-first“ je fráze, která dobře vypadá v hero sekci webu a pro lidi, co kupují konzultace, neznamená nic. Každá agentura vám řekne, že jejich architekti jsou senior. Každé butikové studio tvrdí, že design dává před kód. V praxi většina z nich pošle v prvním týdnu juniorní vývojáře psát kód a výsledek pak zpětně popíše jako architekturu.

Zkusme to tedy udělat testovatelné. Tady je, co architecture-first v našich zakázkách skutečně znamená, a čtyři konkrétní věci, které kvůli tomu odmítáme dělat.

Pracovní definice

Architecture-first znamená: než se napíše první řádek produkčního kódu, máme sepsáno — a s vámi odsouhlaseno — jak řešení vypadá, které jeho části jsou rizikové a proč jsme ho vybrali před třemi alternativami, o kterých jsme uvažovali.

Konkrétně jde o Architecture Decision Document. Má tři sekce:

1. Diagram. Systémový obrázek, který ukazuje komponenty, jejich trust boundaries a hlavní toky. Ne UML veledílo — obrázek v kvalitě whiteboardu, který kdokoli technický přečte za 90 sekund.
2. Rozhodnutí. 5–15 číslovaných ADR (Architecture Decision Records). Každý říká: „Vybrali jsme X před Y, protože Z.“ Nic víc. Budoucí údržbář je proletí za deset minut a pochopí, proč systém vypadá, jak vypadá.
3. Rizika. Co se může pokazit, jakou tomu přisuzujeme pravděpodobnost a co uděláme, když se to stane. Ne divadelní lomení rukama — 3 až 7 reálných položek, které si zaslouží pozornost.

To je celý artefakt. Jeho úkolem je udělat neshody levné a viditelné dřív, než se z nich stane přepsaný kód.

Čtyři věci, které odmítáme dělat

1. Nezačínáme „pojďme to prostě naprototypovat“

„Nejdřív prototyp, architektura potom“ je legitimní přístup, když je problém jasně neznámý. V 95 % případů problém známý je — pod tlakem je obchodní tým, který chce rychle něco ukázat. Prototype-first v takových případech produkuje kód, který se dostane do produkce, aniž by se architektura kdy sepsala. Šest měsíců nato je z toho „ten prototyp“, který se každý bojí měnit.

Když je prototyp skutečně ten správný tah (třeba pro ověření netriviálního technického předpokladu), nastavíme si dopředu throwaway budget: dva týdny, jeden vývojář a explicitní povolení všechno smazat.

2. Neúčtujeme vám psaní univerzálních frameworků

Konzultační projekty mají nehezký zvyk nafukovat interní frameworky, které dávají smysl jen uvnitř toho projektu. Vlastní knihovny formulářů, šité i18n wrappery, in-house state machines. Vývojáři, který je píše, připadá, že je produktivní, a ve chvíli, kdy přijde někdo nový, se z nich stane závazek.

Pravidlo: pokud existuje rozumná knihovna třetí strany, použijeme ji. Chakra UI, React Hook Form, TanStack Query, Zod, Prisma — nejsou glamourní, ale udržuje je víc lidí, než jaký konzultační projekt kdy dohromady dá. Vlastní stavíme jen tam, kde doména skutečně nemá ekvivalent off-the-shelf.

3. Neoddělujeme „architekta“ od „inženýrů“

Klasický pattern selhání: senior architekt navrhne systém, junior inženýři ho píšou a architekt zmizí na další projekt. Nevyhnutelný výsledek — juniorní tým narazí na designový edge case, se kterým architekt nepočítal, improvizuje kolem něj, a architektura se do pár týdnů odchýlí od diagramu.

U nás na projektech platí: kdo napsal architekturu, ten v tom projektu píše i produkční kód. Ne jako kontrolní mechanismus — jako zpětnovazební smyčka. Pokud designové rozhodnutí dělá kód neohrabaným, všimneme si toho v druhém týdnu, ne v šestém měsíci, kdy to odhalí integrační testy.

4. Neděláme čisté poradenství

Neděláme ten stereotyp „napíšeme vám report a jdeme dál“. Písemná doporučení, která nikdo neimplementuje, mají nulovou hodnotu. Písemná doporučení, jejichž implementaci pomáháme, stojí za to, co se za ně zaplatilo.

Když napíšeme architektonický dokument, buď ho doneseme až k dodání, nebo ho předáme konkrétně jmenovanému inženýrovi, který to udělá — ne mlhavé „možná váš tým půjde podle ADR“. Obvykle to znamená, že zůstaneme u projektu minimálně přes první produkční release toho, co dokument popisuje.

Proč je to pro váš projekt důležité

Většina konzultačních hororových příběhů se dá vystopovat k jedné z těch čtyř věcí. Prototyp, který se stal produkcí. Vlastní framework, který nikdo neudrží. Architekt, který zmizel. Report, který zůstal na shared disku.

Architecture-first konzultace neznamená, že strávíte měsíce, než uvidíte kód. V praxi píšeme architektonické dokumenty obvykle do 48 hodin od prvního rozhovoru. Jsou krátké, vyhraněné a v malých věcech špatné — ale ty se opraví v kódu. Nejde o to design zmrazit — jde o to, aby byly neshody vidět, dokud jsou levné.

Pokud vybíráte mezi konzultanty, nejjednodušší test: zeptejte se na poslední architektonický dokument, který vyprodukovali, začerněný kvůli důvěrnosti. Jestli si ho musí na schůzku vymyslet, víte, co kupujete.