Текстовий коментар не передає інтонації: те, що рецензент вважав дрібною порадою, автор може прочитати як різку вимогу. Тому важливо явно позначати вагу коментаря і писати про код, а не про людину.
Conventional Comments - домовленість про формат коментарів: мітка на початку показує, чого саме чекає рецензент.
issue: тут N+1 - для кожної вакансії окремий запит до company.
Додай ->with('company') у запит вище.
suggestion (non-blocking): можна винести умову в scope `published()`,
вона повторюється в трьох місцях.
nitpick: `$data` -> `$vacancyAttributes`, так зрозуміліше.
question: чи може тут прийти порожній масив? Якщо так - впаде на array_key_first.
praise: дуже зручно, що експорт іде потоково, - пам'ять не росте.
Мітки й значення:
| Мітка | Що означає |
|---|---|
issue |
проблема, яку треба виправити |
suggestion |
пропозиція покращення |
question |
рецензент не впевнений, хоче зрозуміти |
nitpick |
дрібниця на смак, не блокує |
praise |
щось зроблено добре |
(blocking) / (non-blocking) |
чи блокує злиття |
Принципи доброго коментаря:
- пояснювати чому: не «зроби інакше», а «так буде N+1, бо...»;
- питати, а не стверджувати, коли не впевнені: можливо, автор знає те, чого не знаєте ви;
- «ми» і «код», а не «ти»: «тут можна спростити», а не «ти ускладнив»;
- пропонувати рішення чи напрямок, а не лише вказувати на проблему;
- хвалити вдалі рішення - це теж інформація: що варто повторювати;
- не дублювати: однакова проблема в десяти місцях - один коментар «і так само нижче».
Автору: відповідати на кожен коментар (виправлено, не згоден - ось чому, винесу в окрему задачу) і не сприймати рев'ю особисто - рецензують код, а не людину.
