Повний посібник з англійської для Backend-розробників

Англійська мова для вивчення мови

Розробка бекенду є однією з найбільш міжнародно поширених дисциплін в інженерії програмного забезпечення. Незалежно від того, працюєте ви в компанії з виробництва продуктів, розподіленому стартапі або як підрядник для клієнтів у різних часових поясах, ваш код не існує в ізоляції — він живе всередині документації, описів запитів на витягування, гілок Slack, проблем GitHub, записів рішень архітектури і відповідей Stack Overflow. Всі вони написані англійською мовою.

Розгляньте, що типовий інженер-сервер насправді створює за тиждень: запит на витяг з описом, який пояснює мотивацію зміни, вбудовані коментарі коду, які документують неочевидну логіку, відповіді на відгуки про перегляд коду від колег у різних країнах, повідомлення, яке пояснює, чому завдання було заблоковано, квиток Jira, який описує помилку з кроками відтворення, і, можливо, технічний документ проекту, який описує запропонований підхід до нової можливості. Кожен з цих артефактів залежить від чіткої, точної, професійної англійської.

Проблема в тому, що більшість ресурсів для вивчення англійської не вчать такої мови. Вони навчають вас, як замовити номер у готелі або написати офіційний лист, але не вчать вас розрізняти « це слід переформатувати » і « ні: розгляньте можливість вилучення цього до допоміжного методу ». Вони не вчать вас, як сказати « Я б сказав, що тут компроміс на користь послідовності переважає над доступністю » у обговоренні проектування системи, або як написати « Повертає 404, якщо ресурсу не існує; повертає 422, якщо тіло запиту не пройшло перевірку схеми » у посиланні на API.

Цей підручник містить інформацію про конкретні англійські слова, які вам потрібні як розробнику сервера — не загальну бізнес- англійську, а точну лексику, шаблони фраз і норми спілкування під час роботи з сервером. Прочитайте кожен розділ, вправляйтеся з пов’ язаними вправами, і ви швидко помітите різницю у вашому щоденному письмовому і усному спілкуванні.

Розділ 1: REST API & Документація англійською

Писання документації API є однією з найбільш конкретних і високоцінних навичок англійської мови, яку може мати розробник сервера. Добрі документи API читають десятки або сотні інших інженерів. Погано написана документація сповільнює інтеграцію, створює квитки на підтримку і шкодить репутації вашої команди. Мова документації API є дуже специфічною і відповідає встановленим конвенціям.

Назва методу HTTP і опис кінцевої точки

При описі того, що робить кінцева точка, зазвичай використовується імперативний настрій — та ж форма, яку ви використовуєте для надання команди. Ви ввели « Створює нового користувача », а не « Ця кінцева точка створює нового користувача » або « Створення нового користувача ». Тема має бути самою кінцевою точкою. Це стосується резюме OpenAPI/Swagger, таблиць README і будь-якого списку кінцевих точок.

Стандартний словник дієслів HTTP є точним: кінцеві точки GET — це « отримати », « набрати » або « повернути » ресурси; кінцеві точки POST — це « створити », « надіслати » або « запустити »; кінцеві точки PUT — це « замінити » або « оновити » (повний ресурс); кінцеві точки PATCH — це « частково оновити » або « змінити »; кінцеві точки DELETE — це « вилучити » або « вилучити ». Використання неправильного дієслова не тільки не буде точним, але й повідомить іншим розробникам про те, що ви не знайомі з семантикою REST.

Описи параметрів шляху повинні використовувати послідовні формулювання: « Унікальний ідентифікатор користувача », а не « ідентифікатор користувача » або « ідентифікатор користувача ». Описи параметрів запиту повинні вказувати тип, коректний діапазон і типове значення: « Максимальна кількість результатів, які буде повернено. Має бути між 1 і 100. Типовий рівень 20»

Документація та відповіді на запити

Документація тіл запитів означає опис цілі, типу і обмежень кожного поля. Сильні описи полів є активними і точним: « Адреса електронної пошти нового користувача. Має бути коректною адресою RFC 5322. Використовується для надсилання перевірки облікового запису. » Недосконалі описи повторюють назву поля: « Поле електронної пошти ». Ніколи не повторюйте назву ключа як опис.

Документація відповіді відповідає тим самим правилам. Документувати як успішний випадок, так і всі випадки помилок. Для кожного з кодів стану HTTP, які ви повертаєте, напишіть чіткий опис: « 200 OK — Повертає оновлений ресурс у тілі відповіді. » « 404 Не знайдено — Повертається, якщо у базі даних не існує ресурсу з вказаним ідентифікатором. » « 422 Необроблена сутність — Повертається, якщо тіло запиту є синтаксично коректним JSON, але не пройшло перевірку за бізнес- правилами; тіло відповіді містить список помилок перевірки. »

Самі повідомлення про помилки — рядки, які повертаються у тілі відповідей на помилки — слід писати простою англійською мовою, з точки зору користувача: « Поле « email » є обов’ язковим. », а не « відсутнє поле адреси » або « Перевірка поля не вдалася для електронної пошти ». Повідомлення про помилки повинні вказати користувачеві API, що сталося не так і, якщо це можливо, що робити з цим.

OpenAPI Field Descriptions and Changelog Language (англійською)

Описи OpenAPI використовують послідовний регістр: формальне, але коротке, без першої особи, без скорочень. Під час документування властивостей схеми завжди включайте її призначення, а не лише тип. Під час документування нової версії API, мова changelog слідує шаблонам: « Застаріло поле user_ name на користь username. » « Додано параметр cursor, щоб увімкнути сторінкування за допомогою курсора. » « Зміна, що викликає занепокоєння: обгортку даних було вилучено з усіх відповідей списку. »

Розділ 2: Перегляд коду комунікації

Перегляд коду є однією з найбільш лінгвістично тонких форм спілкування на робочому місці. Ви оцінюєте роботу когось іншого і надсилаєте зворотній зв’ язок, який може бути різноманітним: від незначної пропозиції до блокування злиття можливості. Зрозуміти правильний регістр — бути чесним, не будучи жорстким, бути прямим, не будучи грубим — це справжнє професійне вміння, яке рідні носії англійської також повинні вивчити.

Блокування проти Не блокує відгук

Найважливішим відмінним елементом мови перегляду коду є те, чи є ваш коментар блокуючим (тобто, PR не можна об’ єднати, поки не буде вирішено цю проблему) або не блокуючим (тобто, ви ділитеся думкою, але автор може вирішити, чи поділитися нею). Різні команди мають різні звичаї, але спільні шаблони включають префіксування неблокуючих коментарів з « nit: » (короткий для « nitpick »), « optional: » або « suggestion: », щоб вказати, що автор може не погоджуватися. Блокування зворотного зв'язку зазвичай оформляється як вимога: «Це має обробляти нульовий регістр, перш ніж ми зможемо об'єднати.» або «Будь ласка, додайте тести для шляху помилки.»

Префікс « nit: » широко використовується в командах інженерів, які розмовляють англійською мовою: « Nit: Я б перейменував цю змінну на userCount для зручності, але це залежить від вас ». Цей префікс означає, що ви помітили щось незначне, у вас є певні переваги, але ви не блокуєте доступ до цієї змінної. Використання « nit: » значно спрощує сортування ваших коментарів перегляду коду і показує професійну оцінку того, що насправді важливо.

Запитувати зміни ввічливо, але чітко

Якщо вам потрібно подати запит на зміну, англійська мова пропонує вам широкий спектр прямоти. « Ви повинні виправити це » — це прямий запит, але він може бути неприємним. « Це призведе до пошкодження програми, якщо список буде порожнім » — це фактична інформація, яка свідчить про необхідність виправлення. « Чи можемо ми додати захисний пункт для порожнього списку?» — це форма питання, яка пом’ якшує запит. « Я вважаю, що цей запит потребує захисного пункту для порожнього списку — що ви на це скажете? » — це запрошення до обговорення. Всі чотири з них використовуються у справжніх переглядах коду; правильний вибір залежить від тяжкості проблеми і ваших стосунків з автором.

Корисні шаблони для запитів змін включають: «Це призведе до X, коли станеться Y.» / «Я переживаю, що цей підхід буде…» / «Ми повинні розглянути можливість розв'язання ситуації, де…» / «Чи є причина, чому ми не використовуємо X тут?» / «Це здається, що це може призвести до умови перегони — раді обговорити, якщо я щось пропустив»

Використовується для передачі і прийому мовлення

«LGTM» (Looks Good To Me) — найпоширеніший PR-схвалення скорочення в англомовних командах. Також ви побачите « Затверджено з мітками » (затверджено, але є невеликі необов’ язкові пропозиції), « Заштамповано » (неформальний варіант затверджено) і « Гумовий штамп » (затверджено без ретельного перегляду, часто з самокритикою: « заштамповано, оскільки логіка проста »).

Хороший коментар затвердження додає цінності, крім простого клацання на кнопку Затвердити: «LGTM — чудове рішення проблеми запиту N+1. Підхід до завантаження є чистим." або "Схвалено. Залилося декілька нот, але вони не обов’ язкові — гарна робота над тестовим покриттям. » Якщо ви погоджуєтесь з коментарем іншої людини, ви можете відповісти « +1 на пропозицію щодо X » або « Згоден з цим — назва трохи заплутана. »

Розділ 3: База даних і мова SQL

Робота з базою даних створює особливий англійський словник, який вам знадобиться як для написання документації, так і для розмов під час зустрічей з архітекторами і проектувальниками. Незалежно від того, чи ви пропонуєте розробку схеми, обговорюєте оптимізацію запиту або пояснюєте стратегію індексування, точність вашої мови безпосередньо впливає на те, чи зрозуміють ваші колеги ваші аргументи.

Оптимізація запитів

Під час обговорення швидкості запиту ви говорите про запити, які є « повільними », « дорогими » або « не використовують індекс ». Ви « профільуєте » або « пояснюєте » запит, щоб зрозуміти його план виконання. Запит « виконує всю таблицю », якщо він не може використовувати індекс, і ви « переписуєте » або « оптимізуєте » його. Ви згадали про « N+1 запиту » (поширена проблема, коли програма виконує один запит для отримання списку, а потім один запит на кожен елемент для отримання пов’ язаних даних), « планування запиту », « послідовне сканування проти сканування індексів » і « час виконання запиту »

Практичні фрази: «Профіль показує, що цей запит займає 800 мс — виглядає, що він робить повне сканування таблиці на таблиці замовлень.» / «Ми могли б додати складний індекс на (user_id, created_at) для покриття цього запиту.» / «Я помітив деякі N+1 в ORM — я додав охоче завантаження, щоб розв'язати їх.»

Схема дизайну словника

Розробка схеми включає обговорення « нормалізації » (вилучення дублікатів даних) і « денормалізації » (навмисне дублювання даних для збільшення швидкодії читання), « зовнішніх ключів », « обмежень », « стовпчиків, які можна або не можна скасувати », « каскадних вилучень » і « міграцій схеми ». Ви « додаєте », « викидаєте », « змінюєте » або « перейменовуєте » стовпчики і таблиці. Міграції є «зворотно сумісними» або «розривними» змінами.

Індексація стратегії мови

У дискусіях щодо індексів використовуються такі фрази, як « частковий індекс », « індекс покриття », « складний індекс », « унікальні обмеження » і « вибірковість індексу ». Ви описуєте стовпчик як маючий « високу » або « низьку » кардинальність. Ви кажете « додавання індексу на X прискорить читання, але уповільнить запис » — ця формула компромісу є центральною у дискусіях щодо швидкості бази даних.

Розділ 4: Дискусія про системний дизайн англійською

Дискусії щодо проектування системи — чи то на зустрічах з архітектурою, документах RFC, чи сесіях перегляду проекту — вимагають спеціалізованого словника для вираження компромісів, обмежень масштабованості і технічного вибору. Це також одна з основних компетенцій, що тестуються в старших інтерв'ю з інженерами, що робить подвійне значення правильної мови.

Словник-довідник

Вміння вільно обговорювати компроміси є знаком інженерного стажу. Ключові фрази: «Компроміс тут між X і Y.» / «Ми отримуємо X за рахунок Y.» / «Цей підхід оптимізує для швидкості читання, але вводить затримку запису.» / «Ніякого безкоштовного обіду — ми маємо вибрати, який режим невдачі ми віддаємо перевагу.» / «Я б стверджував, що компроміс на користь послідовності над доступністю в цьому випадку використання, враховуючи, що наші користувачі роблять фінансові операції.»

Якщо ви надаєте декілька варіантів, скористайтеся « Варіант А дає нам X, але вимагає Y. Варіант B уникає Y, але жертвує X. Моя рекомендація — варіант B, тому що…» Ця структура — варіант, компроміс, рекомендація з обґрунтуванням — є стандартним форматом для архітектурних записів рішень (ADR) і проектних документів.

Розмовна мова

У дискусіях щодо масштабованості використовується точний словник: « горизонтальне масштабування » (додання більше серверів), « вертикальне масштабування » (збільшення потужності сервера), « вузьке місце » (обмеження, що обмежує пропускну здатність), « пропускна здатність » (запити за секунду), « затримка » (час відповіді), « розшарування » (розділення даних між базами даних), « шар кешування », « репліка для читання » і « зрештою послідовність ». Ви кажете, що система « без стану », коли екземпляри можна масштабувати без координації, і « має стан », коли цього неможливо зробити.

Практичні шаблони: «На наших поточних рівнях трафіку, вертикального масштабування достатньо, але якщо ми зростаємо на 10x, нам потрібно подивитися на горизонтальне масштабування і, ймовірно, ввести кешуючий шар.» / «Поточна архітектура має одну точку невдачі в базі даних — ми повинні додати репліку читання і, можливо, перейти до налаштування первинної репліки»

Професійне «залежно» вкладення

У системному дизайні, « це залежить » є правильною відповіддю на більшість питань — але ви завжди повинні слідувати за ним з « це залежить від X, Y і Z. » Залишаючи його на « це залежить » звучить ухилятися. Сильні формулювання: «Це залежить від ваших вимог до послідовності. Якщо вам потрібна сильна послідовність, вам знадобиться реляційна база даних з операціями, які можна серіалізувати. Якщо остаточна послідовність прийнятна, то NoSQL-склад може дати вам кращу пропускну здатність запису." / "Правий підхід насправді залежить від очікуваних шаблонів запитів — чи можете ви провести мене через найчастіші шаблони доступу?"

Розробка мови програмування C# та розділів мови

У розмовах про розподілені системи обговорюється теорема CAP (ви можете мати не більше двох з таких: Послідовність, Наявність, Толерантність до розділів), « сценарії розділення мозку », « алгоритми консенсусу », такі як Raft і Paxos, « вибори лідерів », « кворум » і « затримка реплікації ». Використовуйте ці терміни з обережністю: « У сценарії мережевого розділу ця система надає перевагу доступності перед послідовністю — клієнти можуть читати застарілі дані доки розділ не буде відновлено. »

Розділ 5: Технічне інтерв'ю англійською

Технічні інтерв'ю англійською мовою мають свої власні конвенції і словниковий запас. Зрозуміти, що очікують співбесідник і знати, як структурувати свої відповіді, може зробити різницю між хорошим інженером, який співбесідує погано, і хорошим інженером, який співбесідує добре.

Метод «Зоря» для поведінкових питань

На поведінкові питання (Розкажіть мені про час, коли ви...) найкраще відповідати за допомогою формату STAR: Ситуація (встановіть контекст), Завдання (поясніть вашу роль і виклик), Дія (описайте конкретно, що ви зробили), Результат (вкажіть результат з даними, якщо це можливо). Мовний шаблон: «На моїй попередній посаді в [компанії], у нас була ситуація, коли [ситуація]. Я був відповідальним за [Задача]. Я зробив [Дія]. Як результат, [Різниця].» Практикуйте цю структуру, поки вона не стане природною — це очікуваний формат у більшості технологічних компаній.

«Пройти через» відповіді

Інтерв'юери часто просять вас «провести мене через» ваш код, ваш підхід або ваш попередній досвід. Ця фраза сигналізує, що вони хочуть розповідь, а не просто список фактів. Почніть з великої картини, а потім зануріться в деталі: «Звичайно — на високому рівні, те, що я тут роблю, це X. Я не можу робити це, тому що я не знаю, як це зробити». Зокрема, [деталь 1], [деталь 2], і [деталь 3]. Причина, чому я обрав цей підхід над Y, це [розуміння]»

Алгоритмічне мислення

У живих інтерв'ю з програмуванням і алгоритмами, від вас очікують, що ви будете думати вголос. Ключові фрази: «Дозвольте мені почати з того, що я розумію проблему…» / «Один підхід буде використовувати геш-карту для зберігання…» / «Я розгляну краї випадки спочатку: що відбувається, коли вхід порожній? Що, якщо є дублікати?» / «Це рішення має складність O(n log n) за часом і O(n) в просторі. Ми могли б поліпшити складність простору за допомогою…» Інтерв'юери явно хочуть почути цю розповідь — мовчання інтерпретується негативно.

Розділ 6: Щоденне командне спілкування

Найчастіше англійською розробник сервера пише не в документації або формальному дизайні документів — це в щоденному асинхронному спілкуванні: оновленнях, повідомленнях Slack про блокування, коментарях до квитків і резюме зустрічей. Якщо ви це зробите правильно, ви збудуєте репутацію чіткого комунікатора і зробите свою команду більш ефективною.

Актуальні новини

Повідомлення (написане в Slack або вимовлене) відповідає на три запитання: Що ви робили вчора? Що ти сьогодні робиш? Ты заблокирован? Мова коротка і орієнтована на дії. Порівняйте слабку і сильну версії: Слабка: « Вчора я виконував розпізнавання, і сьогодні я продовжую це робити ». Сильна: « Вчора: було завершено оновлення токенів JWT (PR # 312 об’ єднано). Сьогодні: реалізація середовища обмеження швидкості. Без блокування»

Використовуйте простий минулий час для завершених завдань (« завершено », « об’ єднано », « розгорнуто »), теперішній час для триваючої роботи (« працюю над », « реалізую »), і явні фрази « Заблоковано X », якщо це потрібно, замість нечіткого « маючи деякі проблеми. »

Блокування ескаляції

Коли вам потрібна допомога або вас заблокували, англійська конвенція має бути конкретною: «Заблоковано на PR #287 — очікує перегляду від команди платформи. Позначте цей пункт, якщо нам потрібно буде ескалувати ситуацію, щоб досягти мети спринту. » Уникайте нечітких повідомлень на зразок « Я застряг » — завжди вказуйте, з чим ви застрягли і що вам потрібно. При ескалації: «Я намагався вирішити X два дні і в мене закінчилися ідеї — буду вдячний за 30 хвилин спілкування з кимось, хто має досвід з [технологією]»

Асинхронні повідомлення Slack

Асинхронні повідомлення мають бути самостійними і дійсними. Завантажувати ключові дані заздалегідь: починати з найважливіших. Використовувати гілки для впорядкування обговорень. Поширені шаблони: « Зауваження: розгортання до стадії розробки було заблоковано [проблема]. Я опублікую оновлення, коли це буде вирішено — від команди не потрібно жодних дій." / "@team — швидке питання перед тим, як я продовжу: чи повинна ця кінцева точка повертати 404 або 403, коли ресурс існує, але користувач не має доступу?" / "FYI — Я помітив X у виробництві. Не спекотно, але записую це тут, щоб ми не забути»

Найкорисніший словник і фрази для розробників сервера

Наступні фрази постійно з' являються в інженерному спілкуванні. Вивчайте їх у контексті, а не як ізольовані терміни.

Рекомендований шлях навчання для розробників сервера

Пройдіться цими вправами послідовно, щоб поступово розвивати свої навички англійської мови, починаючи з основного словника і закінчуючи складними сценаріями спілкування.

1. 1-й

   Мова розробки API

   Почати тут — API- зв’ язок є хребетною кістковою кістки англійської мови. Включає словник опису кінцевої точки, семантику HTTP і мову проектування RESTful.

2. 2-й

   Перегляд коду повідомлення

   Необхідний для будь-якого інженера, що працює в команді. Вивчіть блокування і відблокування зворотного зв’ язку, префікс nit і те, як запитувати зміни без пошкодження робочих відносин.

3. 3-й

   База даних і мова SQL

   Словник для обговорення проектування схем, швидкодії запиту і стратегії індексування під час зустрічей і у письмовій документації.

4. 4-й

   Архітектурна мова програмування

   Словник компромісів, шаблони проектування системи, і мова архітектурних записів рішень.

5. П'ять

   Розподілені системи та консенсус

   Теорема CAP, моделі послідовності, вибори лідерів та інші словники розподілених систем для старших ролей сервера.

6. 6-й

   Віддалене & асинхронне спілкування

   Оновлення Standup, блокування ескалації та асинхронне спілкування Slack для розподілених команд.

7. Сім

   Запитання для інтерв'ю

   Вправлятися у відповіді на найпоширеніші питання інтерв’ ю з інженерами англійською мовою з впевненістю.

8. 8-й

   Мова інтерфейсу — англійська

   Словниковий запас і структури, необхідні для системного дизайну, в топових технологічних компаніях.

Набори вправ для розробників сервера

Вправляйтеся у словниковому запасі і моделях спілкування, які описано у цьому підручнику, за допомогою таких груп вправ: