Egyéni fejlesztőknek · 2 nap · Budapest · csak személyesen

Darálod a ticketeket, de a rendszer továbbra is homályos.

Szállítod a ticketeket, de az egész rendszer még mindig ködös. A nagyobb döntéseknél gyakran csak találgatsz.

Az architektúráról szóló beszélgetések nélküled mennek—vagy bent ülsz, de nincs meg az a nyelv, amivel átütően tudsz érvelni. A rendszertervező interjúkon ugyanúgy kijön: ismered a részleteket, de nem tudsz gyorsan, érthetően beszélni a rendszerről.

Ez két gyakorlatorientált nap technikai döntésekről, C4-ről és könnyű ADR-ekről, hogy világosan el tudd mondani, mit építettél, meg tudd védeni a kompromisszumokat, és úgy szólalj meg, mint aki alakítja a rendszert—nem csak aki lekódolja.

A probléma

  • Mélyen benne vagy a megvalósításban, de a függőségek, határok és hibamódok továbbra is homályosak.
  • Minden lényegesebb választás (adatmodell, integráció, szétbontás, „átmeneti” megoldások) bizonytalannak érződik, amikor számít.
  • Nem vagy benne—vagy nem hallanak meg—ott, ahol a technikai irányt tényleg eldöntik.
  • Amikor valaki azt kérdezi: „miért így csináltuk?”, a becsületes válasz gyakran az, hogy „senki nem emlékszik”.
  • A rendszertervező helyzetek leleplezik a rést: ismered a részeket, de nem tudsz belőlük gyorsan összefüggő történetet rakni.

Ha ilyen egy átlag heted, akkor Neked szól.

Mi ez valójában

Ez nem „szemlélet”-ről szóló diasor. Kiscsoportos, személyes képzés, ahol valós döntési mintákon dolgozol: szétválasztod a korlátokat a véleményektől, összehasonlítod az opciókat kockázat és költség szerint, és akkor hagysz rövid nyomot, amikor számít.

Az ADR-ek annyiban jelennek meg, amennyire kellenek: egy kis, ismételhető formátum arra, hogy „mit döntöttünk, mit fontolgattunk még, mi törik el, ha tévedünk”—nem vállalati papírtologatás.

A C4 az, ahogy olvashatóvá teszed a rendszert: kontextus, konténerek, komponensek—hogy te és mások ugyanazt értsék a határokról és a felelősségről, ne egymás fejében élő modellekről vitázzatok.

Eredmény: döntések, amiket meg tudsz indokolni, diagramok, amikre rá tudsz mutatni, és olyan kommunikáció a termékkel és a vezetéssel, ami nem fullad zsargonba.

Mit viszel haza

  • Újrahasználható döntési checklista valós feladatokhoz és tervezési egyeztetésekhez—nem egyszeri elmélet.
  • Egy-két C4 nézet (kontextus, konténer, komponens) a saját rendszeredre vagy egy teremben vett konkrét példára—bemásolható a doksiba vagy interjúfelkészítésbe.
  • ADR vázlatok, amiket a képzésen írtál (visszajelzéssel), hogy már egyszer végigcsináld, mielőtt visszaülsz a munkához.
  • Képes leszel néhány perc alatt végigvezetni valakit a rendszereden egy diagrammal és egy rövid döntéstörténettel.
  • Élesebb felkészülés rendszertervező jellegű beszélgetésekre és arra, hogy komolyan vegyenek, amikor tényleg eldőlnek a kompromisszumok.

Hogyan működik

  • Két nap, Budapest, kiscsoport. Csak személyesen—a közös tábla és a modellezés nélkülözhetetlen; nincs online közvetítés.
  • Rövid elmélet, sok gyakorlat: opciókat hasonlítasz, rajzolsz, írsz—nem csak végighallgatsz.
  • Hozd a saját „rendetlenséged”: egy rendszert, amin dolgozol, vagy egy döntést, ami még mindig zavar. Lesznek életszerű példák is, ha belső részleteket nem oszthatsz meg.

Nem oklevéllel és homályos „felismeréssel” mész haza - hanem dolgokkal, amiket bemásolhatsz Confluence-be, Notionba vagy a repóba.

1. nap — Döntések nyomás alatt

Tisztázod a valódi döntést, összeveted a kompromisszumokat, és akkor rögzítesz röviden, amikor számít—az ADR könnyű keret, nem dokumentációs színház.

Döntési helyzetek tisztázása

  • Korlátok, feltételezések és célok szétválasztása.
  • A valódi döntési kérdés megfogalmazása zajos helyzetekben.

Opciók és kompromisszumok összevetése

  • Alternatívák összevetése kockázat, költség és változtatási ár alapján.
  • Döntési indoklás érthető kommunikálása technikai és üzleti nézőpontból.

Rövid döntési lenyomatok (ADR mint keret)

  • Mikor érdemes rögzíteni egy döntést, és mikor elég szóbeli megállapodás.
  • Könnyűsúlyú sablon használata úgy, hogy ne legyen adminisztrációs teher.

2. nap — Láthatóvá teszed C4-gyel

C4-gel modellezed a rendszert, felismered a csatolást és a felelősségmegosztás hiányosságait, és diagramokat plusz rövid döntésjegyzeteket egy mesévé fűzöl.

C4: kontextus- és konténernézet

  • Rendszerhatárok és külső függőségek modellezése.
  • Felelősségek és kulcs interakciók tiszta jelölése.

C4: komponensnézet

  • Konténerek bontása értelmes komponensekre és interfészekre.
  • Kockázatos csatolások és homályos felelősségmegosztás felismerése.

Döntések kommunikálása diagramokkal és rövid leírásokkal

  • A diagramok és rövid döntési leírások összerendezése közös történetté.
  • Ismételhető kommunikációs rutin kialakítása csapaton belül és kívül.

Kiknek szól?

  • Medior–senior fejlesztőknek, akik senior, staff vagy tech lead irányt céloznak—nem még egy év „csak Jira zárás”.
  • Akik rendszer-szintű jártasságot akarnak: hogyan kapcsolódnak, buknak el és változnak a részek—nem csak keretrendszer-API-kat.
  • Akik interjúra is hasznos tisztaságot akarnak: architektúra és kompromisszumok strukturáltan, időnyomás alatt.
  • Mérnököknek, akiknek elege van abból, hogy fölöttük döntenek úgy, hogy nincs mivel érdemben visszavágni.

Kiknek nem szól?

  • Kezdőknek, akik még az alap programozást tanulják.
  • Akik csak előadást akarnak gyakorlat és közös átnézés nélkül.
  • Akik nem hajlandók a teremben rajzolni, írni és megvédeni egy döntést.
  • Akiknek kötelező a távoli részvétel—tábla nélkül ez a formátum nem működik.

Következő lépés

Iratkozz fel a várólistára—amikor írok a budapesti időpontokról, küldhetsz pár mondatot egy rendszerről, amin dolgozol (vagy két döntésről, amit még mindig nehéz megindokolni). Elég néhány mondat; ebből hangolom a példákat és ellenőrzöm, hogy illik-e a csoport.