Як обговорювати код власності англійською мовою
Вивчіть англійські фрази для обговорення права власності на код: хто є власником чого, шляхи ескалації і спільна відповідальність у зростаючій базі коду.
«Чий це код?» постійно запитують, коли база коду зростає, і відповідаючи на нього нечітко («Я думаю, що команда платформи підтримує це») сповільнює кожен перегляд, кожен інцидент і кожну розмову про дорожню карту, яка торкається спільного коду. Цей підручник описує, як чітко вказати і обговорити право власності.
Ключовий словник
** Основний власник ** — особа або команда, яка має останнє слово щодо напрямку частини коду і є першою точкою контакту для питань щодо нього, відмінною від будь- кого, хто лише вніс свій внесок у нього. “Команда розробників платформи є основним власником бібліотеки auth — будь- які зміни, які порушують її, потребують їх підпису, навіть якщо інша команда написала початковий PR.”
** Внесок (або власник) ** — хтось, хто вніс зміни до коду, який не належить йому, зазвичай, перед об’ єднанням, особливо якщо зміни є значними, потрібна перевірка або затвердження головного власника. “Ми є співробітниками цієї служби, а не власниками — ми можемо надіслати PR, але команда на виїзді для цієї служби все ще має схвалити його перед об’єднанням.”
Крайня межа власності — явне позначення лінії, де відповідальність однієї команди за кодову базу закінчується і починається відповідальність іншої, ідеально задокументоване, а не виведене з git blame. “Крайня межа власності тут — це шар API — все за цим інтерфейсом є відповідальністю команди даних, і все перед ним є нашим.”
** Осиротілий код ** — код, який не має чіткого поточного власника, зазвичай, через те, що початкову команду було реорганізовано або початковий автор пішов, для якого потрібно визначити нового власника, а не залишати його неоднозначним назавжди.
- “Цей модуль залишився сиротою, оскільки команда, яка його створила, була розпущена минулого кварталу — нам потрібно визначити нового власника, перш ніж його торкнеться наступне оновлення залежностей.” *
Звичайні фрази
- «Хто є основним власником цієї служби — чи це все ще ваша команда?»
- «Ми тут співробітники, а не власники, тому це потребує підпису від команди власників»
- «Де межа власності між нашим сервісом і вашим?»
- Цей код виглядає сиротою — чи можемо ми отримати явного власника, призначеного до того, як ми будемо будувати на ньому?»
- Чи можемо ми документувати це право власності десь, щоб це не було просто племінним знанням?»
Приклади висловлювань
Перевірка власника перед внесенням змін:
- “Перед тим, як я надсилю цей PR, чи можете ви підтвердити, що ваша команда досі є основним власником цього модуля? Я хочу переконатися, що правильні люди переглядають його, а не тільки ті, на кого git blame вказує»
Повідомлення про код, що залишився сиротою:
- “Ця бібліотека не мала команди власників з часу реорганізації платформи два квартали тому. Перед тим, як ми додамо ще одну залежність до нього, чи можемо ми отримати когось, хто явно прийме власність, навіть якщо це просто відповідальність за викликом? ”*
Переговори щодо межі власності у обговоренні проекту:
- “Я б запропонував, щоб межа власності була на рівні черги — ваша команда володіє всім, що публікується в ній, а ми володіємо всім, що споживає з неї. Таким чином кожна сторона може змінювати свої внутрішні елементи незалежно.»*
Професійні поради
- Запитуйте “хто є головним власником” явно, а не припускаючи, що це залежить від того, хто останнім торкався коду — історія git часто відображає, хто виправив ваду один раз, а не хто насправді відповідає за систему.
- Використовуйте contributor, щоб чітко описати свою роль під час запропонованих змін до коду, який не належить вам — це встановить правильний очікування, що перегляд командою власників є обов’ язковим, а не необмеженим.
- Натисніть, щоб зробити ** межу власності ** явною і задокументованою в будь-якому крос-командному дизайні, а не залишати її як припущення - недокументовані межі є місцем, де відповідальність беззвучно зникає під час інцидентів.
- Позначайте ** сирітський код **, коли ви його помічаєте, особливо перед додаванням нових залежностей до нього — призначення власника до того, як він стане критичним, набагато дешевше, ніж це робити під час інциденту.
Практичні вправи
- Напишіть речення з запитанням, хто є основним власником частини коду.
- Поясніть різницю між тим, щоб бути співробітником і власником.
- Написати повідомлення з позначкою сиротського коду і запитом на призначення нового власника.
Національні мови: мова рідних, мова нерідних
Ефективне обговорення права власності на код не просто про те, хто відповідальний; це глибоко переплетене з тонкими нюансами професійної англійської. Для розробників, чия перша мова не є англійською, розуміння цих тонкощів - особливо навколо фразування і очікувань - може значно поліпшити співпрацю і зменшити непорозуміння. Розглянемо деякі спільні області, де носії мови можуть використовувати певний словниковий запас, який може здатися незнайомим, і як до них підходити з ясністю.
Одна з часто зустрічаються областей плутанини виникає з самої концепції «власності». Це часто сприймається як суворе, ієрархічне завдання, але в сучасній розробці програмного забезпечення, це часто більше про відповідальність і вирівнювання. Замість того, щоб сказати « Джон є власником цієї можливості », що може звучати надто авторитетно, розгляньте такі фрази, як « Джон є головним відповідальним за постійне підтримання і еволюцію цього компонента » або « Джон є головним власником у команді щодо цієї області ». Використання таких термінів, як « вирівнювання », « співпраця » і « спільна відповідальність » підкреслює, що це командні зусилля. Аналогічно, при описі виправлення помилки, замість того, щоб просто сказати « Виправте це », що може звучати вимогливо, спробуйте « Чи могли б ви дослідити і вирішити проблему з цим PR? Ми особливо зацікавлені в тому, щоб це було врівноважене з більш широкою системною архітектурою. “Ця фраза демонструє повагу до їхньої експертизи і чітко говорить про бажаний результат.
Іншою ключовою областю є шляхи ескалації - знати * як * висловлювати занепокоєння або просити підтримки. Пряме слово «Мені потрібна допомога!» може відчуватися конфронтаційним. Професійніший підхід включає такі фрази, як: «Я виявив потенційний ризик у цій області і був би вдячний за ваші рекомендації щодо того, як найкраще діяти», або «Щоб переконатися, що ми підтримуємо послідовність у всій базі коду, я хотів позначити це для перегляду і обговорити потенційні наслідки». Формування його як пошуку рекомендацій, а не вимоги допомоги часто є більш ефективним. Під час створення описів PR уникайте надто технічного жаргону, який може бути не відразу зрозумілим для рецензентів. Замість того, щоб сказати «Рефакторинг за допомогою шаблону X», спробуйте «Цей рефакторинг покращує читання коду і підтримку, відповідно до стандартів кодування нашої команди»
Нарешті, пам’ятайте, що ясність і активне слухання є найважливішими. Не вагайтеся попросити про пояснення, якщо фраза неясна - це * набагато * краще визнати, що ви не розумієте, ніж неправильно інтерпретувати критичну інструкцію або очікування. Фрази на кшталт «Чи можете ви розібратися, що ви маєте на увазі під…?» або «Чи можете ви дати мені приклад того, як це слід реалізувати?» є цілком прийнятними і демонструють вашу прихильність до повного розуміння ситуації. Важливо також бути уважним до тону, навіть у письмовому спілкуванні. Ввічливий і шанобливий підхід завжди сприяє більш продуктивній розмові.