Takto začneš

„Kód neprepisuj“ a „napíš, čo ti chýba“ sú dôležitejšie než samotná otázka.

Toto je trieda zo staršej aplikácie, ktorú som zdedil. Prostredie: [Java verzia, framework, databáza]. Idem do nej [čo ideš urobiť].

Vysvetli mi v piatich vetách, za čo je zodpovedná a kto ju pravdepodobne volá. Potom vypíš miesta, kde sa mení stav alebo sa deje niečo neočakávané, a pri každom napíš, prečo ti to príde podozrivé.

Kód neprepisuj. Ak ti na pochopenie niečo chýba, napíš, čo ti mám doložiť.

[trieda]

Verzie, čo sa nasadilo a čo si už skúsil sú tri vety, ktoré rozhodujú o kvalite odpovede.

Prostredie: [Java verzia, framework, databáza, počet inštancií]. Toto padlo v produkcii, lokálne sa to nedá zopakovať. Včera sme nasadili [čo]. Už som skúsil [čo] — to preskoč.

Daj mi päť hypotéz zoradených podľa pravdepodobnosti a ku každej napíš, ako ju viem za päť minút potvrdiť alebo vylúčiť.

Neuvádzaj metódy ani nastavenia, ktoré v týchto verziách neexistujú — ak si nie si istý, označ to ako „over v dokumentácii“. Kód zatiaľ neprepisuj.

[stack trace alebo výpis z logu]

Najprv zoznam v slovenčine, kód testov až potom. Ty rozhodneš, ktoré prípady dávajú zmysel.

Toto je metóda a takto má fungovať: [kontrakt vlastnými slovami — čo dostane, čo vráti, čo sa nesmie stať].

Vypíš zoznam prípadov, ktoré by som mal otestovať: prázdne a neplatné vstupy, hranice, súbežné volanie, chyby z okolia (databáza, sieť, čas). Ku každému jednou vetou, prečo je dôležitý.

Kód testov zatiaľ nepíš — najprv chcem ten zoznam.

[metóda]

Bez reprodukcie nevieš, či si opravil to, čo si myslel. Preto test pred opravou.

Mám chybu: [čo sa deje a čo by sa malo diať]. Toto je príslušný kód: [kód]. Testy píšem v JUnit 5.

Najprv mi napíš test, ktorý túto chybu spoľahlivo reprodukuje — a povedz, prečo by mal padnúť. Opravu navrhni až potom, zvlášť. Ak ti na napísanie testu chýba kontext, spýtaj sa namiesto domýšľania.

„Buď prísny a nechváľ“ — bez toho dostaneš zoznam toho, čo je na tvojom kóde pekné.

Toto je môj diff pred odoslaním na review: [diff]. Zmena mala [čo mala urobiť].

Buď prísny recenzent a nechváľ ma. Vypíš pripomienky zoradené podľa závažnosti: (1) chyby a riziká, (2) veci, ktoré sa v budúcnosti vypomstia, (3) štýl. Pri každej uveď konkrétny riadok.

Kód neprepisuj — chcem pripomienky, nie hotovú verziu.

Vecná výhrada sa prijíma lepšie než tá istá výhrada napísaná o druhej poobede v zhone.

Toto som chcel napísať do review kolegovi: [tvoja poznámka tak, ako ti napadla].

Prepíš to tak, aby to bolo vecné, konkrétne a nevyznelo ako útok na autora. Zachovaj obsah aj tvrdosť tam, kde ide o skutočné riziko — nezjemňuj to na nič. Max tri vety. Ak je moja výhrada nejasná, napíš, čo v nej chýba.

Model nevie, prečo si to urobil. Tú jednu vetu doplň — zvyšok vytiahne z diffu.

Toto je môj diff: [diff]. Zmena mala [čo mala urobiť a prečo].

Napíš:
1. commit message v imperatíve, prvý riadok max 72 znakov,
2. popis pull requestu — čo sa mení, prečo, čo to ovplyvní a na čo sa má recenzent pozrieť,
3. poznámku do ticketu pre netechnického človeka, max 100 slov.

Nesľubuj nič, čo v diffe nie je.

Posledná veta bráni tomu, aby model za teba sľúbil, že sa staré dáta opravia samy.

Stalo sa toto: [čo sa dialo a čo to spôsobilo, technicky]. Opravili sme to takto: [čo ste urobili].

Napíš poznámku pre [komu — produktová manažérka, podpora, klient]: čo sa dialo z pohľadu zákazníka, čo je odteraz inak a či treba niečo dorobiť ručne so starými dátami. Max 120 slov, bez technických pojmov.

Nesľubuj nič, čo nie je v mojom opise. Ak si niečím nie si istý, napíš to ako otvorenú otázku na koniec.

Vypýtaj si aj správanie na veľkej tabuľke — to je polovica hodnoty odpovede.

Mám tieto tabuľky a stĺpce: [schéma — názvy, typy, vzťahy]. Skutočné dáta neposielam.

Potrebujem dotaz, ktorý [čo má vrátiť]. Napíš ho pre [PostgreSQL / MySQL / Oracle], vysvetli ho po častiach a napíš, ako sa bude správať pri [rádovo koľko] riadkoch a čo by sa oplatilo zindexovať.

Ak je v mojom opise nejednoznačnosť, spýtaj sa namiesto domýšľania.

Ten dotaz s tromi JOINmi, ktorý sa nikto neodvážil zmeniť, prestane byť čierna skrinka.

Tu je dotaz, ktorý som zdedil: [dotaz]. Schéma: [tabuľky a stĺpce].

Vysvetli po častiach, čo robí a v akom poradí. Potom napíš, kedy dá iný výsledok, než človek čaká (prázdne hodnoty, duplicity, typ spojenia, časové pásma), a kde je najpravdepodobnejšie výkonnostné úzke miesto.

Prepis navrhni až na koniec a zvlášť — a napíš, čo presne si v ňom zmenil.

Bez „počítaj kódom“ dostaneš vierohodne vyzerajúce vymyslené číslo.

Toto je [výpis z logu / export] za [obdobie]. Formát riadku je: [čo znamenajú jednotlivé časti]. Citlivé údaje som odstránil.

Pomocou kódu spočítaj: [čo potrebuješ — koľko chýb podľa typu, kedy ich bolo najviac, ktorá služba padá najčastejšie]. Výsledok ukáž ako tabuľku a napíš tri veci, ktoré z tých čísel vyplývajú.

Počítaj, neodhaduj.

Otvorené otázky sú tu cennejšie než samotný zoznam krokov — s nimi ideš za zadávateľom.

Dostal som takto zadanú úlohu: [zadanie tak, ako prišlo]. Aplikácia: [čo to je, aké verzie, čo je okolo].

Rozbi to na kroky v poradí, v akom sa dajú robiť. Ku každému napíš, čo je hotové kritérium. Zvlášť vypíš otvorené otázky, na ktoré potrebujem odpoveď od zadávateľa, a miesta, kde sa to najpravdepodobnejšie zasekne.

Nedomýšľaj si, čo zadanie nehovorí — radšej to daj medzi otázky.

Bez zdrojov je to bezcenné. A rozdelenie na „musím“ verzus „počká“ je to hlavné.

Prechádzame z [verzia] na [verzia] — ide o [Java / framework / knižnica]. Aplikácia používa hlavne [čo z toho reálne používate].

Zhrň, čo sa zmenilo a čo z toho sa nás týka. Rozdeľ to na: (1) čo prestane fungovať, (2) čo treba prepísať pri najbližšom zásahu, (3) čo je len pekné mať. Prilož odkazy na oficiálnu dokumentáciu.

Ak si niečím nie si istý, radšej to označ, než by si to tvrdil.

Cieľ: Prestať čítať zdedené triedy naslepo a prestať sa v stack trace zasekávať sám.

1. 1.Otvor si AI chat a napíš mu dve vety o tom, na čom robíš — verzie, framework, databáza.
2. 2.Vezmi triedu, ktorej roky poriadne nerozumieš, a nechaj si ju vysvetliť. Pridaj „kód neprepisuj“.
3. 3.Skús to isté bez vety „kód neprepisuj“ a porovnaj, čo dostaneš.
4. 4.Pri najbližšej chybe si vypýtaj päť hypotéz podľa pravdepodobnosti namiesto jednej odpovede.
5. 5.Všimni si, kde si model domyslel niečo, čo si mu nepovedal — to je vec, ktorú budeš odteraz dopĺňať hneď.

Cieľ: Mať odstup od vlastného kódu skôr, než ho uvidí kolega.

1. 1.Pri jednej metóde si vypýtaj zoznam hraničných prípadov a označ tie, ktoré ozaj dávajú zmysel.
2. 2.Nechaj napísať testy len na tie, ktoré si vybral, a jeden z nich schválne najprv nechaj padnúť.
3. 3.Pri chybe si vypýtaj najprv test, ktorý ju reprodukuje, a až potom opravu.
4. 4.Svoj diff pred odoslaním nechaj prejsť prísnym recenzentom a pozri, čo z toho sedí.
5. 5.Jednu ostrú poznámku do review si nechaj prepísať tak, aby sa dala prijať.

Cieľ: Zrýchliť SQL a prestať odkladať texty, ktoré sa musia napísať tak či tak.

1. 1.Napíš schému (bez skutočných dát) a nechaj si zložiť dotaz aj s poznámkou, čo zindexovať.
2. 2.Zdedený dotaz s viacerými JOINmi si nechaj rozobrať po častiach.
3. 3.Jeden výpis z logu nechaj spočítať kódom a jedno číslo si over ručne.
4. 4.Z jedného svojho diffu nechaj napísať commit message aj popis PR.
5. 5.Jednu opravu vysvetli biznisu — bez technických pojmov, do sto slov.

Cieľ: Vedieť si rozbiť neurčité zadanie a dobehnúť to, čo si roky odkladal.

1. 1.Vezmi zadanie, ktoré prišlo neurčito, a nechaj si ho rozbiť na kroky a otvorené otázky.
2. 2.S tými otázkami choď za zadávateľom — to je celý zmysel cvičenia.
3. 3.Nechaj si zhrnúť, čo sa zmenilo medzi verziami, ktoré vás čakajú, a otvor aspoň dva zdroje.
4. 4.Rozdeľ si to na „prestane fungovať“, „prepíšem pri najbližšom zásahu“ a „počká“.
5. 5.Rozhodni, ktoré tri prompty ti ostanú uložené natrvalo, a zvyšok zabudni.