Code review není soutěž v tom, kdo najde víc chyb. Je to místo, kde se má ověřit, že kód dělá to, co má, a že mu bude rozumět i někdo jiný za půl roku. Pokud chcete, aby vaše změny prošly napoprvé, musíte reviewerovi ušetřit práci. Nejde o to psát kód pro sebe, ale pro toho, kdo ho bude číst.

Základem je malý a srozumitelný pull request. Jeden PR by měl řešit jednu věc. Pokud do něj přidáte refaktoring, opravu chyby a novou featuru najednou, reviewer ztratí přehled a bude se ptát na věci, které spolu nesouvisí. Rozdělte práci na menší celky, i když to znamená více PR. Menší diff se čte rychleji a snadněji se v něm hledají chyby. Zároveň platí, že pokud se inspirujete zásadami pro psaní čistého kódu v JavaScriptu, ušetříte reviewerovi polovinu otázek ještě předtím, než je položí.

Před odesláním si projděte vlastní diff. Často najdete zapomenutý console.log, nepotřebný import nebo komentář, který už nedává smysl. Spusťte lint a testy lokálně. Pokud váš projekt používá Prettier nebo ESLint, nechte je, ať udělají svou práci. Reviewer nemá řešit styl odsazení, ten má být vyřešený automaticky. Popis PR napište tak, aby vysvětlil proč, ne co. Co je vidět z kódu, proč často ne.

Reagujte na komentáře věcně a bez emocí. Pokud s něčím nesouhlasíte, vysvětlete proč, ale neberte to jako útok. Když reviewer navrhne změnu, která nedává smysl, řekněte to. Code review je diskuze, ne hlasování. A pokud máte pochybnosti, zeptejte se předem. Lepší je strávit deset minut diskuzí nad návrhem než hodinu přepisováním hotového kódu.