Tech Lead English: Code Reviews, Planning, and Team Alignment Vocabulary (англійською)

Introduction

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

Переклад з англійської

Технічні лідери часто встановлюють тон для культури перегляду коду. Словниковий запас має значення, оскільки він впливає на те, як рецензенти надають зворотній зв’ язок, а також на те, як автори отримують цей зворотній зв’ язок:

• «Це блокування — ми не можемо об’єднуватися, поки це не буде вирішено» — сигналізує про необхідну зміну
• «Це ніт — не соромтеся ігнорувати» — сигналізує про незначні переваги стилю
• «Я залишив деякі пропозиції — прийміть їх або залиште їх» — низько-тиск рекомендації
• «Цей підхід стосується мене — чи можемо ми обговорити це перед злиття?» — вимагає розмови, а не прямого блокування
• «Нічний поліпшення тут» або «Хороше мислення» — позитивне підкріплення; важливо для культури
• «Чи ви розглядали [альтернативу]?» — пропонує варіант без вимоги його
• «Це шаблон, від якого ми намагаємося відійти — чи можете ви використовувати [X] замість цього?» — надає контекст для запиту

Розрізняють blocker і nit (nitpick). Блокери заважають злиттю. Гниди необов’язкові. Поєднання їх призводить до того, що автори відчувають себе занадто рецензованими, а рецензенти втрачають довіру.

Планування та оцінка спроб

У гнучких командах, технічні лідери часто глибоко залучені в планування спринту. Словник:

• ** спринт ** — фіксоване період часу (зазвичай два тижні), протягом якого команда завершить заплановану кількість роботи
• ** мету спринту ** — основну мету, яку команда прагне досягти у спринті; « нашою метою спринту є завершення інтеграції потоку платежу »
• ** user story ** — опис можливості з точки зору користувача; « як користувач, я хочу скасувати свій пароль, щоб знову отримати доступ до свого облікового запису »
• ** точки історії ** — відносна мірка зусиль, а не часу; « ми оцінили цю історію у 5 очок, оскільки вона включає зміну сервера і оновлення фронт- енд »
• ** speed ** — скільки очок історії команда зазвичай завершує за спринт; « наша середня швидкість становить 32 очки, тому ми не повинні зобов’ язуватися на більше »
• ** spike ** — коротке, обмежене часом дослідження, щоб зменшити невизначеність; « нам потрібен пік, щоб перевірити, чи сторонній API підтримує webhooks »
• ** перенесення ** — робота, яку не було завершено у поточному спринті, перенесено до наступного; « у нас є дві історії, які перенесено з попереднього спринту »

Фраза, яку технічні лідери регулярно використовують при плануванні: «Ми перебільшуємо — на основі нашої швидкості, ми можемо реально завершити близько 70% того, що зараз заплановано. Що ж нам робити?»

Управління технічними суперечками

Технічні керівники потребують мови для конструктивного вирішення розбіжностей:

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

Фраза “звони” важлива для технічних лідерів. Это значит принимать решение, когда команда застряла. Технічні лідери, які ніколи не телефонують, створюють неоднозначність; ті, хто телефонує занадто швидко, втрачають команду.

Підтримувати команди в порядку

• ** технічна дискусія щодо боргу ** — розмова про прийняті скорочення, які потрібно виправити; « нам потрібна спеціальна дискусія щодо технічного боргу у наступній сесії планування »
• ** перегляд архітектури ** — зустріч для оцінки запропонованого технічного проекту; « ми проводимо щотижневий перегляд архітектури для будь- якого проекту, який перетинає межі команди »
• ** визначення виконано (DoD) ** — спільні критерії, які завдання має задовольняти, перш ніж його вважати завершеним; « наш DoD вимагає успішних тестів, оновлення документації і перегляду безпеки для нових кінцевих точок »
• «Ми повинні соціалізувати цю зміну» — поділитись запланованою зміною з відповідними зацікавленими сторонами перед її впровадженням; «давайте соціалізуємо переробку API з мобільною командою, перш ніж ми зобов’язаємося»

Ключовий словник

Term	Definition
blocker	A code review comment that must be resolved before merging
nit	A minor optional suggestion in a code review
sprint goal	The primary objective the team aims to achieve in a sprint
story points	A relative measure of task complexity used in sprint planning
velocity	The average number of story points a team completes per sprint
spike	A time-boxed exploration to reduce uncertainty
carry-over	Work not completed that moves to the next sprint
make a call	Make a decision when discussion has stalled
definition of done	Agreed criteria a task must meet to be considered complete
socialise	Share a change with stakeholders before implementing it

Практичні поради

1. ** Нанесеть мітку на ваші коментарі щодо перегляду коду. ** Перед кожним коментарем додайте префікс: « Блокування: », « Ніт: », « Питання: » або « Пропозиція: ». Це негайно зробить ваші наміри зрозумілими і допоможе авторам визначити пріоритети відповідей.

2. ** Вправляйтеся у використанні фрази « Я збираюся викликати ». ** Ця фраза вимагає впевненості у собі, особливо якщо ви не є носієм англійської мови. Практикуюсь в ситуациях с низкими ставками, чтобы это казалось естественным, когда тебе это нужно в настоящем разногласии.

3. ** Використовуйте « socialise » у професійному значенні. ** У технічній англійській мові « socialise » означає неформальний обмін інформацією з учасниками перед формальною пропозицією. « Ми повинні обговорити це з командою платформи » — це професійна і шанована фраза.

4. ** Напишіть « Визначення виконаного » для вашої команди. ** Це вправу змушує вас думати про стандарти якості у точній англійській мові. ДоД повинен бути коротким, конкретним і вимірюваним: «Всі нові кінцеві точки мають: тести з 80% + покриттям, документацію OpenAPI і підписання перегляду безпеки»

Conclusion

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

Наприклад, англ. anchoring — тримання ланцюга

Як не рідною мовою, освоєння нюансів технічного спілкування може відчувати себе особливо складно. Це не просто про те, щоб знати самі слова; це про розуміння немовлених очікувань в професійному середовищі. Здається, просту фразу, наприклад, « зневадження гумової качки », можна неправильно інтерпретувати, якщо ви не розумієте основної концепції вербального викладення проблеми, щоб прояснити своє мислення. Аналогічно, зворотній зв’язок на перегляд коду, особливо коли він доставляється з сильною мовою, може відчувати себе пригніченим без структури для інтерпретації його намірів. Давайте розглянемо деякі поширені сумніви і надамо практичні стратегії.

Однією з часто зустрічаються проблем є розуміння конструктивної критики. Багато розробників, незалежно від володіння рідною мовою, можуть сприймати негативну фразу як негайно критичну. Ключовим тут є зосередитися на * дії *, яку потрібно виконати, а не на судженні, яке передбачає. Замість коментаря на зразок « Цей код не дуже чіткий », хороший технічний керівник сказав би: « Давайте переробимо цей розділ для поліпшення читабельності; це полегшить роботу за рахунок ясніших назв змінних і послідовного відступу ». Зауважте, що останній розділ зосереджено на розв’ язанні проблеми — переробці — а не просто на вказівці на помилку. Аналогічно, коли ви просите про зміни під час перегляду коду, уникайте обвинувальних тверджень на кшталт «Ви повинні були зробити…» Замість цього, оформляйте свої пропозиції як спільні дослідження: «Чи могли б ми дослідити, використовуючи цей підхід, щоб звернутися до X?» або «Мені цікаво, чи можемо ми розглянути Y для цього конкретного сценарію»

Іншою перешкодою є використання специфічного технічного словника. Такі терміни, як «технічний борг», «низько висять плоди» і «шпильки» часто зустрічаються швидко в швидкому середовищі, але їх точне значення може бути нерозбірливим без контексту. Не вагайтеся просити про пояснення. Набагато краще визнати, що ви чогось не розумієте, ніж робити припущення, які можуть призвести до непорозумінь або неефективної роботи. Просте питання на кшталт: «Чи можете ви пояснити, що ви маєте на увазі під «технічним боргом» в цьому контексті?» демонструє залученість і бажання вчитися. Пам’ ятайте, що більшість досвідчених членів команди раді допомогти роз’ яснити жаргон.

І нарешті, пам’ятайте про формальність спілкування. Хоча прямота цінується, надто тупий мова може бути неповажною або відверто. Стрімтеся до ясності і точності, але завжди підтримуйте тон, який є співпрацею і підтримкою.

# Example: Using `git diff` to highlight changes in a pull request description

git diff --color=user  --summary

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