Англійські фрази для незгодні ввічливо в кодових рецензіях
Disagree without friction in code reviews: softening language, questions over commands, the suggestion phrasing, and how to push back firmly when it really matters.
Перегляд коду є місцем, де починаються багато міжкомандних тренувань — не через код, а через слова. Коментар, який для вас нейтральний, може бути прочитаний як напад на колегу, який не є рідною мовою, і навпаки. У цьому підручнику ви знайдете англійські вирази, які дадуть вам змогу чітко висловити свою позицію, не змінюючи при цьому зв’ язку і запиту на прив’ язку.
У цій книзі більше уваги приділено тексту
Розмова з небажанням погоджуватися зменшується твоєю обличчям і голосом. У письмовому коментарі читач має тільки слова. Недбале “Це неправильно” набагато важче вимовити на екрані, ніж у розмові. Метою не є бути неясним — це бути ясним про код, залишаючись теплим про людину.
Використовувати питання замість команд
Питання закликають до відповіді, команди закликають до оборони.
| Command (harsh) | Question (collaborative) |
|---|---|
| “Move this to a service." | "What do you think about moving this into a service?" |
| "This will leak memory." | "Could this hold the connection open if the loop throws?" |
| "Don’t use a global here." | "Is there a reason this needs to be global?” |
- “Можливо, я не розумію контексту — що стало причиною кешування цього на клієнті, а не на сервері?” *
Фраза “Я можу не розуміти контексту” сигналізує про смирення і часто виявляє хорошу причину, яку ви не розглядали.
Патерн «Підказка»
Багато команд відрізняють блокування коментарів від необмежених. Зробити різницю явною англійською:
- Nit: “Nit: Я б перейменував
dataнаuserRecordsдля ясності — не блокуючи.” - ** Пропозиція: ** * « Пропозиція: ми могли б витягнути це до допоміжного, але з радістю залишимо це. » *
- ** Питання: ** *“Питання: чи обробляє цей параметр порожній масив?” *
- ** Блокування: ** * « Блокування: цей запит не параметризований, що створює ризик втручання SQL ». *
Мітки ваших коментарів повідомляють автору, що слід вказати у коментарі, а що можна ігнорувати.
Складні слова, що складаються з простих слів
“Все виглядає добре — лише одну річ я хотів відзначити.” “В основном это предпочтение стиля, так что не стесняйтесь отступать.”
- “Я можу помилятися, але…” * “Ти не думав про…?”
- “Що б ти подумав про…?” *
Невелика доза розм’якшення йде далеко. Однак, якщо ви надмірно використовуватимете його, ви почуєтесь непевно — зарезервуйте найменш різкі фрази для справді необмежених питань.
Якщо потрібно, то слід відштовхуватись від землі
Іноді ввічливості недостатньо — помилку безпеки або помилку коректності не слід об’ єднувати. Ты можешь быть твердой и все еще уважающей.
- “Я не думаю, що нам слід об’єднувати це так, як є. Цей шлях надає змогу неавтентифікованим користувачам читати дані інших облікових записів, що є проблемою безпеки, яку нам слід вирішити перед випуском. Я щасливий, що зможу поєднати їх, якщо це буде корисно»
Зверніть увагу на структуру: чітка відмова, конкретна причина і пропозиція допомоги. Твердість без пояснення відчувається як гра в сили; твердість з причиною відчувається як турбота про якість.
Не погоджується з висновками старшого оглядача
Якщо ви є автором і не погоджуєтесь з відгуком, захищайте своє рішення доказами, а не его.
“Дякую за огляд. Я вибрав цей підхід, тому що альтернатива додавала поїздку в обидві сторони на кожен запит — ось еталон. Відкритий до зміни, якщо я неправильно оцінив компроміс.»
“Це справедлива точка зору. Можеш розповісти більше про те, що ти очікуєш розбити? Я хочу переконатися, що я розумію занепокоєння, перш ніж я зміню його.»
Попросити рецензента * “сказати більше” * перетворює протистояння в дискусію.
Фрази, яких слід уникати
| Avoid | Why |
|---|---|
| ”Obviously this is wrong." | "Obviously” implies the author is foolish. |
| ”Why would you do this?” | Reads as an accusation, not curiosity. |
| ”Just do X." | "Just” minimises real complexity. |
| ”Everyone knows…” | Alienates and shames. |
Просте виправлення: замініть * « ви » * на * « цей код » * або * « ми » *. * « Ви забуваєте про нульову перевірку » * стає * « Тут відсутня нульова перевірка » * — та ж інформація, без звинувачення.
Завершується огляд хорошим відгуком
- “Хороша робота — тестове покриття чудове. Тільки один блокуючий коментар на аутентифікаційній перевірці, тоді я з радістю схвалю.»*
Завершення з вдячністю і чітким шляхом до схвалення залишає автора мотивованим, а не розчарованим.
Не сходитися в оглядах коду - це майстерність. Поставляй вопросы, указывай, что блокирует, смягчай мелкие вещи и будь твердой с причиной, когда это важно. Робіть це постійно, і ваші огляди стануть тим, що колеги з нетерпінням чекають, а не бояться — що, в кінцевому підсумку, є показником того, наскільки хороший код насправді надходить.
Назва походить від імені Нестора — невідомого літописця
Незгода є неминучою частиною спільної розробки програмного забезпечення. Однак, ефективне висловлення незгодні, особливо коли ваша перша мова не є англійською, може відчувати себе наповненим потенціалом для нерозуміння і тертя. Це не про вигравання дебатів; це про те, щоб забезпечити поліпшення коду і плавний рух команди вперед. Цей розділ присвячено додаванню шарів нюансів до вашого спілкування, що особливо важливо, коли ви свідомо розвиваєте свій професійний словник англійської мови.
Однією з поширених пасток є оформлення незгодні як звинувачення - такі фрази як “Це неправильно” або “Вам потрібно це виправити” негайно ставлять іншу людину в оборону. Замість цього, розгляньте можливість пом’якшення вашої презентації фразами, які зосереджені на спостереженні і потенційних рішеннях. Наприклад, замість того, щоб сказати « Назва цієї змінної неясна », ви можете сказати: « Я помітив, що змінна x не є особливо описовою; можливо, перейменування її на щось, що більше відповідає її призначення, поліпшить читабельність ». Аналогічно, коли відповідаєте на каналі Slack, обговорюючи запит на витяг, уникайте прямої критики. Замість того, щоб вводити «Цей код жахливий!», спробуйте «Мені цікаво, чи не могли б ми дослідити деякі альтернативні підходи тут — можливо, додавання коментарів, щоб прояснити логіку?» Це змінює фокус з особистого судження на спільне вирішення проблеми.
Ключовим елементом є перехід від надання команд до запитання питань, які заохочують роздуми. Замість того, щоб сказати: « Вам слід реалізувати тайм- аут », запитайте: « Чи розглядали ви можливість включення тайм- аута для вирішення потенційних проблем з підключенням? Які є компроміси у цьому?» Це запрошує розробника подумати про наслідки самому, сприяючи власності і розумінню, а не просто нав’ язуючи свою думку. При відкиданні рішення в описі PR, використовуйте такі фрази, як «Я переживаю, що…» або «Може бути корисно розглянути…» Ці м’якіші підходи демонструють повагу до роботи іншої людини, все ще закликаючи до якості. Пам’ятайте, що мета полягає в тому, щоб вести їх до кращого рішення, а не диктувати його.
І нарешті, не недооцінюйте силу підтвердження значення в існуючому коді перед тим, як пропонувати пропозиції. Фрази на кшталт «Ця частина виглядає добре структурованою» і «Я запитав себе, чи можемо ми, можливо,…» можуть допомогти в побудові відносин і продемонструвати, що ви цінуєте їхні зусилля, поки ви все ще шукаєте поліпшення. Практикування цих тонких змін у мові значно зменшить ймовірність неправильного тлумачення і побудує міцніші відносини у вашій команді розробників — важливо для продуктивного і позитивного робочого середовища, незалежно від рідної мови.