Як використовувати мову Hedging в технічній англійській
Дізнайтеся, як професійно виразити невизначеність англійською мовою за допомогою мови хеджування: might, could indicate, it appears, preliminary results suggest і т. д.
У технічному спілкуванні, виражаючи впевненість, коли ви не впевнені, є помилкою - і потенційно дорогою. Досвідчені інженери, дослідники і технічні письменники використовують ** hedging language **, щоб сигналізувати про ступінь впевненості, яку вони мають у твердженні. Це не неясність, це точність. Цей посібник пояснює, коли і як правильно хеджувати технічною англійською.
Що таке хеджування?
** Хеджування ** це використання лінгвістичних засобів для позначення того, що твердження є невизначеним, приблизним або заснованим на обмеженому доказі. У повсякденній англійській люди хеджують фразами на кшталт “Я думаю” або “можливо”. У технічній і професійній англійській хеджування більш різноманітне, більш нюансоване і більш навмисне.
Хеджування має значення в:
- Отчеты об инцидентах и вскрытиях
- Дослідження та аналіз даних
- Пропозиції архітекторів
- Оновлення стану, коли причина проблеми ще не підтверджена
- Витягнути коментарі запитів, якщо ви не впевнені у правильності підходу
Модальні дієслова: могла, могла, могла
** Модальні дієслова ** є найпоширенішими засобами захисту. « Може », « міг би » і « може » виражають можливість, а не певність.
** Можливо ** виражає відносно низьку ймовірність або можливість:
- “Спостерігається перевищення часу очікування, можливо, через вичерпання резерву з’ єднань під час великого навантаження.” * “Ця зміна може призвести до непрацездатності клієнтів, що використовують застарілу кінцеву точку автентифікації.”
** Можливо ** виражає логічну можливість — щось, що може статися, але не обов’ язково ймовірне:
- « Витік пам’ яті може бути у обробнику подій — його ніколи не буде скасовано реєстрацію. » * “Використання однопоточної моделі може стати вузької ямкою в масштабі.”
** May ** є більш формальною формою, яку часто використовують у технічній документації:
“Ця поведінка може відрізнятися залежно від операційної системи.”
- “Користувачі можуть відчувати підвищену затримку під час годин пік.” *
«З’являється» і «Здається»
Ці дієслова позначають, що ви повідомляєте про спостереження, а не про підтверджений факт — це особливо корисно у звітах про події, які не підтверджено як основну причину.
“Здається, що служба почала відмовлятися в 14:32 UTC, приблизно через дві хвилини після того, як було впроваджено зміну конфігурації.”
- “Здається, що журнали вказують на затримку у менеджері транзакцій, але ми ще не підтвердили це.” *
Зауваження: «появляється» трохи більш формальний і краще в письмовому технічному спілкуванні.
«Пропозиції» і «Індикації»
Використовуйте ці дієслова, коли докази вказують на висновок, але не доводять його остаточно.
- “Профіль продуктивності свідчить про те, що в’ язка знаходиться у шарі запиту бази даних, а не на сервері програми.” *
- “Шаблон помилок вказує на умову гонки, але нам потрібно відтворити його в контрольованих умовах, щоб бути впевненими.” *
Кваліфіковані твердження: «попередній», «початковий», «ймовірно»
Прикметники і прикметники можуть захищати висловлювання без зміни його граматичної структури.
“Перехідні результати показують, що нова стратегія кешування зменшує затримку p99 приблизно на 30%.”
- “Наше початкове аналізування вказує на неправильне налаштування балансувальника навантаження.” *
- “Це, ймовірно, тимчасова проблема, пов’ язана з розгортанням, а не фундаментальна проблема архітектури.” *
«Виявляється, що…» проти «Це так, що…»
Порівняти ці дві форми:
| Strong (no hedging) | Hedged |
|---|---|
| ”The bug is caused by…" | "The bug appears to be caused by…" |
| "This will fail under high load." | "This could fail under high load." |
| "The change broke the API." | "The change may have introduced a regression in the API.” |
Захищені версії не слабші — вони більш точні. Вони сигналізують, що може знадобитися подальше розслідування.
Коли не слід хеджувати
Хеджування не підходить, якщо:
- Вы подтвердили доказательства, и хеджирование создаст лишние сомнения
- Ви вказуєте вимогу або специфікацію (« система повинна…», а не « система може…»)
- Ви документуєте підтверджену поведінку у документації API
- Вам слід бути авторитетним у прийнятті рішення (« Ми використаємо PostgreSQL », а не « Ми можемо використовувати PostgreSQL »)
- « Скасування розпізнавання через 24 години. » * — підтверджена поведінка, не потрібне хеджування
- “Кореневой причиной был отсутствующий индекс в таблице
orders.” * — пост-доследование подтвердило обнаружение
Практичні фрази для технічного хеджування
-
- “Це може бути пов’ язано з витоком пам’ яті, який ми виправили у версії 2. 3.” *
- “Метрика свідчить про кореляцію, але ми не повинні припускати причинно-наслідковий зв’язок без подальшого тестування.”
- “Служба відновлюється автоматично приблизно через 90 секунд.”
-
- “Попередні випробування показують поліпшення, але нам потрібно більше даних, перш ніж зробити це типовим.” *
- “Це може вплинути на користувачів з старими версіями браузера — ми повинні перевірити.”
- “Здається, тут є певна схема, хоча розмір нашої вибірки невеликий.”
Вважається, що це стосується британських та американських мов
У британській англійській мові «may» і «might» розрізняються більш ретельно: «may» означає теперішню можливість, «might» означає минулу можливість або більш віддалений шанс. На практиці, це розмежування часто розмито в технічному письмі, але розуміння цього допомагає вам точніше читати британські технічні документи.
Хеджування мови - це ознака інтелектуальної чесності і професійної зрілості. Інженери, які відповідно хеджують, будують довіру - вони не стверджують впевненості, якої вони не мають, і вони не створюють хибної довіри до систем або аналізів. Якщо правильно використовувати, хеджування робить ваші технічні повідомлення більш точними, а не менш.
Наприклад, мова йде про неможливість розуміння немовлями немовлят
Хеджування мови - ті фрази, які пом’якшують твердження і визнають можливість - є ключовими для професійного спілкування. Але для розробників, які вивчають технічну англійську, * спосіб * використання мови може бути таким же важливим, як і самі слова. Часто нерідні носії підходять до хеджування з певною мірою непевності, бажаючи передати абсолютну впевненість, щоб продемонструвати компетентність. Це часто призводить до надмірно настійливих фраз, які насправді можуть підірвати довіру і створити тертя під час перегляду коду або при поясненні складних питань. Ключовим є розуміння * чому * ми використовуємо хеджування і застосовуємо його стратегічно, не як знак слабкості, а як показник ретельного розгляду.
Розглянемо такий сценарій: ви щойно завершили дослідження вузької місцини у системі журналювання програми. Ви виявили шаблон, за допомогою якого під час пікового навантаження створюється надто багато команд журналу, що спричиняє повільний час відповіді. Під час перегляду коду ваш колега Алекс коментує ваш запит на звантаження: « Це виглядає добре, але * здається *, що об’ єм журналів сприяє уповільненню ». Зауважте, що Алекс не стверджує однозначно, що журнали є проблемою — « здається », що підтверджує можливість інших факторів. Більш пряме твердження, наприклад, «Журнали спричиняють уповільнення» було б набагато конфронтаційнішим і могло б негайно викликати оборонну реакцію. Фраза «здається» запрошує до подальшого обговорення і дослідження, а не представляє твердий висновок.
Іншою поширеною ситуацією є повідомлення попередніх результатів експерименту. Уявіть, що ви повідомляєте про початкові результати нової стратегії кешування вашій команді через Slack: «Перший тестовий запуск може показати покращення затримки на 15%». Знову ж таки, використання «може» відразу сигналізує, що це засновано на обмеженій кількості даних і може змінюватися. Сказати «Стратегія кешування покращує затримку на 15%» було б надто сильним, враховуючи ранню стадію тестування. Аналогічно, при написанні опису PR для нової функції, заява на кшталт: «Ця рефакторинг * може * призвести до поліпшення масштабованості» є кращим, ніж заява про остаточне поліпшення масштабованості. Це дозволяє місце для майбутніх коригувань і визнає, що вплив може не бути відразу очевидним.
І, нарешті, не впадайте в пастку надмірного страхування! Невелика невизначеність — це добре; надмірне обмеження може зробити ваше спілкування нечітким і непереконливим. Сфокусуйтеся на чіткому представленні ваших результатів, визнаючи при цьому потенційні обмеження або області, які потребують подальшого дослідження. Метою є не уникнути заяв, а обмежувати свої висновки відповідними рівнями впевненості.
Ось простий приклад використання curl для проілюстрації того, як ви можете повідомити про результати гіпотетичного виклику API:
curl -s https://api.example.com/v1/users?limit=10 | jq .Ця команда отримує дані з кінцевої точки API і використовує jq (процесор JSON) для форматування виводу для зручності читання. Навіть якщо ви повідомляєте про щось на зразок цього — що є відносно простим — вам слід знати, що « Початковий виклик API * може * повернути список користувачів, хоча час відповіді може змінюватися залежно від завантаження сервера ». Це додасть контексту і керуватиме очікуваннями без надмірної розгорнутості.