Граматика для технічного хеджування: Might, Could, Should
Дізнайтеся, як використовувати модальні дієслова might, could і should, щоб захистити технічні висновки, висловити невизначеність і дати професійні рекомендації англійською мовою.
У технічному спілкуванні важлива точність, але також і чесність щодо невизначеності. Досвідчені інженери не завжди знають відповідь на це питання з певністю. Вони працюють з неповною інформацією, роблять ймовірнісні оцінки, і пересуваються справжніми невідомими. Англійські модальні дієслова might, could, і should є граматичними інструментами для професійного вираження цієї невизначеності. Навчання правильно використовувати їх - це різниця між звучанням пробним і звучанням відповідно каліброваним.
Що таке криптовалюта і чому вона потрібна?
** Хеджування ** означає кваліфікацію висновку, щоб вказати, що ви не на 100% впевнені, або що твердження застосовується за певних умов. У науковому і технічному письмі, хеджування не є слабкістю - це точність. Заявляти, що ти впевнений, що не маєш, шкодить репутації. Хеджування точно його створює.
Порівняйте ці два речення:
- «Втеча пам’яті викликана тим, що слухач події не був видалений»
- «Витік пам’яті може бути викликаний тим, що слухач події не був видалений — я б хотів перевірити з профілером»
Друге речення більш професійне. Він повідомляє, в що ви вірите, будучи чесним щодо рівня довіри.
Модальне словосполучення
Модальні дієслова в англійській мові стоять перед головним дієсловом і змінюють його значення. Три найважливіші для технічного хеджування:
| Modal | Core meaning | Certainty level |
|---|---|---|
| might | possibility | Low to moderate (~30–50%) |
| could | possibility or ability | Low to moderate; also suggests capability |
| should | expectation or recommendation | Moderate to high; “expected to” or “it is advisable to” |
За всіма трьома слідує базова форма дієслова (без -s, без -ing, без -ed).
Використовуючи силу
** Можливо ** виражає справжню можливість, але сигналізує про відносно низьку впевненість. Використовуйте цей параметр, якщо ви спекулюєте, якщо докази є неповну, або якщо ви бажаєте позначити ризик, не стверджуючи його як факт.
Діагностика та лікування
- «Служба ** може ** бути тайм-аут через збільшення розміру вантажу, який ми розгорнули вчора.»
- “Ця помилка може з’явитися тільки під високою одночасністю — мені потрібно буде запустити тест навантаження, щоб підтвердити.”
- «Кеш може мати застарілі дані з часу до міграції схеми.»
Система управління ризиками
- Цей підхід може викликати проблеми, якщо база даних піддається великому навантаженню під час міграції
- «Видалення цього середовища ** може ** перервати поток автентифікації для застарілих клієнтів.»
- «API може поводитися по-різному в виробництві, де змінні середовища різні.»
Необхідно уникати помилок
Не використовуйте ** може **, якщо ви дуже впевнені. « Сервер ** може ** не працює », коли всі спостереження підтверджують, що він не працює, звучить нелогічно. Використовуйте « Сервер ** не працює ** — я розслідую причину. »
Може використовуватися
Could перетинається з might у вираженні можливості, але має додаткове значення: здатність або потенціал. У технічних контекстах це розрізнення має значення.
Вираз можливості (подібно до можливості)
- Проблема може бути пов’язана з відновленням сертифіката SSL
- «Існує може бути умова гонки в обробнику завантаження файлів.»
- Це може пояснити стрімкий ріст помилок, які ми побачили минулого четверту
Виразність і потенціал
- «Ми ** могли ** мігрувати до безсерверної архітектури, що зменшить операційні витрати.»
- Цей рефактор може зробити код значно легшим для тестування
- «Використання CDN тут може скоротити наш час до першого байта на 40%»
Вказівки та рекомендації
** Could ** — це природний модальний вираз для ввічливого представлення параметрів:
- «Ми можемо використовувати функціональний прапорець, щоб поступово розгортати це»
- «Ви можете також спробувати скасувати локальну кеш-пам’ять — це іноді вирішує це.»
- “Ми можемо розв’язати це в поточному спринті або відкласти його на наступний, залежно від пріоритету.”
Можливе проти можливого
Розрізняють тонкі, але реальні:
- “Це ** може ** викликати проблему з продуктивністю” = Я думаю, що є шанс, що це станеться
- “Це може викликати проблему з продуктивністю” = Це може викликати одну (за правильних умов)
На практиці носії обох мов використовують обидва взаємно виключно в неформальних технічних дискусіях. У формальному письмі (звіти про інциденти, архітектурні документи) варто відзначити цю відмінність.
Використання SHOULD
** Should ** має два різні застосування у технічній англійській, і їх поєднання є поширеним джерелом нерозуміння.
Очакування: «Це очікується, що станеться»
Коли ви кажете, що щось ** має ** статися, ви маєте на увазі, що згідно з вашим розумінням, проектуванням або специфікаціями, це очікувана поведінка.
- «Механізм повторних спроб ** повинен ** викликатися після трьох невдалих спроб.»
- «Збірка ** повинна ** завершити за менше ніж п’ять хвилин на стандартному runner. »
- «Токен ** повинен ** закінчитися через 24 години — якщо він закінчується раніше, це помилка»
Це використання should особливо корисно при зневадженні: «Це should працює, але це не так, що означає, що щось несподіване відбувається»
Рекомендація: «Я радий вам»
** Слід ** також виражає професійну рекомендацію — те, що ви вважаєте правильним або найкращим курсом дій.
- «Ми ** повинні ** додати перевірку вводу, перш ніж ці дані досягнуть бази даних. »
- Команда ** повинна ** переглянути цей PR перед злиття — є наслідки для безпеки. ”
- «Ми ** повинні ** документувати це рішення в архітектурному записі рішення. »
В. В. Столяр. Треба
** Слід ** передбачає рекомендованість; ** має ** або ** потрібно ** передбачає необхідність.
- “Вам ** варто ** додати тайм- аут” = Я рекомендую це; це хороша практика
- « Ви ** маєте ** додати тайм- аут » = Це обов’ язково; без цього будуть проблеми
Використовуйте це розрізнення навмисно. Зловживання ** must ** в рекомендаціях звучить диктаторським. Недоліки його використання для реальних вимог призводять до того, що люди ставляться до них як до опціональних.
Система управління: реальність та технології
В коді перегляду коментаря
“Ця функція може мати проблему, якщо userList порожня — чи ви можете додати нульову перевірку перед циклом? Поточний режим ** повинен ** викинути TypeError в цьому випадку, який ** може ** бути неочікуваним для викликаючих.”
В оновленні стану
“Розгортання ** повинно ** завершитися протягом наступних 20 хвилин. Там ** може ** бути короткий період підвищеного рівня помилок під час фази канарки - ми ** повинні ** бачити їх падіння назад до базису, як тільки рух змінюється повністю. “
В архітектурі
«Монолітна архітектура може працювати для нашого поточного масштабу, але вона може стати вузьким місцем, коли ми ростемо. Ми ** повинні ** розробити межі даних ретельно зараз, щоб ми ** могли ** витягнути послуги пізніше без повного переписування. “
В результаті інциденту
“Коренева причина ** може ** бути вичерпання бази даних з’ єднань, що ми визначили в журналах. Ми ** могли ** підтвердити це, дивлячись на метрики бази даних з того періоду. В подальшому, ми ** повинні ** додати попередження про використання пулу з’єднань вище 80%. “
Вибір правильних дій
Коли вам потрібно захистити технічне твердження, запитайте себе:
- Чи я виражаю справжню невизначеність щодо факту? → Використовуйте міг або може
- Чи я виражаю що я очікую, що станеться на основі дизайну або специфікації? → Використовуйте потрібен
- Чи я роблю рекомендацію? → Використовуйте should (або could для м’якших пропозицій)
- Чи я представляю опції? → Використовуйте може
Освоєння цих трьох модальних мов зробить вашу англійську більш точною, професійною і надійною. Метою не є виглядати невпевнено — це точно повідомити ваш фактичний рівень впевненості.
На практиці — поза навчальним планом
Як розробники, ми рідко маємо абсолютну впевненість. Ми постійно пропонуємо рішення, пропонуємо вдосконалення, і реагуємо на відгуки — усі, визнаючи потенційні обмеження або невизначеності. *Може *, *може *, і *потрібен * є вашими найкращими друзями, коли ви пересувається цю неоднозначність, особливо в технічних дискусіях. Це не про те, щоб стверджувати остаточні факти; це про те, щоб уважно оформити пропозиції, мінімізувати звинувачення і відкрити двері для спільного дослідження. Наприклад, замість того, щоб сказати « Ця можливість * виправить * ваду », більш професійним підходом буде сказати « Ця можливість * може * вирішити основну причину вади — рекомендується провести подальші дослідження ». Зауважте, що « може » негайно додає рівень обережності.
Ключова відмінність між цими модальними дієсловами полягає у їхніх нюансах. * Можливо * говорить про можливість і потенціал, часто передбачає бажання дослідити різні шляхи. « Ми * можемо * інтегрувати цю бібліотеку, якщо вона відповідатиме нашій існуючій архітектурі », передає відкритий розум без зобов’ язання щодо негайного реалізування. * Слід *, з іншого боку, передбачає рекомендацію або очікування, засновані на найкращих практиках або відомих результатах — але все ще залишає місце для відхилення. « База даних * повинна * бути оптимізованою для запитів з великим обсягом читання » говорить про розумний курс дій, але не виключає можливості потреби у альтернативних стратегіях, якщо продуктивність не відповідає очікуваним. * Можливо *, як найбільш неприйнятний, просто вказує на невизначеність і потребу у подальшому дослід
Часто, не-рідні носії борються з використанням цих модальних дієслів ефективно, тому що вони перекладають безпосередньо з їх рідної мови, де таке нюансове фразування може не існувати. Важливо розуміти, що в професійній англійській, надмірна впевненість або абсолютні висловлювання сприймаються негативно - сигналізуючи про відсутність обізнаності про потенційні ризики або альтернативні рішення. Замість того, щоб сказати « Цей код * є * правильним », розгляньте « Цей код * міг би бути * правильним, якби його ретельно перевірили ». Цей тонкий зсув перетворює потенційно упевнене твердження на виміряну пропозицію. Освоєння цих модальних дієслів значно покращить ваше спілкування, продемонструє як компетентність, так і ретельне роздумування.
Ось приклад використання jq для фільтрування даних, що ілюструє різноманітність формулювань, які ми обговорюємо:
jq '.[] | if .value > 10 then "High" else "Low" end' data.jsonЦя команда, коли використовується в повідомленні Slack або описі PR, може бути доповнена словами «Ми *може * потрібно змінити поріг для «Високого» на основі подальшого аналізу набору даних.» - набагато більш співпрацюючі, ніж просто заявляючи, що код автоматично категорізує дані як високі або низькі. Він визнає потенційні варіації і запрошує обговорення про критерії.