Английский на практике
Зачем это нужно
Прошлая глава научила читать сообщения об ошибках и дала стартовый словарь. Но между «узнаю́ слово на экране» и «пользуюсь английским в работе» — целая пропасть. На занятии наставник просит: «прочитай свой код вслух» — и уверенный в себе человек, который только что бегло разобрал Permission denied, вдруг мычит: он никогда не произносил val и println голосом и не знает, как это делается. А вечером тот же человек вставляет в переводчик по одному слову и получает бессмыслицу.
Эта глава — про два практических навыка, которые не даёт ни один словарь: говорить кодом (читать его вслух так, чтобы тебя понял и русский наставник, и англоязычное видео) и правильно пользоваться переводчиками (фразами, а не словами, с проверкой обратным переводом). Плюс игры для закрепления словаря из прошлой главы и честный маршрут «куда дальше», если английский хочется подтянуть всерьёз.
- Зачем это нужно
- Как читать код вслух
- Произношение 20 главных терминов
- Стратегия переводчиков
- Игры со словами
- Типичные ошибки
- Как звучат правила в документации
- Аббревиатуры, без которых не выжить в переписке
- Ещё пять ложных друзей переводчика
- Читаем настоящий issue и код-ревью
- Commit-сообщения и changelog по-английски
- Переведи и почини: трассировка стека
- Что говорят имена функций и переменных
- Куда дальше: маршрут прокачки
- Челлендж ⭐
- Что должен уметь
Для полного нуля: латиница и как читать буквы
Если английский в школе прошёл мимо и латинские буквы пока сливаются в кашу — вот минимум, с которого можно начать прямо здесь, не откладывая главу.
Английский алфавит — 26 букв. Как они называются (примерно, русскими буквами):
| Буквы | Названия |
|---|---|
| A B C D E F G | эй, би, си, ди, и, эф, джи |
| H I J K L M N | эйч, ай, джей, кей, эл, эм, эн |
| O P Q R S T U | оу, пи, кью, ар, эс, ти, ю |
| V W X Y Z | ви, дабл-ю, экс, уай, зед (или зи) |
Зачем знать названия букв: программисты постоянно диктуют друг другу имена и адреса по буквам — «переменная икс», «файл си-эс-ви», «зайди на джи-ай-ти-эйч-ю-би». Это называется spelling (спе́ллинг — произнесение по буквам).
Главные ловушки для русского глаза:
c— это «си», а не русская «с»; читается то как «к» (cat), то как «с» (cent).iиj— разные буквы: «ай» и «джей». В кодеi— любимое имя счётчика цикла.g— «джи», аj— «джей»; в словах g читается то как «г» (go), то как «дж» (git — исключение, читается «гит»).h— «эйч», в словах часто почти не слышится (hour — «а́уэр»).w— «дабл-ю», в словах даёт звук «у»:width— «уидс».y— «уай», в словах чаще звук «й» или «ай»:type— «тайп».
Читать целые слова по правилам сразу не получится — в английском исключений больше, чем правил. Рабочая стратегия новичка: запоминать звучание целых слов (в карточках прошлой главы у каждого слова есть кнопка озвучки — жми её и повторяй голосом), а буквы использовать для спеллинга. Этого достаточно, чтобы двигаться по главе дальше.
Как читать код вслух
Код — текст, который пишут глазами, а обсуждают голосом. «Посмотри на строку: вэл нейм и́квалз...» — так звучит любая планёрка, разбор и видеоурок. Чтобы участвовать, нужно знать, как принято произносить элементы кода. Хорошая новость: никто не читает вслух каждый символ — есть устоявшиеся привычки.
Ключевые слова читаются как английские слова: var — «вар», val — «вэл», fun — «фан», if — «иф», else — «элс», while — «уа́йл». Составные имена читают по частям: println — «принт-лайн» (print line — «печатай строку»), а не «принтлн». Знак = в объявлении читают «и́квалз» (equals — «равно»), а по-русски просто говорят «равно».
Скобки тоже имеют имена: ( ) — parentheses (пэрэ́нтэсиз, «круглые»), { } — curly braces (кёрли бре́йсиз, «фигурные»), [ ] — square brackets (сквэа брэ́кетс, «квадратные»). В русской речи так и говорят: «открой фигурную», «в квадратных скобках».
Разбери, как произносится вслух строка Kotlin-кода — нажми на каждую часть:
Вся строка целиком по-английски: «вэл нейм оф тайп стринг и́квалз оулег». По-русски на планёрке скажут смешанно: «вэл нейм типа стринг равно строке Олег» — и это нормально, так говорит вся индустрия.
Привычка читать код вслух — это ещё и способ найти ошибку: то, что глазами проскакивает, голосом спотыкается. Метод называется «резиновая уточка»: объясни код вслух хоть игрушке — и баг часто находится сам.
Произношение 20 главных терминов
Слова ниже ты будешь произносить каждый день — на занятиях, в вопросах наставнику, при просмотре видео. У половины из них есть «ловушка»: по буквам читается одно, а звучит совсем другое. Русское приближение в таблице — опора для старта; точное звучание слушай кнопкой озвучки в карточках прошлой главы или на YouGlish (ссылка в конце главы).
| Термин | Как звучит | Ловушка |
|---|---|---|
var | вар | — |
val | вэл | не «вал» |
fun | фан | не «фун» |
println | принт-лайн | не «принтлн» |
String | стринг | — |
Int | инт | — |
Boolean | бу́лиэн | не «боолеан» |
null | нал | не «нулл» |
true | тру | не «труе» |
false | фолс | не «фальсэ» |
height | хайт | не «хейт» и не «хейгхт» |
width | уидс | не «видтх» |
cache | кэш | не «кейч» и не «каше» |
queue | кью | не «квеуэ» — 4 буквы из 5 не звучат |
return | рэтёрн | ударение на второй слог |
while | уайл | не «вхиле» |
else | элс | не «элсэ» |
IDE | ай-ди-и́ | по буквам, не «идэ» |
git | гит | не «джит» — исключение из правила про g |
debug | диба́г | не «дэбуг» |
Произношение — не про «красивый акцент», а про то, чтобы тебя поняли. «Хейт» вместо «хайт» (height) — это буквально другое слово (hate — «ненависть»), и слушатель честно зависнет.
Стратегия переводчиков
Переводчик — легальный и правильный инструмент программиста. Неправильно им пользоваться только одним способом: переводить по одному слову. Слово вне фразы — многозначно: переводчик, получив «журнал», честно предложит magazine (глянцевый журнал), хотя ты имел в виду log (журнал событий). Дай ему целую фразу — и по контексту он выберет верное значение.
Три правила, которые превращают переводчик из генератора чуши в рабочий инструмент:
- Переводи фразами, а не словами. Не «журнал», а «посмотри журнал ошибок сервера» — тогда в переводе появится server error log, а не magazine.
- Проверяй обратным переводом. Получил английскую фразу — прогони её обратно на русский, лучше в другом переводчике. Смысл уцелел — фраза годная. Получилось «собрание упало» вместо «сборка упала» — формулируй заново.
- Термины сверяй по коду, а не по словарю. Если переводчик предлагает слово, которого ты ни разу не видел в ошибках, документации или меню — скорее всего, это «человеческий» перевод, а не термин. Правильный перевод «ветки» в git — branch, потому что так называется команда, и никакой словарь это не переспорит.
- Переводи фразами, а не отдельными словами — у слова без контекста десяток значений.
- Проверяй обратным переводом: переведи результат назад и сравни смысл с оригиналом.
- Термины из словаря главы запоминай по-английски — в коде и ошибках они будут без перевода.
Каким переводчиком пользоваться — вопрос вкуса: DeepL силён в живых фразах, Google Translate — в охвате языков и интеграции с поиском, Яндекс Переводчик лучше других понимает русские реалии. Рабочая схема — основной + второй для обратной проверки.
Профессиональные переводчики пользуются тем же приёмом «обратного перевода» (back translation) для контроля качества — например, при переводе медицинских инструкций: текст переводят обратно на язык оригинала другим человеком и сверяют смыслы.
Игры со словами
Словарь из прошлой главы пора закрепить в другом направлении. Карточки учат узнавать английское слово; игры ниже заставляют вспоминать его сам — это сложнее и полезнее: именно так слово становится активным, готовым к использованию в речи и поиске.
Найди пары «слово — перевод». Открывай карточки по две: совпали — остаются открытыми. Следи за временем и числом ходов — а потом попробуй улучшить свой результат:
Теперь обратный квиз — направление рус → англ, противоположное карточкам. Дано русское слово, выбери английское:
И собери целые английские фразы — в прошлой главе ты собирал русские переводы, теперь наоборот. «Создай новую ветку»:
«Запусти тесты ещё раз»:
Типичные ошибки
В прошлой главе типичные ошибки были про терминал. Здесь — про сам английский: четыре привычки, которые выдают новичка и мешают общению. У каждой — как звучит, почему так выходит и как починить.
1. Читать слово по буквам: «хейгхт», «вхиле»
Как звучит: height превращается в «хейгхт», while — в «вхиле», queue — в «квеуэ».
Почему так выходит: в русском как пишется, так и читается — привычка тянется в английский, где написание и звучание разошлись столетия назад.
Как починить: запоминать звучание целого слова, а не правила чтения: таблица 20 терминов выше + кнопка озвучки в карточках + YouGlish для любого нового слова. Услышал — повторил голосом три раза.
2. Переводить дословно по одному слову
Как выглядит: «сборка упала» переведено по словам как assembly fell — и собеседник представляет упавший митинг или деталь конструктора.
Почему так выходит: кажется, что перевод — это замена слов. На деле переводится смысл фразы: «сборка упала» по-английски — the build failed.
Как починить: правило из раздела про переводчики — фразами, не словами, с обратной проверкой. Устойчивые пары запоминать целиком: build failed, tests passed, merge conflict.
3. Доверять переводу термина без проверки
Как выглядит: переводчик предложил для «ветки» слово bough (ветвь дерева, поэтичное) — и запрос «how to create bough in git» находит ботанику.
Почему так выходит: у общего языка и у индустрии разные словари. Переводчик по умолчанию отвечает общим.
Как починить: термины сверять по реальным текстам — сообщениям ошибок, командам, документации. Если слово не встречается в выводе git или в меню IDE — это не термин.
4. Молчать из-за стеснения за акцент
Как выглядит: человек знает ответ, но не задаёт вопрос под англоязычным видео и не читает код вслух на занятии — «у меня произношение плохое».
Почему так выходит: школьная привычка, что за ошибку в произношении снижают оценку.
Как починить: вспомнить цель — не «звучать как диктор BBC», а быть понятым. Индустрия глобальна, в ней говорят с индийским, китайским, немецким, русским акцентом — и прекрасно понимают друг друга. «Пуш зе бранч» — валидная рабочая фраза.
Как звучат правила в документации
Русский язык различает совет и требование интонацией и словами вроде «нужно», «неплохо бы», «обязательно». В английской технической документации для этого используют строгий, стандартизированный набор модальных глаголов — настолько строгий, что авторы интернет-стандартов даже формализовали его в документе RFC 2119, и с тех пор ему следуют README, спецификации и правила контрибьютинга по всему миру.
| Слово в доке | Что значит | Можно ли нарушить |
|---|---|---|
must / required | обязательно, без вариантов | нет |
must not | категорически запрещено | нет |
should / recommended | сильная рекомендация | да, но нужна веская причина |
should not | не рекомендуется | да, но нужна веская причина |
may / optional | на твоё усмотрение | вопроса «можно ли» не стоит — это и так необязательно |
Перепутать must и should в разговоре с наставником или в чтении чужого README — не мелочь: «тесты обязательны» и «тесты неплохо бы» — это разные требования к твоему коду.
Второе, что бросается в глаза в любой документации, — она почти никогда не обращается к тебе словом «ты» или «you» перед командой. Вместо «you should run npm install» пишут просто «Run npm install» — глагол сразу, без подлежащего. Это повелительное наклонение (imperative mood), стандартная форма для инструкций в английском: подлежащее «you» подразумевается, но опускается. Это не грубость — это принятый стиль всей технической литературы, от рецептов до README.
Слово please перед командой («Please run the tests before opening a PR») ничего не меняет в обязательности — это по-прежнему should или must, просто вежливая обёртка. Отсутствие please в доке — тоже не грубость, а просто более короткий, деловой стиль.
Прочитай фрагмент из вымышленного файла CONTRIBUTING.md — именно такой текст встретит тебя в любом настоящем open-source проекте:
## Before you open a pull request
You must run the full test suite locally before pushing.
Please ensure all commits follow the Conventional Commits format.
New features should include unit tests, but documentation-only
changes may skip this step.
Do not merge directly into main — always open a pull request
and wait for at least one approval.
Аббревиатуры, без которых не выжить в переписке
Переписка в PR, issue и рабочих чатах полна сокращений — их не объясняют, потому что вся индустрия и так их знает. Не узнать их — значит потерять половину смысла короткого комментария коллеги.
| Сокращение | Расшифровка | Что значит на практике |
|---|---|---|
| WIP | work in progress | «работа не закончена» — часто в названии PR: WIP: add login form |
| LGTM | looks good to me | «мне нравится, одобряю» — так пишут при код-ревью вместо «approved» |
| TBD | to be determined | «пока не решено» — вопрос открыт, ответ появится позже |
| RFC | request for comments | «прошу обсудить» — документ или PR специально выложены для обсуждения, а не для немедленного слияния |
| PR / MR | pull request / merge request | запрос на слияние ветки — тема всей главы про git впереди |
| FYI | for your information | «для сведения» — сообщают не как задачу, а как факт |
| IMO / IMHO | in my (humble) opinion | «по-моему», «на мой (скромный) взгляд» — смягчает личное мнение |
| N/A | not applicable | «неприменимо» — пункт не относится к делу |
| TODO / FIXME | to do / fix me | пометка в коде: «здесь ещё нужно доделать» / «здесь баг, почини» |
| ASAP | as soon as possible | «как можно скорее» |
| POC | proof of concept | черновой прототип, чтобы проверить, работает ли идея вообще |
| MVP | minimum viable product | минимальная работающая версия продукта |
| e.g. / i.e. | for example / that is | «например» / «то есть» — латинские сокращения, но обычные в английском тексте |
| w/ / w/o | with / without | «с» / «без» — экономия места в коротких заметках |
e.g. и i.e. путают чаще всего: e.g. (exempli gratia) вводит один пример из многих возможных — «сохраняй файлы часто, e.g. каждые 10 минут»; i.e. (id est) уточняет и переформулирует то же самое — «сохраняй файл после каждого изменения, i.e. буквально после каждой правки».
Прочитай вымышленную переписку под настоящим PR — она собрана из реальных, часто встречающихся формулировок:
@lena_dev commented:
LGTM overall, just one nit — can you rename `tmp` to something
more descriptive? Also this PR is still WIP, right? I see a TODO
left in utils.py. Let's mark it as draft until that's resolved.
@oleg_k replied:
Good catch, fixing now. FYI the TODO is intentional — it's TBD
until we get product's answer on the RFC. Will ping you ASAP
once it's ready for a proper review.
Ещё пять ложных друзей переводчика
В прошлой главе уже встречались слова, которые звучат по-русски знакомо, но означают совсем не то, что кажется (actual, character, data, complex). Вот ещё несколько — из тех, что чаще всего подводят в рабочей переписке и документации:
| Слово | Кажется, что значит | На самом деле значит | Пример |
|---|---|---|---|
sympathetic | «симпатичный» | сочувствующий, понимающий | a sympathetic reviewer — ревьюер, который входит в положение, а не «симпатичный ревьюер» |
magazine | «магазин» | журнал (глянцевый, печатный) | для магазина нужно слово shop или store |
fabric | «фабрика» | ткань, материал | для фабрики нужно слово factory или plant |
accurate | «аккуратный» | точный, безошибочный | an accurate estimate — точная оценка, а не «аккуратная» |
replica | «реплика» (в диалоге) | точная копия предмета | для реплики в диалоге нужно line или remark |
prospect | «проспект» (улица/буклет) | перспектива; потенциальный клиент | a promising prospect — многообещающая перспектива |
Ложные друзья опасны именно потому, что не выглядят как ошибка: предложение звучит гладко, а смысл — не тот. Если слово легло в фразу «слишком удобно» и никогда раньше в текстах индустрии не встречалось — самое время свериться, а не доверять первому впечатлению.
Читаем настоящий issue и код-ревью
Issue (заявка о проблеме) и комментарии код-ревью пишут по устойчивым, узнаваемым шаблонам — почти как заявление в поддержку. Зная шаблон, читаешь такой текст в разы быстрее, потому что не гадаешь, что за чем идёт.
Вот вымышленный, но типичный отчёт об ошибке — именно такую структуру задаёт форма issue почти в любом open-source репозитории на GitHub:
### Bug report
**Describe the bug**
The login button becomes unresponsive after the third failed attempt.
**To Reproduce**
1. Open the login page
2. Enter wrong credentials three times in a row
3. Observe that the button no longer responds to clicks
**Expected behavior**
The button should stay clickable and show a rate-limit message instead.
**Actual behavior**
The button silently stops working with no error message.
**Environment**
- Browser: Chrome 118
- OS: Windows 11
Четыре подзаголовка — не случайный порядок, а стандарт: Describe the bug (в чём проблема, коротко), To Reproduce (пошаговый рецепт «как повторить баг» — без него никто не сможет помочь), Expected behavior (как должно быть) и Actual behavior (как есть на самом деле). Разница между expected и actual — и есть сама суть бага.
Дальше — комментарии код-ревью на этот же (гипотетический) фикс. У них тоже есть свой узнаваемый словарь серьёзности:
Nit: consider extracting this into a separate function.
Blocking: this will break existing sessions — please add a
migration step before merging.
Approved, nice work! ✅
Nit (от nitpick — «придирка по мелочи») значит «необязательно, но неплохо бы поправить». Blocking — противоположность: «пока это не исправлено, PR не сливается». Разница этих двух слов решает, нужно ли останавливать работу прямо сейчас.
Commit-сообщения и changelog по-английски
У сообщений коммитов и записей в changelog (файле-журнале изменений проекта) тоже есть устоявшийся формат — Conventional Commits и Keep a Changelog, два неофициальных, но массово принятых стандарта. Зная их словарь, ты за секунду поймёшь, что изменилось в чужом проекте, даже не открывая diff.
Формат commit-сообщения: тип(область): краткое описание. Основные типы: feat (новая функциональность), fix (исправление бага), docs (только документация), refactor (код переписан, поведение не изменилось), test (добавлены/поправлены тесты), chore (рутина: обновление зависимостей и подобное). Если изменение ломает обратную совместимость, в конце сообщения добавляют отдельный абзац BREAKING CHANGE: с пояснением.
feat(auth): add password reset flow
fix(api): correctly handle empty response body
refactor(parser): extract token validation into a helper
BREAKING CHANGE: `login()` no longer accepts a callback;
use the returned Promise instead.
Это напрямую связано с версией проекта: семантическое версионирование (semantic versioning, semver) кодирует номер версии как MAJOR.MINOR.PATCH — например 2.3.0. fix увеличивает PATCH (последнее число), feat увеличивает MINOR (среднее), а BREAKING CHANGE увеличивает MAJOR (первое) — потому что старый код, написанный под прежнюю версию, может перестать работать.
Записи в changelog при этом группируют по типу изменения не commit-словами, а отдельным набором заголовков:
## [2.3.0] - 2026-08-14
### Added
- Dark mode toggle in settings.
### Fixed
- Crash when opening an empty project.
### Deprecated
- `oldExportFormat` will be removed in 3.0.0.
Added — что появилось нового, Fixed — что починили, Changed — что изменилось в существующем поведении, Deprecated — что ещё работает, но скоро исчезнет (использовать уже не стоит), Removed — что удалено окончательно, Security — исправления безопасности. Deprecated — самое коварное слово для новичка: код с ним пока работает, но это уже официальное предупреждение «переезжай на замену заранее».
Переведи и почини: трассировка стека
Трассировка стека (stack trace) — самый пугающий с виду, но и самый информативный текст, который печатает программа при падении. Пугает объём; на деле там всего два вида информации: что именно пошло не так (первая строка) и где именно — путь вызовов сверху вниз, от места ошибки к месту запуска.
Exception in thread "main" java.lang.NullPointerException:
Cannot invoke "String.length()" because "name" is null
at com.example.app.Greeter.greet(Greeter.kt:12)
at com.example.app.MainKt.main(Main.kt:5)
Переведи и ответь на вопросы — сначала попробуй сам, решение спрятано ниже:
- Как переводится и что означает первая строка после слова
Exception? - В какой строке файла случилась сама ошибка — по самой верхней строчке
at ...? - Что означает
name is nullпростыми словами — какого значения не хватало?
Решение (сначала попробуй сам)
NullPointerException: Cannot invoke "String.length()" because "name" is null— «исключение из-за пустой ссылки: невозможно вызвать String.length(), потому что name равно null». То есть код попытался спросить длину строки у переменнойname, а там оказалось «ничего» (null), а не строка.- Самая верхняя строка
at ...показывает место, где произошёл сбой:Greeter.kt:12— файлGreeter.kt, строка 12, внутри функцииgreet. Строки ниже — это цепочка вызовов, которая туда привела (mainвызвалgreet). - Переменной
nameне присвоили значение (или туда явно записалиnull) до того, как код попытался вызвать у неё метод.length(). Чинить нужно именно это место — проверить, откуда берётсяname, и добавить проверку наnullили гарантировать, что значение туда всегда попадает.
Правило чтения любой трассировки одинаковое на любом языке программирования: читай первую строку — она называет проблему; ищи самую верхнюю at ... из своего собственного кода (не из системных библиотек) — она называет место починки.
Что говорят имена функций и переменных
Опытный разработчик придумывает английские имена не случайно — по имени функции сразу видно, что она делает и что возвращает, ещё до чтения кода внутри. Это не эстетика, а рабочий инструмент: правильно названная функция экономит время каждому, кто её потом читает, включая тебя самого через месяц.
Несколько устойчивых префиксов, которые встречаются в любом коде на любом языке программирования:
| Префикс | Что обычно означает | Пример | Что возвращает или делает |
|---|---|---|---|
get... | получить значение | getUserById(id) | возвращает пользователя по id |
set... | задать значение | setLoading(true) | меняет состояние на переданное |
is... | вопрос да/нет о состоянии | isValidEmail(text) | возвращает true или false |
has... | вопрос да/нет о наличии | hasPermission(user) | возвращает true или false |
on... | обработчик события | onSubmit(), onClick() | вызывается, когда событие произошло |
calculate... / compute... | что-то посчитать | calculateTotalPrice() | возвращает число — результат вычисления |
create... / build... | собрать что-то новое | createUser(name) | возвращает новый объект |
Сам порядок слов в имени тоже несёт смысл: связка «глагол + существительное» (calculateTotal, sendEmail, deleteFile) читается как команда «сделай что-то» — такие функции обычно совершают действие. Имена без глагола, часто с прилагательным впереди (totalPrice, isActive, currentUser) — это данные, а не действия: переменная, которая просто что-то хранит.
Увидев isValidEmail или hasPermission, можно почти не глядя в код угадать: функция вернёт true или false — потому что английский вопрос «is it valid?» или «does it have...?» подразумевает ответ да/нет. Эта привычка называть булевы функции вопросом — не случайность конкретного проекта, а общее соглашение всей индустрии.
Куда дальше: маршрут прокачки
Глава дала старт, но язык растёт от регулярности: 15 минут в день сильнее трёх часов раз в месяц. Проверенные инструменты — на выбор, по одному на каждую задачу:
- Видео и материалы сообщества — ниже — ролики по теме и ссылки от студентов и преподавателей смотри в самом низу страницы.
Рабочая связка на первый месяц: Duolingo для ежедневной привычки + слова платформы в Anki + YouGlish, когда сомневаешься в произношении.
Челлендж ⭐
Ступень 1. Прочитай вслух — голосом, не глазами — этот фрагмент и запиши русскими буквами, как ты его произнёс:
val width = 10
if (width > 5) println("big")
Сверься с разделом «Как читать код вслух»: val и width из таблицы произношения, > читается «грейтэ зэн» (greater than — «больше чем») или по-русски «больше».
Ступень 2 ⭐. Возьми фразу «мой коммит сломал сборку, откатываю изменения» и переведи её на английский по полной схеме из главы: через переводчик целой фразой → обратный перевод вторым переводчиком → сверка терминов по словарю git из прошлой главы. Запиши финальную английскую фразу и одно слово, которое пришлось поправить после сверки терминов.
Решение (сначала попробуй сам)
Ступень 1, примерная запись: «вэл уидс и́квалз тэн. иф уидс грейтэ зэн файв — принт-лайн биг». Допустимо и смешанно по-русски: «вэл уидс равно десять; если уидс больше пяти — принт-лайн биг».
Ступень 2 ⭐, один из рабочих вариантов: my commit broke the build, reverting the changes. Слово, которое чаще всего приходится поправлять после сверки, — «откатываю»: общий переводчик может предложить rolling back (в git-контексте тоже встречается), но точный git-термин для отмены коммита — revert, потому что так называется сама команда git revert.
Сводная проверка по всей главе: 6 вопросов, 5:00 на всё, без подсказок по ходу. Вопросы показываются по одному, ответ изменить нельзя. Если время выйдет — экзамен завершится с тем, что успел ответить. Пересдавать можно сколько угодно раз.
Что должен уметь
- Прочитать вслух простую строку Kotlin-кода так, чтобы её узнал другой программист: «вэл нейм оф тайп стринг и́квалз...», со скобками по именам (круглые/фигурные/квадратные).
- Произносить узнаваемо 20 главных терминов из таблицы — включая ловушки height («хайт»), queue («кью»), cache («кэш»), git («гит»).
- Пользоваться переводчиком по стратегии: целыми фразами, с проверкой обратным переводом вторым движком, со сверкой терминов по реальному коду и документации.
- Вспоминать английские слова стартового словаря по русскому переводу (обратное направление), а не только узнавать их на экране.
- Назвать свой маршрут ежедневной практики: чем заниматься (Duolingo/учебник), где повторять слова (Anki с экспортом слов платформы), где проверять произношение (YouGlish).
Комментарии
Обсуждение живёт в GitHub Discussions и грузится с чужого домена — поэтому только по нажатию.