Глава 1. Как устроен технический английский

Введение

Картина знакомая. Код на английском пишется легко, переменные называются осмысленно, коммиты вроде тоже по-английски. Потом открываешь документацию к незнакомой библиотеке — и через два абзаца глаз соскальзывает. Дальше следует один и тот же вывод: «надо подтянуть английский». Человек записывается на общие курсы, полгода учит там названия овощей и Present Perfect Continuous, а документация как не читалась, так и не читается.

Я прошёл этот круг целиком и потерял на нём примерно год. Вывод оказался неожиданным: технический английский — не «английский, только сложнее». Это отдельный язык, узкий и предсказуемый, и учить его надо отдельно.

Разберём, из чего он собран и почему объективно проще бытового. Посчитаем частотное ядро — сколько слов реально нужно, чтобы читать документацию без словаря. Разложим регистры: язык коммита, чата и созвона — три разных языка, путать их дорого. Отдельно возьмём ложных друзей переводчика, потому что на них понимание ломается тише всего: ты даже не замечаешь, что понял наоборот.

В конце — стратегия чтения: блоками, с опорой на структуру и осознанной догадкой вместо остановок. Она переводит с уровня «я вроде понял» на «я точно знаю, что здесь написано».

Почему технический английский проще бытового

Сначала хорошая новость. Бытовой английский — самый сложный регистр языка, а вовсе не самый лёгкий. В нём живут идиомы (it's raining cats and dogs), фразовые глаголы, смысл которых не выводится из частей (put up with, get away with), сленг, региональные различия и юмор. Поэтому сериал без субтитров даётся тяжелее, чем документация к PostgreSQL. Интуиция подсказывает обратное. Интуиция врёт.

Технический английский устроен иначе, и почти во всём — в нашу пользу.

Ограниченный словарь. Автор документации не соревнуется в красноречии: ему нужно, чтобы читатель понял с первого раза. Поэтому одно понятие называется одним и тем же словом. Если функция returns значение, она будет return его во всей документации — никаких yields и gives back ради разнообразия. В художественном тексте синонимия — достоинство. В техническом — баг.

Простой синтаксис. Предложения короткие, порядок слов прямой: подлежащее, сказуемое, дополнение. Сложные времена почти не встречаются — большая часть документации написана в Present Simple и повелительном наклонении. Причастный оборот на три строки, инверсию и риторический вопрос стайлгайды прямо не рекомендуют, и авторы слушаются.

Почти нет идиом и сленга. Документацию читают люди со всего мира, для большинства английский не родной. Хорошие технические писатели выпалывают культурно нагруженные выражения намеренно: Google в своём открытом стайлгайде прямо советует обходиться без идиом и метафор — они плохо переводятся и сбивают неносителей.

Контекст всегда известен. Самое недооценённое преимущество. Читая роман, ты не знаешь, о чём будет следующий абзац. Читая раздел про кэширование, ты знаешь предметную область заранее: там будет про сроки жизни записей, вытеснение, инвалидацию. Половину смысла ты достраиваешь из профессиональных знаний, а не из английского. Поэтому джун и сеньор с одинаковым уровнем языка читают одну и ту же спеку с разной скоростью — и дело не в языке.

Посмотри на типичный фрагмент. Здесь нет ни одной сложной грамматической конструкции:

The `connect()` method opens a new connection to the database.
If the connection pool is full, the call blocks until a connection
becomes available or the timeout expires. On timeout, the method
raises `PoolTimeout`. The caller is responsible for closing the
connection.

Пять предложений, все в Present Simple, ни одной идиомы. Незнакомыми здесь могут оказаться разве что pool, expires и responsible. Вот этот уровень мы и набираем — не Шекспира.

Частотное ядро: сколько слов нужно на самом деле

Лингвисты давно посчитали: примерно две тысячи самых частотных слов английского покрывают около 80% любого нехудожественного текста. Для документации сверху ложится небольшой профессиональный слой — сотни три терминов и служебных слов, кочующих из документа в документ. Вместе они закрывают около девяноста процентов того, что встретится тебе в работе.

Девяносто звучит скромно: каждое десятое слово незнакомо. Но незнакомые слова лежат не ровным слоем. Это в основном имена собственные, названия технологий и узкие термины предметной области — те, что ты и так знаешь по-русски. Слово idempotent тебе, может, и не знакомо. Идемпотентность знакома отлично.

Вот служебный слой, который окупается первым: он несёт логику текста, а не предметную часть.

Четвёртая строка — самая опасная. Связки при беглом чтении проглатываются первыми, а цена высокая: пропустив unless или however, ты получишь смысл, обратный написанному, и будешь совершенно уверен, что понял правильно. Внутреннего детектора на такую ошибку нет. Предложение-то выглядит осмысленным.

Из пятой строки у меня есть личный шрам. В описании HTTP-клиента стояло the pool opens at most four connections per host, а я по диагонали запомнил «минимум четыре». Дальше был час недоумения, почему пятый параллельный запрос честно стоит в очереди, хотя лимиты «явно выше». Час — из-за двух слов, at most.

Пять регистров: где какой язык

Технический английский — не монолит. Контекстов как минимум пять, у каждого свои правила, и типичная ошибка — писать везде одинаково. Разберём по возрастанию формальности.

Чат (Slack, Discord, комментарии в задачах). Самый неформальный регистр: неполные предложения, пропущенное подлежащее, сокращения. Это нормальный рабочий язык, а не признак неграмотности:

deployed to staging, looks good so far
will check the logs in 10 min
any idea why the build is red?
nvm, found it — stale cache

Заглавных букв и полных предложений тут никто не ждёт. Хуже того, избыточная формальность читается странно. Мои первые месяцы в международной команде выглядели так: я писал в канал Dear colleagues, I would like to inform you that the deployment has been completed successfully — и получал в ответ nice 👍 и лёгкое недоумение. Через месяц тимлид мягко объяснил, что это Slack, а не письмо в министерство.

Коммит-сообщение. Жёсткий, почти телеграфный регистр. Заголовок — повелительное наклонение, без точки в конце, до пятидесяти символов. Тело — что и почему, обычными предложениями:

fix(auth): reject tokens issued before password change

Tokens signed before the user changed their password stayed valid
until expiry. We now store `password_changed_at` on the user and
compare it with the token `iat` claim during validation.

Closes #482

Заголовок отвечает на вопрос «что этот коммит сделает с кодовой базой», отсюда fix, а не fixed и не fixes. Формат type(scope): summary — конвенция Conventional Commits; её понимают автоматические сборщики changelog, так что аккуратность здесь ещё и экономит работу.

Описание пулл-реквеста. Средняя формальность, но обязательная структура: что изменилось, почему, как проверить. Здесь уже полные предложения и списки:

## What
Adds rate limiting to the public search endpoint (60 req/min per IP).

## Why
A single client generated 40% of all search traffic last week and
pushed p95 latency above our SLO.

## How to test
1. Run `make dev`.
2. Send 70 requests to `/api/search?q=test` in under a minute.
3. Requests 61+ should return 429 with a `Retry-After` header.

Документация. Самый формальный письменный регистр: полные предложения, никаких don't и can't (пишут do not, cannot), нейтральный тон, обращение к читателю через you или императив. Ему целиком посвящена глава 2.

Устная речь: созвон и интервью. Полные предложения не обязательны, зато нужны маркеры темпа и уточнения — let me rephrase, does that make sense?, sorry, could you repeat the last part?. И одна мысль, которую полезно принять сразу: на созвоне твою грамматику не оценивает никто. Оценивают, понятно ли ты объяснил.

Ложные друзья переводчика

Слова, которые в английском и русском выглядят почти одинаково, а значат разное. Коварство в том, что подозрений они не вызывают: в словарь ты не лезешь, ведь «и так понятно». А стоит это дорого — требование можно понять ровно наоборот и потом долго защищать свою версию на ревью.

Первые два встречаются каждый рабочий день, поэтому разберём их отдельно.

actual. В тестах и логах actual — то, что получилось, в противоположность expected, тому, что ожидалось. Никакой «актуальности»:

FAIL test_discount_applied
  expected: 90.00
  actual:   100.00

«Актуальный» в смысле «свежий, современный» — это current, up to date или relevant. А the actual version означает «версия, которая по факту стоит», а не «последняя»; последняя — the latest version. Разница вылезает ровно в тот момент, когда в тикете написано please check the actual version on staging, а ты идёшь обновляться до свежей.

eventually. «В итоге, спустя какое-то время, но обязательно». Сомнения в этом слове нет ни грамма. Классика распределённых систем — eventual consistency: не «возможная согласованность», а «согласованность, которая наступит». Разница принципиальная:

Writes are replicated asynchronously, so a read from a replica
may return stale data. The replica eventually catches up.

Автор здесь гарантирует, что реплика догонит. Хотел бы выразить неуверенность — написал бы possibly, perhaps или might. Знакомый бэкендер прочитал ту же фразу как «может, догонит, а может, и нет» и на всякий случай увёл все чтения на мастер. Нагрузка на мастер выросла втрое, реплики простаивали, и разбор занял два дня — из-за одного наречия.

Стратегия чтения: как читают те, кто читает быстро

Главная ошибка — читать технический текст как упражнение из учебника: слово за словом, с переводом каждого в голове. Медленно и, что обиднее, хуже по качеству: внимание съедает лексика, а на смысл его уже не остаётся. Работающая стратегия — четыре приёма.

1. Сначала структура, потом текст. Прежде чем читать абзац, пробегись по заголовкам, подписям к коду, выделенным словам, названиям параметров. Документация структурирована всегда. Половину смысла ты получаешь бесплатно, просто пройдясь по каркасу: открыв раздел Error handling, ты уже знаешь, что там будет про ошибки и их обработку.

2. Читай блоками, а не словами. Глаз должен захватывать смысловые группы: if the connection pool is full — один блок, «если пул соединений заполнен», а не четыре отдельных слова. Тренируется до неприличия просто — читай вслух с естественными паузами, паузы сами разложат текст на блоки.

3. Угадывай из контекста и иди дальше. Незнакомое слово — не повод тормозить. Дочитай предложение, потом следующее. В девяти случаях из десяти смысл проявится сам:

The scheduler will throttle outgoing requests when the error rate
exceeds 5%. Throttling is lifted automatically after two minutes
of successful responses.

Даже не зная throttle, из «когда доля ошибок превышает 5%» и «снимается после двух минут успешных ответов» видно: речь про какое-то ограничение потока. Этого хватит, чтобы читать дальше. Точное значение посмотришь потом — если вообще понадобится.

4. В словарь — только со второго раза. Слово встретилось повторно и всё ещё тёмное? Значит, оно частотное: лезь в словарь и выписывай. Встретилось однажды — скорее всего, больше и не встретится. Так в личный словарь попадает нужное, а не коллекция редкостей.

И маленькое, но важное: смотри значение в англо-английском словаре, а не перевод. Русский эквивалент всегда тащит за собой лишние коннотации. Commit в толковом словаре — «зафиксировать окончательно, взять на себя обязательство». Сразу понятно, почему это слово выбрали для git и почему та же семантика у commit a transaction.

Кейс из реального проекта: читаем абзац документации

Возьмём фрагмент документации к кэшу — такой абзац найдётся в описании любой библиотеки кэширования. Прочитай его целиком, ни на чём не останавливаясь. Именно целиком: желание застрять на первом непонятном слове здесь и надо перебороть.

Entries are evicted when the cache exceeds its configured maximum
size. The eviction policy is least-recently-used: the entry that
has not been read for the longest time is discarded first. Note
that eviction is not immediate. Entries are removed lazily on the
next write, so `size()` may temporarily report a value above the
limit. Unless you set `strict_size=True`, this behaviour is
expected and should not be treated as a leak.

Теперь по приёмам.

Структура. Пять предложений. Первые два задают правило, третье и четвёртое вводят исключение (Note that — маркер «дальше неочевидное»), пятое добавляет условие, при котором правило меняется.

Блоки. Первое предложение распадается надвое: entries are evicted — «записи вытесняются», when the cache exceeds its configured maximum size — «когда кэш превышает заданный максимальный размер». Пассив are evicted тут не случаен: автору неважно, кто вытесняет, важен факт.

Догадка из контекста. Если evict незнакомо — второе предложение объясняет его само: «запись, которую дольше всего не читали, отбрасывается первой». Слово расшифровано. Словарь не понадобился.

Ловушки. Их здесь три, и все три образцово-показательные.

• lazily — не «лениво» в бытовом смысле, а «отложенно, только когда понадобится». Это термин, у него точное значение.
• temporarily — «временно». Пропустив это слово, получишь вывод «size() врёт», хотя автор говорит «size() на короткое время показывает больше».
• Unless you set strict_size=True — самое опасное место. Unless = «если не». Описанное поведение действует, ПОКА ты не включил strict_size. Прочитай unless как if — и получишь абзац наоборот.

Последний пункт стоит мне одного испорченного вечера. Метрика показывала cache.size выше лимита, я был убеждён, что нашёл утечку, и полтора часа расставлял логи вокруг вытеснения. Утечки не было. В абзаце чёрным по белому стояло temporarily и unless, а я прочитал по диагонали.

Итог на русском: «Записи вытесняются, когда кэш перерастает заданный размер, по принципу давно не использованных. Вытеснение не мгновенное — оно случается при следующей записи, поэтому размер может ненадолго превышать лимит. Это ожидаемое поведение, если только ты не включил строгий режим».

Сколько слов пришлось смотреть в словаре? Ни одного. Всё вытащено из структуры, контекста и знаний о том, как вообще работают кэши.

Типичные ошибки

1. Переводить через русский вместо прямого понимания

Схема «английское предложение → русский перевод в голове → смысл» медленная, и промежуточный слой в ней протекает: русский эквивалент почти никогда не совпадает по объёму значения. Deprecated — не «устаревший» (устаревший — это obsolete, оно уже не работает), а «объявленный устаревшим: пока работает, но будет удалён». Разница между «можно не спешить» и «мигрируй сейчас», причём в пользу второго.

Лечится связыванием английского слова напрямую с образом. Читая the connection times out, представляй крутящийся спиннер и красное сообщение в консоли, а не проговаривай про себя «соединение истекает по тайм-ауту».

2. Читать со словарём на каждое незнакомое слово

The request is throttled → лезем в словарь
after the quota is exhausted → лезем в словарь
for the current billing period → лезем в словарь

Три остановки — и нить предложения потеряна. Дальше веселее: словарь выдаёт по пять значений на слово, а выбрать нужное без контекста невозможно, контекст же ты только что и потерял. Дочитывай до конца, возвращайся потом.

3. Бояться, что понял неправильно

Знакомая позиция: «я вроде понял, но вдруг там написано другое, перечитаю-ка ещё пять раз». Страх почти всегда напрасен, и снимается он не перечитыванием. Если текст описывает поведение кода — проверь понимание кодом. Документация не священное писание, она описывает то, что ты можешь воспроизвести за две минуты:

cache = LRUCache(max_size=2)
cache.set("a", 1)
cache.set("b", 2)
cache.set("c", 3)          # должно вытеснить "a"
print(cache.get("a"))      # None — понял правильно
print(cache.size())        # 3, а не 2 — про lazy тоже правильно

Двадцать строк эксперимента дают уверенность, которой не даст ни одно перечитывание.

4. Доверять машинному переводу технического текста

С бытовым текстом автоперевод справляется прекрасно, а на техническом ломается системно: он не отличает термин от обычного слова. Классика жанра:

"Commit the transaction"      → "Совершите преступление транзакции"
"The build is broken"         → "Здание сломано"
"Run the migration"           → "Запустите миграцию птиц"
"Drop the table"              → "Уроните стол"

Смешно, пока это заголовки. Опаснее, когда перевод выходит гладким, но подменяет модальность: SHOULD превращается в «должен», хотя это рекомендация, а не требование (глава 2 целиком про это). Такую подмену не видно глазом. Она всплывёт на код-ревью или, если не повезёт, в проде.

Разумный компромисс: переводчик как подсказка на трудном абзаце — можно, но сверяться с оригиналом обязательно. В первую очередь по связкам (unless, however, otherwise) и модальным глаголам.

Итог

Технический английский узкий, предсказуемый и заметно проще бытового: ограниченный словарь, прямой порядок слов, почти полное отсутствие идиом, всегда известный контекст. Две тысячи общеупотребительных слов плюс три сотни технических закрывают около девяноста процентов того, что тебе встретится. Остальное достраивается из предметных знаний, а они у тебя уже есть.

Регистры расходятся сильно: телеграфный коммит, структурированное описание пулл-реквеста, формальная документация, почти разговорный чат. Четыре набора правил, и умение переключаться между ними даёт больше, чем ещё пятьсот выученных слов. Ложные друзья переводчика — главный источник тихих ошибок, тех самых, где ты уверен, что понял. Actual, eventually и компанию запоминай осознанно.

Стратегия чтения — четыре пункта: сначала структура, потом блоки, догадка вместо остановки, словарь только для повторяющихся слов. И привычка проверять понимание кодом, когда речь о поведении системы.

Следующая глава — про грамматику. Не всю, а тот её кусок, который реально работает в документации: императив, Present Simple, пассив, условные конструкции и модальность RFC 2119, где путаница между should и must обходится дороже всего.