Як запитати про допомогу в послідовності перегляду коду

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

Ключові фрази

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

• “Я не впевнений, що розумію, що робить ця функція у випадку невдачі — чи можете ви провести мене через це?” *

** Запит на контекст ** — запит на інформацію про фон, яку не можна побачити у самому diff.

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

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

• « Я не маю чіткого контексту на рівні кешування — чи варто було б зациклювати когось з команди платформи на цьому конкретному коментарі? » *

Flagging your own uncertainty about a suggestion — proposing a change while being upfront that you might be missing something.

• “Це може здатися наївною пропозицією, але чи не краще використовувати множину замість списку? Дайте мені знати, якщо я не маю причини, чому це потрібно замовити. ”*

** Запит на пояснення ** — запит на пояснення автором зміни у словесній формі або більш докладно, часто для складної логіки. “Можете ли вы дать мне 15 минут, чтобы я прошел через это в ходе телефонного разговора? Я думаю, що зрозумію це швидше таким чином, ніж через коментарі»

** Визнайте, що ви щось дізналися ** — подяка рецензенту або автору за пояснення, яке створює довіру і заохочує до відкритості у майбутньому. “А, тепер це має сенс — дякую за пояснення логіки повторення, я не розглядав вимогу про ідемпотентність.”

Escalating politely — raising that a review has stalled or a disagreement needs resolution beyond the thread. “Ми кілька разів тут обговорювалися без угоди — чи не варто нам використати 10 хвилин одночасно, щоб вирішити це?”

Запитання, що не мають відповідей, не розглядаються

Ключ - бути конкретним про те, що ти не розумієш, а не нечітким, і сформулювати це як питання про код, а не про власні здібності.

• «Чи можете ви допомогти мені зрозуміти, чому ця перевірка відбувається до підтвердження, а не після?»
• «Я хочу переконатися, що я не пропустив щось — чи викликається ця функція де-небудь з порожнім масивом?»
• “I followed the logic up to this point, but I’m lost on how the retry count gets reset. Чи можете ви додати коментар, або пояснити тут?»

Запит довідки без затримки перегляду занадто довго

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

Фрази, яких слід уникати

Avoid	Try instead
“Sorry, I’m probably being dumb, but…”	“Could you clarify this part for me?”
“This is confusing.”	“I’m having trouble following the logic here — can you help me understand it?”
“I guess this is fine?”	“I don’t see an issue, but I’d like a second opinion since I’m less familiar with this area.”
“Never mind, I’ll figure it out.”	“Let’s sync briefly so I can ask a few quick questions.”

Професійні поради

1. ** Будьте конкретними щодо того, що ви не розумієте. ** « Я не розумію логіку повторення » є більш дійсним, ніж « це заплутано »
2. ** Відокремлюйте затвердження від повного розуміння, коли ризик низький. ** Не потрібно затверджувати зміни з низьким ризиком і просити про пояснення.
3. ** Розглядати запити на допомогу як звичайні, а не виняткові. ** Команди зі здоровою культурою перегляду сприймають питання як ознаку зацікавленості, а не слабкості.

Практичні вправи

1. Напишіть коментар (2- 3 речення), у якому ви визнаєте, що не розумієте частини запиту на завантаження, але не вибачайтеся за це.
2. Написати повідомлення з проханням про те, щоб колега по команді дав свою думку щодо коментаря, що ви не впевнені у його достовірності.
3. Написати ввічливе повідомлення про ескалацію для гілки перегляду, яка тричі переходила туди- назад без розв’ язання.

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

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

Одна з найчастіших перешкод - це просто визнання, що ти застряг. Замість того, щоб сказати щось на зразок: «Я не розумію цього», що може звучати пасивним і, можливо, означати відсутність зусиль, спробуйте фрази, які демонструють активну залученість. Наприклад, після отримання коментаря на ваш запит на скидання, що описує потенційну проблему з логікою у функції з назвою calculate_tax, ви можете відповісти: “Дякую за вказівку! Я переглядаю код і намагаюся зрозуміти, як умовні вимоги працюють з різними податковими категоріями. Може, ви б розказали, чому саме цей сценарій є проблематичним? Знання очікуваного результату дійсно допоможе мені визначити проблему. ” Зауважте використання “ Я зараз переглядаю ” — це показує, що ви активно працюєте над проблемою. Аналогічно, коли рецензент пропонує рефакторинг довгої функції, замість того, щоб сказати «Це занадто довго», розгляньте: «Це хороша точка про читабельність коду. Я досліджую способи розбити цю функцію на менші, більш керовані одиниці. Чи можемо ми обговорити, що є «надто довгим» в контексті нашої команди - наприклад, чи є конкретні обмеження довжини лінії або складності метрики, які ми повинні розглядати? ”

Крім того, важливо, щоб ваші запитання були запитаннями на інформацію, а не викликами. Уникайте фраз, що означають, що судження рецензента неправильне. Замість того, щоб сказати «Чому ви позначили це як помилку?», Що може звучати оборонно, виберіть: «Я намагаюся зрозуміти роздуми за цим відгуком. Можете ли вы рассказать мне о шагах, которые вы предприняли, чтобы выявить эту потенциальную проблему? Я хочу переконатися, що я повністю розумію вимоги і як мій код відповідає їм. » Питання про * їх * процес мислення демонструє повагу і готовність навчатися з їх досвіду, який високо цінується в колективних середовищах. Нарешті, пам’ятайте, що запитання на другу думку не є ознакою сумніву; це стратегічний підхід. Ви можете сказати: «Я ціную початковий відгук, і я хочу переконатися, що я на правильному шляху. Чи не був би ти готовий ще раз поглянути на це, як тільки у мене буде можливість реалізувати твої пропозиції?»