Як не погоджуватися професійно в перегляді коду

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

---

Мова кодування в кодуванні

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

Цель не в том, чтобы быть менее честным. Це буде більш ефективним. Коментар, який сформулюваний з повагою, швидше за все, буде почуто, розглянуто і виконано.

---

Виразити занепокоєння без звинувачення

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

** Замість: **

“Це не працюватиме під одночасною нагрузкою.”

Спробуй

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

Друга версія:

• Виражає занепокоєння, а не звинувачення
• Задає питання, запрошує до діалогу
• Вказує сценарій, який вас хвилює

---

Фрази, що використовуються для порозуміння

Дослідження / Упоряд

Ці фрази сигналізують про цікавість, а не критику:

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

Представлені альтернативні варіанти

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

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

Знак зауваження

Якщо у вас є певні зауваження, але ви не впевнені:

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

Прохання про пояснення перед незгодом

Іноді автор має причину для вибору, яка не буде видно у файлі diff:

“Чи можете ви допомогти мені зрозуміти, що стоїть за цим підходом? Я хочу переконатися, що я не втрачаю контексту, перш ніж підняти проблему.» “Чи є особлива причина, чому ми не використовуємо існуючу утиліту validateInput?”

Підтверджую наближення, а потім піднімаю точку

Структура « так, і » підтверджує роботу автора перед введенням зауваження:

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

---

Ненасильницьке спілкування (NVC) в кодових оглядах

** Ненасильницьке спілкування (NVC) ** це система, розроблена Маршаллом Розенбергом, яка заохочує висловлювати спостереження, почуття, потреби і прохання без звинувачення або судження. У перегляді коду корисною буде спрощена версія:

1. ** Спостерігайте ** — описуйте те, що ви бачите, а не те, що ви судите
2. ** Виразити занепокоєння ** — пояснити, що вас хвилює
3. ** Запит ** — запит на певну зміну або обговорення

Погана (заснована на судженні):

“Цей код - спагеті. Ніхто не зможе підтримувати це.»

Краще (інформовано NVC):

• “Мені важко слідкувати за потоком керування у цій функції — існує п’ ять точок виходу у чотирьох різних умовах. Чи можемо ми обговорити, чи можемо ми спростити це з раннім поверненням шаблону або вилученням деяких умов логіки?” *

---

Розрізняють окремі види блокування

Не всі розбіжності однакові. Будь ласка, вкажіть, чи є ваш коментар обов’ язковою вимогою, чи особистим уподобанням. Багато команд використовують такі мітки:

• ** nit: ** — незначні, не блокуючі (наприклад, форматування, налаштування назв)
• ** suggestion: ** — варто розглянути варіант покращення
• ** проблема: ** — потенційна проблема, яку варто обговорити
• ** блокування: ** — слід розв’ язати перед затвердженням

“nit: я б назвав це calculateTotalPrice, а не getTotalPrice, оскільки це обчислення, а не отримання — але це просто перевага, яку я з радістю відкладу.”

• “зауваження: Схоже, що це стосується запису сирого тіла запиту, яке може містити номери платіжних карток. Я б хотів, щоб ми редагували чутливі поля перед злиттям.”*

---

Прийняти відсіч грациозно

Професіоналізм у перегляді коду йде в обидва боки. Якщо автор не погоджується з вашим коментарем:

*“Це справедлива думка — я не розглядав поведінку кешування у цьому випадку. Я радий відкласти цю справу»

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

---

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

Назва походить від англійського слова «discord» — «незгода»

Незгоди неминучі в перегляді коду. Це не про «перемогу» або про те, щоб бути правим; це фундаментально спільний процес поліпшення кодової бази. Однак, ефективне висловлення незгодні, особливо коли ваша перша мова не є англійською, може бути загрозливим. Багато розробників знаходять себе за замовчуванням до тупих заяв, що ризикують ескалацією напруги і перешкоджають продуктивній дискусії. Ключовим є перехід від простого слів, що ви не погоджуєтесь, до артикулювання ваших зауважень конструктивно - за допомогою того, що ми називаємо невербальним спілкуванням (НВС) в технології. Це означає, що ви можете дати оцінку впливу зміни, а не критикувати сам код.

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

Інша поширена ситуація виникає під час перегляду опису запитів на завантаження. Розробник може просто стверджувати: « Виправлено помилку X ». Хоча це технічно вірно, воно не надає контексту для переглядачів. Професійнішою формулюванням було б: «Ця PR вирішує ваду X [коротко пояснюючи виправлення - наприклад, змінюючи логіку перевірки в модулі автентифікації користувача]. Я також додав деякі тести, щоб переконатися, що ця проблема не з’ являється знову і щоб зберегти ясність коду. “Використання таких фраз, як “адреси”, “зміна” і “забезпечення” демонструє чітке розуміння зміни і її цілі, зменшуючи неоднозначність і сприяючи гладкішим переглядам. Пам’ятайте, чітке спілкування зменшує непорозуміння і сприяє взаємному повазі.

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