Code review — the ProfessNet standard#

Review is not policing — it is collaboration#

Code review at ProfessNet has two goals: catch bugs before production and share knowledge about the code. It is a conversation about the code, not a judgment of the person. A good review raises the quality and skill level of the whole team.

What the reviewer looks at#

Order matters — from most important:

1. Correctness — does the code do what the PR promises? Edge cases?
2. Security — no secrets in the code, input validation, authorization.
3. Readability — will I understand this in six months?
4. Tests — is the change covered? Do the tests actually check the logic?
5. Consistency — alignment with the repo's conventions and patterns.
6. Performance — only when it truly matters; no premature optimization.

Tip: Do not review formatting by hand. That is what Prettier/ESLint and CI are for. Your time as a reviewer is valuable — focus it on logic and security, not on spaces.

How to write comments#

A comment should be specific, kind, and point to a direction, not just the problem.

Instead of	Write
"This is bad"	"This will throw on null here — add a guard?"
"Why this?"	"Can you explain why we compute this twice?"
"Ugly"	"Let's extract this into a formatTotal function for readability"

Mark the severity of a note so the author knows what is blocking:

• blocker — must be fixed before merge.
• nit — a minor detail, optional ("nit: typo in the comment").
• question — I want to understand, not necessarily a change.

The PR author's responsibilities#

• PR description: what and why, how to test, link to the Vercel preview.
• Small scope: one goal per PR.
• Self-review: go through your own diff before asking for review.
• React to comments: reply, don't ignore; mark "resolved" after a fix.

# Assign reviewers and a label via gh CLI
gh pr create --base main --title "fix: poprawny redirect po logowaniu" \
  --reviewer jan-kowalski --label fix

When to approve, when to request changes#

Situation	Decision
Code correct, tests green, possible nits	Approve
Minor notes, I trust the author	Approve with a comment
Logic error / security gap	Request changes
I don't understand the change	Comment + questions

The ProfessNet standard in brief#

1. Every PR requires at least one approve.
2. CI (GitHub Actions) must be green.
3. The Vercel preview is reviewed for UI changes.
4. The reviewer responds in a reasonable time — review must not block the team for days.
5. After merge, the branch is deleted.

Summary#

Review is shared responsibility for quality. The reviewer looks first at correctness and security, comments kindly and concretely, and marks the severity of notes. The author delivers a small, well-described PR and reacts to feedback. Formatting we leave to the machines.