Англійська мова для віддаленого парного програмування: розповідь коду і спільне використання контексту

Віддалене парне програмування — два інженери, що співпрацюють над кодом в реальному часі через відеоконференцію — вимагає певного регістру розмовної англійської мови. Вам потрібно розповісти про свої думки, поставити точні питання і підтримувати спільний контекст, все це під час написання коду і керування викликом.

---

Ролі водіїв і навігаторів

Парне програмування використовує дві ролі:

• ** Драйвер ** — людина, яка вводить код
• ** Навігатор ** — людина, яка переглядає, думає наперед і керує

Знання цих ролей англійською мовою допоможе вам плавніше перемикатися між ними.

Предлагаю переключиться

• «Чи хочеш ти перейняти клавіатуру на деякий час?»
• «Я хочу жити на деякий час» (фр
• «Чому б тобі не навігаційна система і я наберу — ти маєш ясніше уявлення про дизайн.»
• «Let’s swap — Я їздив 20 хвилин.»

Передаю

• «Я збираюся розділити свій екран зараз — ви повинні побачити редактора.»
• “Ви бачите мій термінал? Я пройдусь через те, що я збираюся ввести»
• “Я передам контроль. Використовуйте посилання Live Share.”

---

Розповідь про твою думку

Найважливіша вміння у парному програмуванні це ** думати вголос ** — розповідати, що ви робите і чому, щоб ваша пара могла слідкувати і робити свій внесок.

Дикторський супровід вашого введення

• “Я ** створюю ** нову функцію тут для обробки логіки повторних спроб бази даних.”
• «Я збираюся витягнути це в окремий метод — це стає занадто довгим»
• «Ось я вводжу залежність, а не створюю її безпосередньо»
• “Я додаду клаузулу охорони на верхній частині, щоб повернутися раніше, якщо вхідний сигнал буде нульовим.”

Розповідаєш, про що думаєш

• «Я розглядаю два підходи тут — дайте мені подумати на секунду.»
• «Мій інстинкт — використовувати карту, але я не впевнений, що це перебільшення для цього випадку використання»
• «Я підозрюю це значення тайм-аута — воно здається занадто низьким для мережевого виклику»
• «Дай мені просто перевірити чи ця бібліотека обробляє Unicode правильно, перш ніж ми покладемося на неї»

Розповідь про невизначеність

• «Я не на 100% впевнений щодо контракту API тут — дозвольте мені підняти документи»
• «Це трохи припущення — я думаю, що це працює, але давайте додамо тест, щоб підтвердити це.»
• «Я нечітко пам’ятаю, що була помилка в цій області — варто перевірити git log.»

---

Запитання про пояснення

Віддалене програмування пар вимагає більш чіткого спілкування, ніж у реальному часі — ви не зможете так просто вказувати на екран.

Питання про намір

• Що ми ** намагаємося досягти ** з цією функцією?
• «Чи є метою ** перевірити ** вхід або ** перетворити ** його?»
• Чи ми робимо це наразі або це кінцевий дизайн? “

Питання про кодову базу

• «Звідки це зветься?»
• «Чи є тест на існуючу поведінку ** перед ** ми змінимо її?»
• Що містить UserContext — чи задокументовано це де-небудь?

Перевіряю розуміння

• «Тільки щоб підтвердити — ми хочемо, щоб помилка вибухла, а не була поглинута тут?»
• Таким чином, очікувана поведінка є: якщо термін дії токена закінчився, перенаправте на вході?
• «Чи правильно я розумію, що це працює синхронно?»

---

Розділення контексту і фону

Якщо ви знаєте щось, чого ваші друзі не знають, то діліться цим з ними.

Надання фону

• «Тут трохи історії: цей модуль був написаний до того, як ми прийняли новий шаблон обробки помилок.»
• «Відповідно до відомостей: тут є відома помилка — я посилаю квиток»
• «Context: ця функція викликається 10 000 разів на секунду в виробництві — продуктивність має значення»

Повідомити про проблему

• “Я збираюся флаг що цей підхід може викликати проблеми, якщо мережа повільна.”
• «Одна проблема: це не безпечне для потоків, як написано.»
• «Тільки ** голова-вгору ** — ми будемо оновити скрипт міграції, якщо ми змінимо цю схему.»

---

Давати і отримувати пропозиції

Предлагать, не принимая

• «Один варіант був би використовувати декоратора тут — що ви думаєте?»
• «Я запитав себе, чи фабрика функцій буде чистішою, ніж підхід конструктора.»
• “Ви думали про те, щоб зробити це асинхронно? Це може спростити виклик»

Отримання пропозиції

• «Це **хороша точка ** — дайте мені спробувати це.»
• “Я розумію, що ти маєш на увазі. Дозвольте мені рефакторувати, щоб побачити, як це виглядає»
• «Я б хотів зрозуміти, чому це було б краще — чи можете ви провести мене через це?»

Ввічливо не погоджуюся

• «Я бачу привабливість, але я ** хвилююся **, що це ускладнить тестування»
• “Це правильний підхід. Моє занепокоєння читливості — чи є середня дорога?»
• «Я б натиснув назад трохи — я думаю, що додаткова абстракція додає більше складності, ніж вона усуває»

---

Керування сеансом

Сфокусировался

• «Давайте триматися на трасі — ми можемо перефрактурувати це пізніше»
• “Це хороша ідея для наступного квитка. Давайте паркуємо його наразі»
• «Ми працювали над цим 30 хвилин — чи варто нам зробити перерву або продовжувати?»

Перевіряю

• «Як ти? ** Чи темп OK ** для тебе?»
• “Чи чисте звучання? Я хочу, щоб ти міг мене почути»
• “Ви бачите, що я редактую? Це лінія 87.”

Завершую

• «Давайте приймемо те, що у нас є, і запишемо невирішені питання»
• «Я відкрию квиток для рефакторингу, який ми обговорювали.»
• “Хороша сесія — ми зробили значний прогрес на [X]. Наступного разу давайте почнемо з тестів»

---

Ключеві моменти

• ** Постійно розповідайте **: скажіть вашій парі, що ви вводите * і * чому.
• Подумайте вголос: “Я думаю… мой инстинкт… Я не впевнений…»
• Використовуйте точні запитання: запитайте про намір, контекст, і очікувану поведінку — не просто «що це робить?»
• ** Спільно використовувати фон активним чином **: не приймайте, що ваша пара має такий самий контекст, як і ви.
• ** Запропонуйте без командування **: « одним з варіантів було б,» « чи ви розглядали,» а не « просто зробіть X. »
• Для віддалених сеансів, over-communicate: описати, що відбувається на вашому екрані, підтвердити звук, перевірити розуміння.

Розширення вашого словника: точність у віддаленому спілкуванні

… [останнє з оригінального вмісту блогу тут — це опущено для скорочення, але припускається, що воно охоплює основні поняття розповіді коду під час парного програмування, обговорення ролей, таких як драйвер/ навігатор, запитання для пояснення і ефективного поділу контекстом] …

Тепер, давайте будемо чесними - навіть досвідчені розробники можуть спіткати, коли вони чітко сформулюють свої процеси мислення англійською, особливо в віддаленому середовищі. Це не просто про те, щоб знати * що * ви робите; це про передачу цих знань з точністю, використовуючи правильний словник, щоб сприяти співпраці і уникнути непорозумінь. Для не-рідних носіїв, це часто ускладнюється тиском швидко розвиваються технічних дискусій. Сфокусування уваги на певних фразах, пов’ язаних з коментарями перегляду коду, каналами Slack і описами запитів на завантаження, може значно поліпшити вашу здатність ефективно робити внесок.

Одна з ключових областей для поліпшення полягає в описі * чому * ви робите зміну, а не тільки * що * ви робите це. Замість того, щоб просто сказати “Видалити: NullPointerException,” розгляньте “Я звертаюся до потенційного NullPointerException додаванням нульової перевірки перед доступом до поля user_id. Це запобігає помилці, якщо запис користувача не знайдено. ” Остання позиція надає негайний контекст і обґрунтування зміни, зменшуючи кількість питань. Аналогічно, коли ви просите про пояснення - “Чи можете ви розробити очікувану поведінку в цьому сценарії?” є набагато більш продуктивним, ніж нечітке “Що мені потрібно виправити?”. Вивчення фраз, таких як «Давайте розглянемо…» або «Я думаю, що…» демонструє залученість і запрошує до спільного вирішення проблем. Іншим важливим елементом є використання точної термінології; наприклад, замість того, щоб сказати «цей код не працює», спробуйте «логічний потік тут не збігається зі специфікацією»

Крім того, освоєння словникового запасу, пов’язаного з процесами перегляду коду - такі терміни, як “краєвий випадок”, “регресійний тест”, “рефакторинг” і “технічний борг” - значно підвищить вашу впевненість. Не бійтеся запитати про визначення, якщо ви не впевнені щодо терміну; більшість досвідчених розробників радо їх пояснить. Пам’ ятайте, що чітке спілкування є найважливішим під час віддаленої співпраці, і вкладання грошей у правильний словник — це вкладання грошей у ваш успіх як розробника.

# Example using `git diff` to highlight changes with descriptive commit message
git diff --color-words HEAD~1 HEAD | less -R

За допомогою цієї команди можна продемонструвати, як використовувати певні фрази під час опису змін під час перегляду коду, підсвічування змінених слів і надання безпосереднього контексту для переглядача. Використання інструментів, таких як git diff, у поєднанні з добре розробленими повідомленнями про затвердження дозволяє більш цілеспрямоване і ефективне обговорення про зміни, які робляться.