Code review po angielsku — laptop z otwartym GitHub PR view, dymek z komentarzem, ikony LGTM/WIP/nit i kawa
TL;DR — przed startem

Główne wyzwanie dla Polaków: łagodzenie wypowiedzi w angielskim biznesowym — nasz polski „wrong, fix this" brzmi po angielsku jako agresywny atak.

Conventional Comments: standard 2026. Prefix każdego komentarza: praise / nitpick / suggestion / issue / todo / question / thought.

50 fraz w 5 kategoriach: asking questions · making suggestions · pointing out issues · praising · clarification.

PR description (5 sekcji): What · Why · How · Testing · Screenshots.

AI tools 2026: Copilot Review, ChatGPT do dopracowywania komentarzy, PR-Agent (open source).

Słowniczek skrótów (review jargon):

PR / MR — Pull Request / Merge Request (zmiana do merge'u).
LGTM — Looks Good To Me (approval).
WIP / DRAFT — Work In Progress (nie merge'uj jeszcze).
TLDR — Too Long Didn't Read (summary).
FYI — For Your Information (info bez akcji).
IMO / IMHO — In My (Humble) Opinion.
nit — nitpick, drobna sugestia opcjonalna.
blocker — krytyczny issue blokujący merge.
YAGNI / DRY / KISS — design principles.
SLAP — Single Level of Abstraction Principle.

Spis treści

Czemu code review po angielsku jest trudne dla Polaków

Code review jest najczęściej używaną formą pisemnej komunikacji zawodowej developera. W typowym tygodniu polski dev w Big Tech pisze 20-40 komentarzy review — po angielsku, dla zespołów rozproszonych po świecie. To codzienny kontakt zawodowy z angielskim.

20-40
komentarzy review / tydzień (typowy dev)
95%
PR (Pull Request) w PL Big Tech po angielsku
200-400
optymalna wielkość PR (LoC = lines of code)
35%
problemów z atmosferą zespołu przez nieporozumienia

3 główne wyzwania dla Polaków

1. Polska bezpośredniość vs anglosaskie łagodzenie wypowiedzi

Polski jest językiem bezpośrednim. Mówimy „Pomysł nie zadziała, popraw". Brzmi normalnie po polsku. Po angielsku ten sam komunikat: „This won't work, fix it" odbierany jest jako agresywny atak. Native pisze: „I'm not sure this approach handles edge case X — could we explore alternative Y?". Ta sama treść, dramatycznie inny ton.

2. Brak słownictwa łagodzącego (softeners)

Angielski biznesowy ma rozbudowany system słów łagodzących (softeners) — wyrażeń, które łagodzą krytykę bez utraty znaczenia. Klasyczne: „could", „might", „perhaps", „I'd suggest", „we could consider", „it might be worth exploring". Bez nich komunikat brzmi szorstko. Większość polskich devów A2-B1 ich nie zna — w efekcie powstają dosłowne tłumaczenia z polskiego, które brzmią nieprofesjonalnie.

3. Krytyka KODU vs krytyka AUTORA

Anglosaska kultura biznesowa rygorystycznie oddziela krytykę wyboru technicznego od krytyki osoby. „You wrote bad code" — atak na osobę. „This implementation has X edge case" — krytyka kodu. Polscy devowie często mylą te dwa, co prowadzi do tarć w zespole.

Pro tip dla każdego komentarza: przed wysłaniem, przeczytaj go w głowie głosem szefa, którego nie lubisz. Jeśli brzmi pasywno-agresywnie albo atakująco, przepisz. „Czyste czytanie głosem antagonisty" wykrywa 80% problematycznych komentarzy.

Anatomia dobrego PR description (5 sekcji)

PR description (opis Pull Requestu) to pierwsza rzecz, którą reviewer czyta. Zła opisem = reviewer musi sam dochodzić do wniosków, traci 30-60 minut. Dobra opisem = reviewer ma kontekst w 30 sekund i może skupić się na kodzie. Standard branżowy 2026 — 5 obowiązkowych sekcji:

Anatomia dobrego PR description — 5 sekcji ułożonych jak document: WHAT, WHY, HOW, TESTING, SCREENSHOTS

Przykład profesjonalnego PR description

📋 WHAT
Adds support for OAuth2 authentication via Google and GitHub providers. Users can now sign up / log in with their Google or GitHub account in addition to email/password.
🎯 WHY
Closes #1234. Required for Q1 OKR on user retention — Google login reduces signup friction by 60% based on industry benchmarks (auth0.com/blog/social-login-conversion). Aligns with our growth team's strategy.
🔧 HOW
Implemented using Passport.js strategies. New `OAuth` model stores provider tokens with KMS encryption. Refresh tokens rotated every 24h. Backward compatible — email/password flow unchanged.
✅ TESTING
- Unit tests: 95% coverage on new auth module
- Integration tests: full OAuth flow for both providers
- Manual E2E: tested on staging with 3 different Google accounts + 2 GitHub accounts. Login + logout + token refresh + edge case (expired token) all working.
📸 SCREENSHOTS / SCREENCAST
[Loom: 2-min walkthrough of new login UI]
[Screenshot: new OAuth provider buttons on login page]
[Figma: design source]

Krótka lista kontrolna dla PR (Pull Request) description

  • ✅ Title in imperative form: „Add OAuth2 support" (NIE „Added" / „Adding").
  • ✅ Linkuj do issue / ticket: „Closes #1234" / „Fixes JIRA-456" (auto-zamknie ticket po merge).
  • ✅ Wyjaśnij WHY przed HOW — reviewer zrozumie kontekst, zanim zanurkuje w kod.
  • ✅ Bullet points zamiast wall of text (reviewer skanuje, nie czyta).
  • ✅ Screenshots / screencast dla UI changes (Loom, OBS).
  • ✅ Linkuj related PRs jeśli ta zmiana jest częścią serii.
  • ✅ Mark jako DRAFT jeśli nie gotowe do review (nie marnuj czasu reviewerów).

Conventional Comments — standard 2026

Conventional Comments (conventionalcomments.org) to format opracowany przez open source community 2018-2020, dziś standard w Big Tech. Każdy komentarz zaczyna się od prefixu oznaczającego TYP feedbacku. Korzyści:

  • Jasna intencja — autor wie co naprawić, co rozważyć, co zignorować.
  • Mniej tarć — pochwały są wyraźne, drobne uwagi nie są blokerami.
  • Łatwiejsza priorytetyzacja — issue blocking idą pierwsze, nitpicki na końcu.
  • Mierzalność — zespoły mogą liczyć rozkład typów (za dużo issues = problem z requirements; za dużo nits = problem z linterem).

7 głównych prefixów

praise: Pochwała

Doceń dobrą decyzję / kod. Buduje atmosferę w zespole. Często pomijane przez Polaków — używaj!

praise: Nice use of the Strategy pattern here — makes adding new payment providers trivial.
nitpick: Drobiazg (opcjonalny, non-blocking)

Drobna uwaga estetyczna / stylistyczna. NIE blokuje merge'u.

nitpick (non-blocking): Variable name `x` could be more descriptive — perhaps `userCount`?
suggestion: Propozycja (do rozważenia)

Konkretna sugestia ulepszenia. Autor decyduje, czy ją zastosuje.

suggestion: Consider extracting this validation logic into a separate function — it's used in 3 places and could be reused.
issue: Problem do naprawienia (potential blocker)

Realna wada — bug, security risk, broken edge case. Wymaga akcji od autora.

issue (blocking): This regex doesn't handle international characters — `/^[a-zA-Z]+$/` will reject names like „Łukasz". Should use `/^\p{L}+$/u`.
todo: Drobna zmiana wymagana

Trywialna zmiana, którą autor MUSI zrobić — np. brakujący test, missing docstring.

todo: Add a JSDoc comment for the public `parseConfig()` function explaining the expected input format.
question: Pytanie do autora

Pytanie wyjaśniające, nie krytyka. Może prowadzić do issue lub zostać samowystarczalne.

question: Why are we using Promise.all() here instead of Promise.allSettled()? If one of the requests fails, won't this cause the entire batch to abort?
thought: Myśl do dyskusji

Refleksja, niekoniecznie wymagająca akcji. Otwiera dyskusję architektoniczną.

thought: I wonder if we should think about caching here longer-term. Not blocking this PR, but worth a separate ticket if response times become an issue.

Decorators (opcjonalne)

  • (blocking) — krytyczne, MUSI być rozwiązane przed merge
  • (non-blocking) — opcjonalne, można ignorować
  • (if-minor) — opcjonalne, zrób tylko jeśli to mała zmiana
  • (or-merge-and-followup) — można merge'ować i naprawić w follow-up PR

10 fraz: asking questions

Pytania to najmniej konfrontacyjna forma feedbacku. Pokazujesz, że nie zakładasz złych intencji, dajesz autorowi szansę na wyjaśnienie. Złoty standard w konstruktywnym review.

1
"Could you help me understand why we chose [X] over [Y] here?"
Czy mógłbyś mi wyjaśnić, czemu wybraliśmy X zamiast Y?
Kiedy: autor podjął decyzję, która wydaje Ci się nieoptymalna, ale możesz nie znać kontekstu. Inkluzywne „we" zamiast „you".
2
"What would happen if [edge case] occurs here?"
Co się stanie, jeśli pojawi się [edge case]?
Kiedy: sugerujesz edge case, którego autor mógł nie rozważyć (null, empty array, race condition).
3
"Is there a reason we're not using the existing `helperFunc()` here?"
Czy jest powód, dla którego nie używamy istniejącej `helperFunc()`?
Kiedy: autor reimplementuje coś, co już istnieje w kodzie. Pytanie pozwala na przyznanie się do niewiedzy lub uzasadnienie decyzji.
4
"Have you considered [alternative approach]?"
Czy rozważałeś [alternatywne podejście]?
Kiedy: proponujesz alternatywę bez naciskania. Autor decyduje, czy jest warta dyskusji.
5
"How does this interact with [other component]?"
Jak to wpływa na [inny komponent]?
Kiedy: sprawdzasz wpływ zmiany na resztę systemu. Może odkryć missing test cases.
6
"Could you walk me through the logic here?"
Czy mógłbyś mnie przeprowadzić przez tę logikę?
Kiedy: kod jest skomplikowany i nie rozumiesz. Lepsze niż „This is too complex" — sygnalizuje potrzebę dokumentacji / refactoring.
7
"What's the expected behavior when [condition]?"
Jakie jest oczekiwane zachowanie gdy [warunek]?
Kiedy: spec jest niejasny dla konkretnego scenariusza. Ujawnia luki w requirements.
8
"Do we need to handle backwards compatibility here?"
Czy musimy zachować backwards compatibility?
Kiedy: zmiana łamie API / format danych. Wskazuje na potencjalny breaking change.
9
"Is this intentional, or should we [alternative]?"
Czy to intencjonalne, czy powinniśmy [alternatywa]?
Kiedy: coś wygląda jak literówka / nieprzemyślana decyzja, ale dajesz benefit of the doubt.
10
"What's the test coverage for this new logic?"
Jakie jest pokrycie testami dla tej nowej logiki?
Kiedy: brak widocznych testów. Łagodniejsze niż „You forgot tests".

10 fraz: making suggestions

11
"I'd suggest extracting this into a helper function for reusability."
Zasugerowałbym wydzielenie tego do funkcji pomocniczej dla reusability.
Kiedy: kod się duplikuje albo można go zreużyć w przyszłości. „I'd" miękiej niż „You should".
12
"How about using `Map` here instead of plain object? It would be more semantically appropriate."
A może użyjemy `Map` zamiast zwykłego obiektu? Byłoby semantycznie poprawniejsze.
Kiedy: proponujesz konkretną zmianę z uzasadnieniem. „How about" brzmi włączająco / zespołowo.
13
"It might be worth adding a unit test for the empty input case."
Warto by dodać test jednostkowy dla pustego inputu.
Kiedy: brakujący test edge case. „It might be worth" — soft suggestion.
14
"We could simplify this by using `array.flat()` instead of nested loops."
Moglibyśmy to uprościć używając `array.flat()` zamiast zagnieżdżonych pętli.
Kiedy: proponujesz prostszy / nowocześniejszy syntax. Inkluzywne „we".
15
"What if we cached the result of this expensive computation?"
A może zacachujemy wynik tej kosztownej operacji?
Kiedy: performance optimization. Hipotetyczne „what if" otwiera dyskusję.
16
"Consider using `Promise.allSettled()` here so one failure doesn't abort everything."
Rozważ użycie `Promise.allSettled()` tutaj — jedna porażka nie przerwie wszystkiego.
Kiedy: konkretna sugestia z uzasadnieniem. „Consider" jest neutralne.
17
"This logic might be cleaner if we used early returns instead of nested if statements."
Ta logika byłaby czystsza z early returns zamiast zagnieżdżonych if.
Kiedy: readability suggestion (guard clauses pattern).
18
"Maybe we could add a comment explaining why we're doing X here? It's not immediately obvious."
Może dodalibyśmy komentarz wyjaśniający czemu robimy X? Nie jest to oczywiste.
Kiedy: nieoczywista decyzja, która zasługuje na docstring / inline comment.
19
"I'd recommend using a constant for this magic number — it appears in 3 places."
Zarekomendowałbym stałą zamiast magic number — pojawia się w 3 miejscach.
Kiedy: magic numbers, hardcoded values powinny być wyextrahowane.
20
"Looks great! One small suggestion: we could use `Object.freeze()` to prevent accidental mutation."
Wygląda świetnie! Jedna mała sugestia: moglibyśmy użyć `Object.freeze()` zapobiegając accidental mutation.
Kiedy: dodatek po pochwale (sandwich technique). „Looks great" + „one small suggestion".

10 fraz: pointing out issues

21
"This will throw a `TypeError` when `data` is undefined — we need a guard clause."
To rzuci `TypeError` gdy `data` jest undefined — potrzebujemy guard clause.
Kiedy: konkretny bug z konkretnym scenariuszem. Faktualne, nie atakujące.
22
"There's a potential race condition here — two concurrent requests could both pass the check."
Tu jest potencjalny race condition — dwa concurrent requesty mogą oba przejść check.
Kiedy: wskazujesz konkretny technical issue z explainerem.
23
"This SQL query is vulnerable to injection — we should use parameterized queries."
To zapytanie SQL jest podatne na injection — powinniśmy użyć parametryzowanych zapytań.
Kiedy: security issue. Konkretne i mierzalne, „we should" zamiast „you should".
24
"This breaks our API contract — clients expect `id` to always be present."
To łamie nasz API contract — klienci oczekują, że `id` zawsze będzie obecne.
Kiedy: backwards compatibility violation. Wskaż konkretny contract.
25
"This function has too many responsibilities — it's handling parsing, validation, AND persisting. Could we split it?"
Ta funkcja ma zbyt wiele odpowiedzialności — robi parsing, walidację I zapisuje. Możemy ją podzielić?
Kiedy: Single Responsibility Principle violation. Konkretny analiza + sugestia.
26
"The variable `data` is reassigned 3 times here, making the flow hard to follow."
Zmienna `data` jest reasignowana 3 razy — flow jest trudny do śledzenia.
Kiedy: mutation issues, code clarity. Konkretne (3 razy), mierzalne.
27
"This will cause a memory leak — the event listener is never removed."
To spowoduje memory leak — listener nie jest nigdy usuwany.
Kiedy: resource leak. Wskaż konkretny resource (listener, connection, file handle).
28
"This breaks tests in `auth.test.ts:42` — we need to update the mock."
To łamie testy w `auth.test.ts:42` — musimy zaktualizować mock.
Kiedy: wskaż konkretny failing test. Pomaga autorowi znaleźć szybko.
29
"This implementation is O(n²) — at our scale, it'll cause issues. We should use a Set for O(1) lookup."
Ta implementacja jest O(n²) — przy naszej skali sprawi problemy. Powinniśmy użyć Set dla O(1) lookup.
Kiedy: performance issue z konkretną big-O analysis i sugestią rozwiązania.
30
"This commits PII (email, phone) to logs — that's a GDPR violation. We need to redact these fields."
Tu loguje się PII (email, telefon) — to naruszenie RODO. Musimy usunąć te pola.
Kiedy: compliance issue (GDPR, HIPAA, PCI). Wskaż konkretny regulation.

10 fraz: praise & approval

Pochwały są najczęściej pomijaną kategorią przez polskich devów — uznajemy że dobry kod to standard, więc nie chwalimy. Anglosaska kultura wymaga positive feedback jako część profesjonalnej komunikacji. Buduje atmosferę w zespole i motywację.

31
"LGTM 🚀"
Looks Good To Me — wygląda dobrze, można merge'ować.
Kiedy: standardowy approval. Emoji opcjonalne (sprawdź konwencję firmy).
32
"Approved! Nice work on the test coverage — really comprehensive."
Zaakceptowane! Świetna robota z pokryciem testami — bardzo dokładne.
Kiedy: approval z konkretną pochwałą. Wskaż KONKRETNIE co było dobre.
33
"This is much cleaner than the previous implementation — great refactor."
Dużo czystsze niż poprzednia implementacja — świetny refactor.
Kiedy: doceniasz refactor / improvement. Porównanie do poprzedniej wersji.
34
"I love how you handled the error cases here. Very robust."
Świetnie poradziłeś sobie z error cases. Bardzo solidne.
Kiedy: doceniasz konkretny aspekt (error handling, security, performance).
35
"Smart use of the Strategy pattern — it'll make adding new providers trivial."
Sprytne użycie Strategy pattern — dodawanie nowych providerów będzie trywialne.
Kiedy: doceniasz architectural decision z forward-thinking.
36
"Thanks for tackling this — I know it was a tricky one."
Dzięki za zajęcie się tym — wiem, że to było trudne.
Kiedy: trudny PR (legacy code, complex logic). Acknowledgment of effort.
37
"Approved with minor suggestions — feel free to merge after addressing or as a follow-up."
Zaakceptowane z drobnymi sugestiami — możesz merge'ować po ich rozwiązaniu albo w follow-up.
Kiedy: approval z opcjonalnymi nitami. Daje autorowi flexibility.
38
"The documentation here is excellent — this will save future devs hours."
Dokumentacja jest doskonała — zaoszczędzi przyszłym devom godziny.
Kiedy: doceniasz docs / comments. Często niedoceniane przez polskich devów.
39
"Thanks for breaking this into smaller PRs — much easier to review."
Dzięki za podzielenie tego na mniejsze PR — dużo łatwiej review'ować.
Kiedy: autor wykazał się dyscypliną (vs zrzucenie 2000-line monster PR).
40
"🎉 Ship it!"
Wysyłaj! / Merge'uj!
Kiedy: casual approval w nieformalnym zespole. Sprawdź konwencję firmy (Big Tech corpo — może nie pasować).

10 fraz: clarification & follow-up

41
"Thanks for the explanation — that makes sense now. Approved!"
Dzięki za wyjaśnienie — teraz to ma sens. Zaakceptowane!
Kiedy: autor wyjaśnił Twoje pytanie. Zamykasz wątek pozytywnie.
42
"Got it. Could you also add a comment in the code referencing this discussion?"
Rozumiem. Możesz dodać komentarz w kodzie z odnośnikiem do tej dyskusji?
Kiedy: non-obvious decision powinna być udokumentowana dla przyszłych devów.
43
"Let's discuss this offline / in our next sync — too much to cover in comments."
Omówmy to offline / na następnym sync — za dużo na komentarze.
Kiedy: dyskusja architektoniczna wykracza poza review. Eskaluj do sync.
44
"Could we tackle this in a follow-up PR? I'd like to merge this and not block on the larger refactor."
Zajmiemy się tym w follow-up PR? Chciałbym merge'ować to i nie blokować większego refactora.
Kiedy: sugerujesz zmniejszenie zakresu PR. Pragmatyczne (merge mniejsze, nie blokuj).
45
"I'm not familiar with this library — could you point me to the docs?"
Nie znam tej biblioteki — skierujesz mnie do dokumentacji?
Kiedy: przyznajesz się do niewiedzy. Ważne — nie udawaj eksperta. Native devowie to robią często.
46
"Re: your question above — yes, that's intentional because [reason]."
Co do twojego pytania powyżej — tak, to intencjonalne, bo [reason].
Kiedy: jesteś autorem PR i odpowiadasz na pytanie reviewera. „Re:" zaczyna response.
47
"Pushed the changes — let me know if anything else."
Wypchnąłem zmiany — daj znać jeśli coś jeszcze.
Kiedy: jesteś autorem, naniosłeś poprawki, prosisz o re-review.
48
"Good catch — I missed that. Fixed in the latest commit."
Dobry catch — przegapiłem. Naprawione w ostatnim commicie.
Kiedy: przyznajesz się do błędu jako autor. „Good catch" buduje team chemistry.
49
"I disagree — here's my reasoning: [explanation]. What do you think?"
Nie zgadzam się — oto moje rozumowanie: [explanation]. Co myślisz?
Kiedy: autor nie zgadza się z reviewerem. „I disagree" + uzasadnienie + zaproszenie do dialogu.
50
"After thinking about it more, I think you're right. Updated the implementation."
Po przemyśleniu, myślę że masz rację. Zaktualizowałem implementację.
Kiedy: autor zgadza się z reviewerem po dyskusji. Pokazuje nastawienie na rozwój.

Ton: assertive vs aggressive vs passive

Najtrudniejszy element code review po angielsku dla Polaków: ton. Trzy główne style — używaj ASSERTIVE, unikaj pozostałych:

Ton komentarzy code review — 3 kolumny: Passive (czerwony, słaby), Assertive (zielony, dobry), Aggressive (pomarańczowy, atakujący)
❌ PASSIVE

"Maybe... I'm not sure but... possibly there could be... a small issue?"

"Hmm, I wonder if perhaps..."

"Not sure, but..."

✅ ASSERTIVE

"I think this won't handle null — could we add a check?"

"This implementation has X edge case."

"How about we use Y here for clarity?"

❌ AGGRESSIVE

"This is wrong. Fix it."

"You wrote this badly."

"Why did you do this?"

5 zasad assertive tonu

  1. Krytykuj KOD, nie AUTORA. „This code has X issue" zamiast „You wrote bad code".
  2. Używaj słów łagodzących (softeners): could, might, perhaps, I'd suggest, we could consider.
  3. „We" zamiast „you". „How about we add error handling?" jest collaborative.
  4. Pytania zamiast stwierdzeń. „What if [edge case]?" otwiera dyskusję.
  5. Reasoning + sugestia. „This is O(n²), use Set for O(1)" lepsze niż „Use Set".

AI tools 2026 dla code review

W 2026 AI nie zastępuje human review, ale posila każdy etap procesu. Top 5 narzędzi:

  1. GitHub Copilot Review — generuje pierwszą turę review automatycznie po stworzeniu PR (Pull Requesta). Łapie typowe błędy, proponuje optymalizacje. 10 USD/mies.
  2. Cursor / Cody (Sourcegraph) — pomaga AUTOROWI przed wysłaniem PR (samoprzegląd). Wskazuje brakujące testy, niezgodności z konwencjami.
  3. ChatGPT / Claude — dopracowywanie komentarzy. Wkleisz wstępną wersję komentarza po polsku albo niezgrabnie po angielsku, AI zwróci wersję profesjonalną. Klasyczny prompt: „Translate this Polish-style direct comment into a professional, non-aggressive English code review comment using Conventional Comments format: [komentarz]".
  4. PR-Agent (Codium) — open source, podobny do Copilot Review. Działa z self-hosted GitLab.
  5. LinearB / Graphite — analityka PR (czas review, wąskie gardła, statystyki).

Praktyczny przykład dla Polaków: Voice Mode w ChatGPT do dopracowywania komentarzy w czasie rzeczywistym. Mówisz po polsku „Powiedz autorowi że to nie jest dobry pomysł, bo X i Y", AI zwraca profesjonalną wersję po angielsku. 30-sekundowy proces zamiast 5-minutowego pisania.

7 błędów polskich developerów

Błąd 1 — Zbyt bezpośredni ton

❌ „This is wrong. Fix it." / „You forgot tests."

✅ „I think this won't handle X edge case — could we add a check?" / „I noticed there are no tests for this — could you add some?"

Błąd 2 — Brak kontekstu w komentarzach

❌ „Use map instead." (bez wyjaśnienia czemu)

✅ „I'd suggest using `map` here for readability — `forEach` returns `undefined` and we discard the result, which makes the intent unclear."

Błąd 3 — Blokowanie PR dla nitów

❌ „Request changes" za nazwę zmiennej.

✅ Conventional Comments: „nitpick (non-blocking): variable name `x` could be more descriptive — perhaps `userCount`?". Approve, nie block.

Błąd 4 — Brak PR (Pull Request) description

❌ „fixes #123" (jedna linijka, brak kontekstu).

✅ 5 sekcji: What / Why / How / Testing / Screenshots. 5-15 minut na napisanie = 30-60 minut zaoszczędzone reviewerowi.

Błąd 5 — Brak pochwał

❌ Tylko issues i nity. Nigdy nie chwalisz dobrego kodu.

✅ Conventional Comments: „praise: nice use of [pattern] here". Buduje atmosferę w zespole. Anglosaska kultura tego oczekuje.

Błąd 6 — Wielkie monolityczne PR (Pull Requesty)

❌ 2000-liniowy PR z „Add feature X and refactor Y and update deps".

✅ 200-400 LoC (lines of code) per PR. 1 PR = 1 logiczna zmiana. Powyżej 1000 LoC ~50% reviewerów klika approve bez czytania.

Błąd 7 — Defensywność jako autor

❌ „No, that's the right way." / Argumentowanie każdego komentarza.

✅ „Good catch — I missed that. Fixed in the latest commit." / „After thinking about it more, you're right." Growth mindset > ego.

Linki do pogłębienia

FAQ — najczęstsze pytania

Czemu polskim developerom code review po angielsku jest trudne?

3 powody: (1) polska bezpośredniość vs anglosaskie łagodzenie wypowiedzi, (2) brak słów łagodzących (softeners: could/might/perhaps), (3) mieszanie krytyki kodu z krytyką autora.

Jak napisać dobry PR (Pull Request) description?

5 sekcji: What (1-2 zdania) · Why (motywacja biznesowa) · How (sposób implementacji) · Testing (jak testowałeś) · Screenshots/screencast.

Co to są Conventional Comments?

Format prefixów: praise / nitpick / suggestion / issue / todo / question / thought. Plus decorators: (blocking), (non-blocking), (if-minor). Standard 2026 w Big Tech.

Jaki ton używać?

ASSERTIVE (jasny, ale uprzejmy). NIE passive (niejasny). NIE aggressive (atakujący). 5 zasad: krytykuj kod nie autora, używaj słów łagodzących, „we" zamiast „you", pytania zamiast stwierdzeń, uzasadnienie + sugestia.

AI tools 2026?

Top 5: GitHub Copilot Review (auto pierwsza tura), Cursor/Cody (samoprzegląd przed wysłaniem PR), ChatGPT/Claude (dopracowywanie komentarzy), PR-Agent (open source), LinearB (analityka).

Optymalna wielkość PR (Pull Requesta)?

200-400 LoC (lines of code = linie kodu). Powyżej 400 — efektywność spada. Powyżej 1000 — 50% reviewerów klika approve bez czytania.

Czy używać LGTM, WIP, TLDR?

TAK — standard branżowy. Plus: nit, blocker, IMO/IMHO, FYI, IIRC, AFAIK. Emoji sprawdź konwencję firmy.

Największe błędy polskich devów?

(1) Zbyt bezpośredni ton. (2) Brak kontekstu. (3) Blokowanie PR za nity. (4) Brak PR description. (5) Brak pochwał. (6) Monolityczne PR. (7) Postawa defensywna jako autor.

Polski junior na pierwszym code review w Big Tech: „This is wrong. Fix it." Senior manager 2 dni później: „Możemy porozmawiać o profesjonalnej komunikacji?". Junior: „Ale przecież to było wrong!" Manager: „Tak, ale po angielsku piszemy: 'I think this approach has X edge case — could we explore alternative Y?'". Ta sama treść, dramatycznie inny ton. To jest 50% pracy nad code review po angielsku.