Як дати код перегляду зворотного зв'язку дипломатично англійською мовою
Вивчіть англійські фрази для прямого, корисного зворотнього зв’ язку щодо перегляду коду, не звучачи жорстко або занадто обережно.
Хороший зворотній зв’язок з перегляду коду прямо стосується проблеми, залишаючись уважним до людини, і в англійській мові цей баланс сильно залежить від фрази - той же технічний заперечення може бути прочитано як конструктивне або жорстке залежно від того, як воно сформуловано.
Позначити ваду або проблему з коректністю
Будь конкретним і фактичним, а не обвинувальним.
- «Я думаю, що це може не працювати в тому випадку, коли список порожній — чи можете ви подвоїти перевірку, що відбувається тоді?»
- «Це виглядає так, ніби це може викликати умову гонки, якщо два запити вдарять його в один час — варто подивитись ще раз»
- «Я не впевнений, що ця логіка є цілком правильною — проходячи через крайовий випадок з нульовим вхідним дасть інший результат, ніж я очікував»
Пропонує альтернативний підхід
Поставте це як пропозицію для обговорення, а не як мандат.
- “Ви не думали про те, щоб витягнути це в окрему функцію? Це може зробити тести легше писати.»
- “Це працює, але мені цікаво, чи використання існуючої функції утилити тут збереже її більш послідовною з іншою частиною коду.”
- «Один варіант тут був би спростити це з раннім поверненням — не блокування, просто думка.»
Відмінність блокування від неблокуючих коментарів
Пояснити, чи потрібно щось вирішити перед об’ єднанням.
- «Це блокуючий коментар — я не думаю, що ми можемо об’єднатися, поки не буде вирішено питання з обробкою помилок»
- «Неблокування: маленький ігнорування назв, не соромтеся ігнорувати, якщо ви не погоджуєтесь»
- Це не блокатор, але я б хотів, щоб ми відстежували його як продовження, щоб він не зник»
Замість цього він запитує про допомогу
Якщо ти не впевнений, то сформулюй свою занепокоєність як справжнє питання.
- “Чи є причина, чому не використовується допоміжний інструмент спільної перевірки? Просто хочу зрозуміти контекст, перш ніж запропонувати зміну»
- Чи був цей шаблон обраний навмисно, чи це просто те, як був структурований оригінальний код?
- «Чи я щось пропускаю, чи це пропускає перевірку авторизації, яку мають інші кінцеві точки?»
Визначити правильний вибір
Огляди не повинні бути лише списком проблем — також треба вказувати, що працювало добре.
- «Я не хочу, щоб хтось думав, що я хочу робити щось, що не подобається мені»
- Цей рефактор є набагато чистішим, ніж попередня версія, хороший вибір
- «Дякую за ретельне тестування, це зробило логіку набагато легшою для слідування»
Словник-довідник
| Term | Meaning |
|---|---|
| Blocking comment | A review comment that must be resolved before the code can be merged |
| Nitpick | A minor, non-critical stylistic suggestion |
| Edge case | An unusual or extreme input that a piece of code may not handle correctly |
| Follow-up | Work explicitly deferred to a later time, tracked so it isn’t forgotten |
| Nit | Short for nitpick, used informally in review comments |
Ключеві моменти
- Коректність стану стосується фактично і конкретно, описуючи сценарій, а не звинувачуючи автора.
- Альтернативні підходи слід розглядати як пропозиції чи питання, а не як накази, якщо вони не блокують.
- Явно позначати коментарі як блокуючі або не блокуючі, щоб автор знав, що потрібно для об’ єднання.
- Задавайте справжні питання, коли ви не впевнені в його намірах, а не стверджуйте, що щось не так.
- Збалансувати критичний відгук з явною похвалою за хороші рішення в одному і тому ж огляді.
Наприклад, англійська мова має особливий лексичний склад для не-індіанців
Надання ефективного зворотнього зв’язку з перегляду коду є основою спільної розробки програмного забезпечення. Це не просто вказування на помилки; це допомога вашим колегам вдосконалити їх код і, в кінцевому підсумку, разом створювати краще програмне забезпечення. Для розробників, чия перша мова не є англійською, тонкощі професійного спілкування можуть бути особливо викликом. Метою тут є не просто переклад технічних термінів, а прийняття фраз, які передають повагу, конструктивну критику і справжнє бажання поліпшити - все це при використанні точного словника. Поширеною пасткою є покладання на надто нечіткі висловлювання на зразок « Це могло б бути краще ». Це не дає жодних вказівок; це залишає одержувача у невідомості щодо того, що змінити. Замість цього зосередьтеся на описі * того, що * ви спостерігали і * чому * це має значення з більшої перспективи.
Розглянемо сценарій: Сара отримує запит на витягнення нової можливості в їхньому проекті. Код функціональний, але використовує менш поширений алгоритм, який може призвести до проблем з швидкодією. Замість того, щоб сказати «Цей алгоритм здається неефективним», що може звучати обвинувачуючим, Сара могла б сказати: «Я помітила, що ви реалізували алгоритм сортування за допомогою [конкретна назва алгоритму]. Хоча він працює для менших наборів даних, його продуктивність значно знижується з більшими обсягами даних - що потенційно впливає на швидкість реагування нашого застосування. Можливо, дослідження альтернативи, як [запропонована альтернатива], забезпечить кращу масштабованість. ” Цей підхід негайно визначає конкретну проблему і пояснює потенційні наслідки без судження. Аналогічно, в розмові Slack, обговорюючи зворотній зв’язок про повідомлення про затвердження, замість того, щоб просто сказати «Повідомлення про затвердження заплутано», можна сказати: «Я намагаюся зрозуміти мету цієї зміни, заснованої виключно на повідомленні про затвердження. Чи можете ви додати коротке пояснення, в якому описується, яку проблему вона вирішує або як вона пов’язана з більшою функцією?»
Іншим ключовим елементом є ретельне використання умовної мови. Фрази на кшталт « Це * може * бути краще » можуть звучати непевно і підривати вашу оцінку. Заміна їх більш вирішальними висловлюваннями – «Це покращить…» або «Перехід на… покращить…» – демонструє впевненість у вашій оцінці, при цьому все ще визнаючи, що можуть існувати інші рішення. Крім того, коли ви пропонуєте альтернативи, формулюйте їх у вигляді питання: « Чи ви розглядали можливість використання [альтернативного підходу]? » Це запрошує до обговорення і співпраці, а не до презентації директиви. Пам’ятай, моя мета - керувати, а не диктувати. Нарешті, завжди прагніть до ясності — уникайте жаргону, незнайомого вашій команді, і поясніть будь-які технічні терміни коротко, якщо це необхідно. Не припускайте, що всі розуміють «велику O-нотацію» відразу; замість цього, скажіть щось на зразок «Цей алгоритм має складність часу O(n^2), що може стати повільним з великими наборами даних»