Як обговорювати парне програмування англійською
Практичний посібник англійською мовою для розробників, які парують програми — дізнайтеся лексику навігатора/ драйвера, як граціозно змінювати ролі, і що сказати, коли щось стає незграбним.
Парне програмування є співпрацею, де два розробники діляться однією робочою станцією — один пише код, а інший переглядає і керує. Це поширене в Agile командах, bootcamps і компаніях, які цінують обмін знаннями. Але для людей, для яких англійська не є рідною мовою, соціальна сторона парування може бути більш складною, ніж технічна сторона. Знаючи, що сказати і коли сказати, роблять сеанси більш гладкими, продуктивнішими і менш стресовими.
Ключовий словник
** Водій ** — людина за клавіатурою, яка активно пише код. « Я зараз за кермом, тому дайте мені знати, якщо ви щось не так побачите. »
** Навігатор ** — людина, яка спостерігає, передбачує і надає вказівки без введення тексту. « Поки ви керуєте, я буду керувати — я буду стежити за загальною структурою »
** Сеанс парування ** — запланований проміжок часу для спільної роботи двох розробників. « Чи є у вас час на сеанс парування сьогодні післяобідньо? » Я застряг на логіці автентифікації»
** Моб- програмування ** — це те саме, що і парне програмування, але з всією командою (трьома або більше людьми) на одній машині. « Ми працювали над цією можливістю цілий ранок — це було хаотично, але ми виявили багато випадків, коли використовувалися краї »
** Парування за правилами пінг- понга ** — це метод TDD, за якого одна людина пише тест, який не пройшов, а інша людина робить так, щоб він пройшов, потім вони змінюють один одного. « Хочете спробувати парування за правилами пінг- понга у цьому модулі? » Це може допомогти нам думати через інтерфейс»
** Перемикання / поворот** — зміна керування і навігації. « Ми повинні повертатися кожні 25 хвилин — це збереже нас обох зайнятими »
** Асинхронне продовження ** — нотатки або завдання, які залишилися після сеансу парування для роботи, яку слід виконати самостійно. « Залиште асинхронне продовження для випадків, коли ми не мали часу обробляти периферійні пристрої. »
Поширені фрази під час початку сеансу
Перед тим, як почати, це допомагає зрівняти очікування. Ці фрази є природні і прямі:
- «Ти хочеш керувати першим, чи мені?»
- «Let’s timebox this — how does 90 minutes sound?» (англійською)
- «Я вже маю певний контекст на цій кодовій базі, тому я буду переходити, щоб почати»
- Чи можемо ми поділитись нашим екраном, чи краще використовувати спільне середовище розробників?»
- «Давайте поставимо швидку мету — що ми хочемо, щоб працювало до кінця цієї сесії?»
Фрази для зміни ролей
Перемикання ролей в середині сеансу є нормальним і здоровим, але багато носіїв, які не є рідними носіїв, вагаються, тому що вони не знають, як запитати. Ці фрази ввічливі і поширені:
- «Чи не заважаєте ви, якщо я трохи займуся керуванням?»
- «Дай мені трохи поїхати — я хочу спробувати щось»
- “Власне, ти можеш керувати? Я хочу думати через логіку вголос.»
- «Ми були в цьому на деякий час — хочемо обмінятися?»
- «Мої зап’ястя потребують перерви — чи хочете ви взяти на себе?»
Фраза “взяти кермо” є неформальною ідіомою, що означає взяти контроль. Він широко використовується в технічних розмовах і відчувається природно в контекстах парного програмування.
Фрази для ролі Навігатора
Добре керувати означає давати вказівки без мікроуправління. Тон повинен бути співпрацелюбним, а не контролюючим:
- «Тільки думка — чи можемо ми витягнути це в свою власну функцію?»
- «Я бачу, що ви робите, але мені цікаво, чи нам потрібно обробляти нульовий випадок там»
- “Можеш трохи підняти? Я хочу перевірити, як ми визначили цей інтерфейс»
- «Відчуваю себе добре, я хочу далі жити»
- “Зачекайте — я думаю, що назва змінної може викликати плутанину пізніше. Що ви думаєте про переназвання його?»
Зауважте використання хеджування мови: * “просто думка” *, * “Я запитав, чи” *, * “може ми хочемо” *. Ці параметри пом’якшують пропозиції і роблять навігатор більш співпрацюючим, ніж критичним.
Фрази, яких слід уникати
Деякі фрази можуть сприйматися як відверто неприязні або контролюючі, навіть якщо ви маєте на увазі щось доброе:
| Avoid | Try instead |
|---|---|
| ”No, that’s wrong." | "Hmm, I’m not sure that handles the edge case — let’s talk it through." |
| "Let me just do it." | "Mind if I take the keyboard for a second?" |
| "You’re not listening to me." | "I want to make sure I explained that clearly — let me try again." |
| "That’s obvious." | "Right — and just to build on that…" |
| "Why did you do it that way?" | "Interesting approach — what was the thinking behind that?” |
Обробка розбіжностей під час парування
Недовіра до підходу - це нормально. Ключовим є відокремлення технічної дискусії від особистої динаміки:
- «Я розумію твою думку, але я хочу відштовхнути одну річ — чи можемо ми спочатку перевірити це припущення?»
- «Я не повністю впевнений — а що, якщо ми спробуємо це по-моєму і побачимо, що скажуть тести?»
- “Ми можемо йти в кругу. Чи можемо ми витратити п’ять хвилин, щоб вирішити і рухатися далі?»
- «Давайте позначимо це як розбіжність і приведемо це до командного стоячого — ми не повинні вирішувати це зараз»
Краткий справочник
| Situation | Phrase |
|---|---|
| Starting the session | ”Do you want to drive first?” |
| Taking over the keyboard | ”Let me drive for a bit.” |
| Giving gentle feedback as navigator | ”Just a thought — might we extract that?” |
| Suggesting a role switch | ”Want to swap?” |
| Ending the session | ”Let’s leave an async follow-up for the rest.” |
| Handling disagreement | ”Let’s flag this and bring it to standup.” |
Парне програмування - це так само комунікаційний навички, як і технічний. З правильним словником і фразами ви можете зробити кожен сеанс більш ефективним — і більш приємним для вашого партнера.
Розширення вашого словника: Навігація нюансів в дискусіях з парного програмування
Парне програмування є фантастичною технікою - сприяє співпраці, покращує якість коду і обміну знаннями. Однак, ефективне спілкування не тільки про технічні аспекти; це сильно залежить від точного англійського словника і розуміння тонкої фразування. Для розробників, чия перша мова не є англійською, це може бути особливо складним. Це не просто перекладання ваших ідей буквально; вам потрібно зрозуміти * контекстне * значення таких слів, як « рефакторизація », « крайовий випадок » або « міцний ». Погляньмо, як удосконалювати ваше спілкування навколо звичайних сценаріїв парного програмування.
Однією з найчастіших перешкод є надання конструктивного зворотнього зв’язку під час перегляду коду. Замість того, щоб сказати щось нечітке, наприклад, “Це не добре”, що може відчуватися відверто і нецікаво, вам потрібно бути конкретним. Кращий підхід буде: «Я помітив, що цей розділ може отримати користь від деяких переробок. Зараз логіка обробки введення користувача досить складна; можливо, ми могли б розбити її на менші, більш керовані функції, щоб поліпшити читабельність і підтримку — особливо, якщо розглядати потенційні крайні випадки. ” Ця фраза чітко визначає проблему (складність), пропонує рішення (розбиття логіки) і надає обґрунтування (читабельність, підтримка, * крайні випадки * обробки). Аналогічно, не слід просто говорити « Виправте цю помилку ». Замість цього спробуйте: « Я бачу проблему, коли обчислення не дають правильного результату для від’ ємних чисел. Чи можете ви розслідувати, чи є певна ситуація, яка потребує уваги?” Ключовим є використання точної мови і пояснення * чому * щось потрібно змінити.
Слабкі розмови часто вимагають швидкого, чіткого спілкування під час парних сеансів. Уявіть такий сценарій: «Драйвер: Я застряг у тому, як реалізувати поток автентифікації. Навігатор: Чи можете ви описати, що ви намагалися до цього часу? Можливо, ми можемо почати з опису кроків, які потрібно виконати — реєстрація користувача, входження, керування сеансами?» Це демонструє спільний підхід і зосередженість на розв’ язанні проблеми, а не на звинуваченні або просто на запиті рішення. Використання фраз на кшталт «Давайте пройдемося через…» або «Які ключові роздуми тут?» заохочує активну участь і пояснює очікування.
Нарешті, при описі вашої роботи в описі Pull Request (PR), докладно описуйте що ви робите і чому. Не просто скажіть «Реалізована функція X». Замість цього: «Ця PR вводить функціональність «Профіль користувача», що дозволяє користувачам оновлювати свою контактну інформацію. Я реалізував логіку перевірки даних за допомогою JavaScript, щоб забезпечити цілісність даних і додав тести модулів, щоб охопити ключові сценарії. Цей проект відповідає стандартам нашої команди щодо модульності і дотримується найкращих практик щодо обробки помилок. Чим більше контексту ви надасте, тим краще рецензенти зможуть зрозуміти вашу роботу і надати вам цінний зворотній зв’ язок.
# Example: Running a linter with ESLint (Node.js) – demonstrating a common code review comment
eslint . --ext .js,.jsxЦя команда запустить ESLint на всіх файлах .js і .jsx у поточній теці, підкреслюючи потенційні проблеми і надаючи пропозиції щодо поліпшення. Це реальний приклад того, як можна обговорювати якість коду під час сеансу парного обговорення — вказуючи на конкретні проблеми і пропонуючи рішення, засновані на встановлених інструментах і практиках.