English for Pair Programming: Vocabulary for Driver, Navigator, and Mob Sessions (англійською)
Освоєння англійського словника, який використовується у сеансах парного програмування і групового програмування — передачі драйвера/ навігатора, роздуми у коді, фрази, що викликають розбіжності, і мова зневаджування « гумова качка ».
Парне програмування - це не просто практика кодування - це розмова. Двоє інженерів, які сидять на одній машині, або спільно використовують екран у віддаленому сеансі, повинні постійно спілкуватися: хто пише, що повинен робити код, і чому поточний підхід може або не може працювати. Для носіїв мови, для яких англійська не є рідною, цей вид технічного діалогу в реальному часі з високими ставками є однією з найскладніших ситуацій для навігації англійською. У цій статті ви знайдете точний словник, який вам потрібен для впевненої співпраці.
Ролі водіїв і навігаторів
У серці парного програмування лежить простий поділ праці. ** Драйвер ** це людина з руками на клавіатурі — вони вводять код і керують редактором. ** навігатор ** дивиться на велику картину: вони переглядають те, що вводиться, думають про те, що буде далі, і ловлять проблеми, перш ніж вони стануть вадами.
Це не постійне завдання. Добрі пари часто змінюють один одного, іноді кожні кілька хвилин.
** Фрази передачі для ролі драйвера: **
«Хочеш трохи поїхати?» «Я візьму кермо — ти був у цьому деякий час» “Готовий до обміну? Я хочу спробувати щось»
** Фрази передачі для ролі навігатора: **
«Я буду керувати цим наступним розділом — йди і їдь» “Твоя черга вести судно. Я хочу зосередитися на введенні цього»
Робота навигатора - керувати без мікроуправління. Ефективні запити навігатора запитують питання, а не надсилають команди:
Чи не слід нам перевірити
nullтут, перш ніж ми відреференсуємо?» «Існує можливий краєвий випадок з порожніми масивами — варто перевірити?» «Я запитую себе, чи масштабується цей підхід, коли список має десять тисяч елементів»
Зверніть увагу на мовлення: “не слід нам”, “може бути”, “я запитав, чи”. Цей формат запрошує до обговорення, а не закриває його.
Розуміння під час кодування
Однією з основних практик парного програмування є думання вголос — розповідь ваших міркувань під час написання коду. Це зберігає вашого партнера зацікавленим, виявляє непорозуміння на ранній стадії, і часто допомагає вам вловити власні помилки, перш ніж ваш партнер це зробить.
Описуючи свої рішення:
«Я збираюся витягнути це в допоміжну функцію — я думаю, що нам це знову знадобиться пізніше» «Дозвольте мені прослідкувати, що відбувається, коли список порожній.» «Я збираюся використовувати
Mapтут замість простого об’єкта для виконання пошуку.»
** Перевірка спільного розуміння: **
Чи має це сенс?» “Я занадто швидко? Скажи мені, якщо ти хочеш, щоб я сповільнив темп» «Ви слідкуєте за моїми роздумами, чи мені пояснити, чому я вибрав цю структуру?»
Звичай вербалізувати свої думки спочатку здається незграбним — особливо якщо ви звикли програмувати наодинці у тиші — але це найцінніша вміння, яке ви можете розвинути для спільної роботи.
Технічна мова розбіжностей
Незгоди трапляються в кожній парі. Код не завжди буде йти в напрямку, який хоче один партнер. Спосіб, у який ви виражаєте відмову, має величезне значення: метою є поліпшення коду, а не перемога у суперечці.
Уважительное отступление:
«Я бачу це по-іншому — що, якби ми розділили проблеми тут?» Чи ви розглядали вплив на продуктивність виклику цієї функції всередині петлі? «Я б запропонував нам дослідити альтернативний підхід — чи можу я показати вам, про що я думаю?»
Прошу про роздуми, а не лише про рішення:
Які ж причини такого рішення?» «Проведи мене через твоє мислення — я хочу переконатися, що я розумію, перш ніж ми підемо далі»
** Фрази для паузи і роздумів: **
«Давайте зробимо крок назад і подумаємо про більшу картину на хвилину» «Перед тим, як ми підемо далі — чи ми вирішуємо правильну проблему?» “Я хочу поднять проблему, не блокируя нас. Чи можемо ми припаркувати це і повернутися до нього?»
Фраза «паркувати» — що означає тимчасово відкласти щось на сторону — надзвичайно поширена в інженерних командах. Вивчайте і використовуйте.
Програмне забезпечення
**Mob програмування ** (або **ensemble програмування **) розширює модель пари до цілої команди: зазвичай від трьох до семи людей працюють над однією проблемою, на одному комп’ ютері, в один час. Ролі змінюються на таймері, часто кожні п’ять-десять хвилин.
** Вводячий текст ** (іноді його називають драйвером у контексті груп) робить саме те, що каже група — він не приймає незалежних рішень:
«Скажи мені, що ввести» Чи я повинен це зробити зараз, чи ти хочеш продовжувати?» Я не впевнений, що я слідував — чи можете ви диктувати це знову?»
** Процесним керуванням ** займається ** координатор **, а не код:
«Давайте time-box цю дискусію — п’ять хвилин, тоді ми вирішимо.» «Всі мають п’ять хвилин, щоб поїхати, перш ніж ми поміняємося місцями» «У нас є ще дві повороти перед стендапом — давайте зосередимося»
У ** віддалених сеансах групового спілкування ** спільне використання екрана і дисципліна звуку стають критичними:
“Чи можете ви поділитись своїм екраном? Я не можу побачити, що ти пишеш» “Я буду мовчати, поки не прийде моя черга керувати” Чи можуть всі підтвердити, що можуть побачити термінал?
Дебютний сольний альбом Діксона
** Зневадження гумової качки ** — це практика пояснення вашого коду вголос неживому об’ єкту — зазвичай, гумовій качкі — щоб змусити ваш мозок сформулювати, що саме робить код, у порівнянні з тим, що ви думаєте, що він робить. Магия в том, что акт пояснения часто выводит ошибку на поверхность немедленно.
У парному сеансі ваш партнер виконує ту ж саму функцію, але пояснення має бути більш структурованим.
** Фрази для формальних пояснюючих сеансів: **
«Проведи мене через своє розуміння цієї функції» «Поясни мені це так, ніби я ніколи не бачив цю базу коду раніше» «Припустимо, я молодший розробник — як би ви описали, що робить цей метод?»
Момент проникнення
“О, почекайте — я бачу це зараз. Стан йде назад» “Ось де клоп. Розмова через це зробила це очевидним» “Я только что услышал, как я сказал что-то неправильно. Дай мені секунду»
Момент проникнення - ця раптова ясність, яка приходить в середині пояснення - це причина, чому зневадження гумової качки працює. Ваш партнер не повинен нічого говорити. Достатньо простого слова.
Використовує англійську мову програмування
Готові використовувати цей словник? Спробуйте вправи на розмову, призначені для співпраці розробників:
Вправляйтеся у вживанні фраз, що передають інформацію, мови незгоду і оповіді у вигляді роздумів уголос, поки вони не стануть автоматичними — ваші сеанси у парі будуть гладшими.
Національна ідентичність: розглядаючи культурні відмінності в комунікації
Парне програмування і сеанси спільноти процвітають на відкритому спілкуванні. Однак для розробників, які вивчають професійну англійську як другу мову, тонкі відмінності у фразуваннях і очікуваннях можуть створювати тертя - не через намір, а через вкорінені стилі спілкування. Важливо розуміти, що те, що може бути цілком прийнятним в одному культурному контексті, може здатися різким або надто прямим в іншому. Наприклад, ентузіазм «Давайте просто зробимо це!», Використовуваний водієм, який рухається вперед з рішенням, може бути сприйнятий як відкидаючий, якщо навігатор відчуває, що їхні побоювання щодо потенційних ризиків не були повністю розглянуті. Аналогічно, негайна незгода під час перегляду коду - навіть добре обґрунтована - може бути інтерпретована по-різному в залежності від культурних норм, що оточують ієрархію і повагу до старшинства.
Ключовим напрямком для фокусування є розуміння * активного слухання * фраз. Хоча носії рідної англійської часто використовують їх непрямо, носії інших мов можуть відчувати тиск, щоб негайно відповісти з рішенням або виправленням. Заохочення використання фраз на кшталт «Чи можете ви розібратися в цьому?» або «Я не впевнений, що я повністю розумію - чи можете ви провести мене через ваше мислення?» демонструє повагу до різних точок зору і дозволяє прояснити * перед * переходом до дії. Крім того, пам’ятайте про рівень формальності. Прямість зазвичай цінується в технічних середовищах, але надто тупі висловлювання можуть пошкодити відносини. Конструктивное оформлення зворотного зв’язку - починаючи з визнання позитивних аспектів перед тим, як пропонувати пропозиції - це універсально цінована техніка. Не припускайте, що всі розуміють ідіоми або жаргон; явне пояснення технічних термінів і концепцій залишається життєво важливим.
Інша поширена проблема виникає з різних підходів до вирішення проблем. Деякі культури надають пріоритет спільному прийняттю рішень на основі консенсусу, в той час як інші цінують індивідуальну ініціативу і швидке виконання. Ясне спілкування про бажаний підхід команди - чи це структурований, покроковий процес або більш гнучкий, дослідницький - може зменшити непорозуміння. Також важливо пам’ятати, що “думання вголос” не просто про вербалізацію вашого коду; це про поділ вашого розуміння. Явно заявивши * чому * ви вибираєте певний підхід, ви будуєте довіру і дозволяєте іншим зрозуміти ваш процес мислення, незалежно від їхньої рідної мови.
Нарешті, зверніть увагу на вплив невербальних сигналів. Підтримання зіркового контакту (де це культурно відповідно), кивання, щоб показати розуміння, і використання відкритої мови тіла може значно поліпшити ефективність спілкування. Ці тонкі сигнали часто передавати більше, ніж слова самі по собі.
# Example: Using `git diff` to discuss a code change with a team member
git diff --color=auto HEAD~1 HEADЗа допомогою цієї команди можна побачити відмінності між поточним зберіганням ( HEAD ) і попереднім ( HEAD~1 ). Ви можете використовувати цей вивід, разом з фразами на кшталт «Гаразд, тож ми додаємо цю функцію для обробки X…» або «Я запитав, чи може цей підхід ввести Y…», щоб обговорити зміну коду з колегою.