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

Англійська мова для початківців

Розробка фронтенду знаходиться на унікальному перетині технічної інженерії і дизайну — і обидві області мають свій власний англійський словник. Розробник інтерфейсу повинен бути в змозі прочитати коментар від дизайнера, перекласти нечітке «це не виглядає правильно» в точний опис проблеми CSS, обговорити Core Web Vitals з менеджером продукту, написати доступний HTML, який включає правильні описи атрибутів ARIA, і переглянути документацію API компонента колеги для ясності. Кожне з цих завдань вимагає іншого виду вільної англійської мови.

Інженерія фронтендів також є унікальним видом. Роботу розробника інтерфейсу безпосередньо бачать кінцеві користувачі, що означає, що написаний вміст продукту — повідомлення про помилку, порожня копія стану, ARIA-мітки, текст кнопок — має справжню бізнес-важливість. Вміння писати просту, зрозумілу для користувача англійську мову для інтерфейсу користувача є практичною навичкою, а не додатком.

Крім того, фронт-енд має одну з найбагатших екосистем англомовних ресурсів — MDN Web Docs, CSS-Tricks, Smashing Magazine, документація React і Vue, специфікації W3C і рекомендації WCAG написані англійською мовою і є основними посиланнями для професійних розробників фронт-енду по всьому світу. Читання і розуміння технічної англійської на рівні цих ресурсів є щоденною вимогою для того, щоб залишатися в курсі.

У розділах, наведених нижче, описано певні реєстри і словники, які потрібні вам як розробнику інтерфейсу: правила присвоєння імен архітектурі CSS, мова компонентів API і документації Storybook, точний словник доступності веб- ресурсів, мова оптимізації швидкості, заснована на даних, і спільна англійська мова передачі даних з етапу проектування до розробки.

Розділ 1: CSS & JavaScript Назва конвенції англійською

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

BEM і CSS Architecture Vocabulary

BEM (Block Element Modifier) є найбільш широко обговорюваною методологією CSS-названь в англійській мові. Словник: «блок» є самостійним компонентом (наприклад,.card ), «елемент» є частиною блоку (наприклад,.card__title ), а «модифікатор» є варіантом або станом (наприклад,.card--featured ). У рецензіях коду ви можете написати: « Я пропоную використовувати BEM-назви тут — поточні плоскі назви класів ускладнюють розуміння меж компонентів. » або « Ця назва модифікатора неоднозначна —.btn--primary ясніше, ніж.btn--blue, тому що вона виражає намір, а не вигляд. »

Інші слова з лексики архітектури CSS включають «специфічність» (як браузер вирішує конфліктні стилі — описується як «висока специфічність» або «низка специфічність»), «каскад» (C в CSS — стилі переходять від батька до дитини), «утильні класи» (клас одноразового призначення, як Tailwind's mt-4 ), «дизайнові токени» (названі значення для кольорів, інтервалів і типографії, спільні між дизайном і кодом), і «CSS нетипові властивості» (CSS змінні).

JavaScript і компоненти назв

У дискусіях щодо назв компонентів використовується лексика типу « описові проти загальних назв », « PascalCase для компонентів », « camelCase для змінних і функцій », « kebab- case для назв файлів » і « SCREAMING_ SNAKE_ CASE для констант ». Під час перегляду назв у PR: « Я б перейменував це на UserProfileCard — поточна назва Card занадто загальна для цього випадку використання. » / « Ця назва prop handleClick трохи зайва — оскільки обробники подій зазвичай мають префікс on, onClick буде більш ідіоматичною. » / « Назва файла utils. js є загальною — розгляньте розділення за доменом: dateUtils. js, stringUtils. js. »

Розділ 2: Компонентна документація мови

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

Запис описів компонентів

Опис компонента повинен відповідати на питання: для чого цей компонент? Коли використовувати? Які реквізити він приймає? Які можливості доступності він включає? Які його візуальні варіанти? Хороші описи використовують наголос наказового відмінка для інструкції і теперішнього часу для опису: « Використовуйте кнопку для всіх інтерактивних дій. Віддати перевагу посиланням для навігації." "Показує елемент кнопки, яку можна клацнути. Підтримує три візуальні варіанти: первинний, вторинний і привид. " "Прийнято опціональну іконку prop для відтворення ведучого іконки - іконка повинна бути елементом React."

Конвенції з документації

У описі кожної властивості слід вказувати: назву властивості, її тип TypeScript, чи є вона обов’ язковою чи необов’ язковою, її типове значення, якщо воно необов’ язкове, і чіткий опис того, що вона контролює. "disabled: boolean — необов’ язковий, типове значення — false. Якщо значенням буде « true », кнопка не буде інтерактивною і буде показуватися зі зменшеною непрозорістю." / "variant: 'primary' |' secondary' | 'ghost' — обов' язковий. Керує візуальним виглядом кнопки. » Зауважте, що шаблон: короткий, активний, специфічний. Ніколи не повторюйте назву реліквії.

Система мовлення та мовлення

У документації до Storybook використовуються такі терміни, як « story » (один відтворений екземпляр компонента), « controls » (інтераактивна панель властивостей), « arguments » (прикмети, передані до story), « decorators » (обгортки, застосовані до story), « add- on » і перегляди « canvas » проти « docs ». Мова дизайну системи включає «бібліотеку компонентів», «токен», «варіант», «щільність» (компактний проти комфортного розташування), «патерн» (розв'язання інтерфейсу користувача з можливістю повторного використання) і «композиція» (будівництво складних інтерфейсів користувача з простих компонентів).

Розділ 3: Доступність (a11y) Комунікація

Веб-доступність є технічною та етичною вимогою, а її англійський словник щільно заповнений акронімами та спеціалізованими термінами. Вміння чітко обговорювати доступність — в перегляді коду, перегляді дизайну і звітах про помилки — є маркером професійної зрілості інтерфейсу. Це також важливо для відповідності: документація WCAG (Web Content Accessibility Guidelines) написана англійською мовою і є глобальним стандартом.

WCAG і стандарти доступності мови

WCAG визначає вимоги доступності на трьох рівнях: A (мінімальний), AA (середній рівень, типовий законний вимог), і AAA (найвищий). Вимоги описані як « критерії успіху ». Під час обговорення відповідності: « Цей компонент не відповідає вимогам WCAG 2. 1 AA — співвідношення контрасту кольорів між текстом і тлом становить 3. 2: 1, але AA вимагає принаймні 4. 5: 1 для звичайного тексту. » / « Нам слід додати видимий індикатор фокусу — поточні стилі вилучають типовий контур без надання альтернативи, що не відповідає вимогам WCAG 2. 4. 7 Focus Visible. »

ARIA — мова атрибутів

Атрибути ARIA (Accessible Rich Internet Applications) мають певний словник: « role » визначає, що таке елемент (« Цей div потребує role='button', оскільки це не є нативним елементом < button >. »), « aria- label » надає доступну назву (« Додати aria- label='Close dialog' до кнопки X — сама піктограма не має текстового вмісту. »), « aria- describedby » посилається на елемент з описом, і « aria- live » повідомляє про динамічні зміни вмісту для програм для читання з екрану. Поширені формулювання рецензій: «Цьому інтерактивному елементу не вистачає доступної назви — додайте aria-label або включіть видимий текстовий вміст.» / «Повідомлення про помилку повинно використовувати aria-live='polite', щоб програми для читання з екрану повідомляли про це, коли воно з'являється.»

Доступність в дизайн-оглядах

Під час перегляду дизайну на предмет доступності, використовуйте точні слова: « Цільовим розміром для дотику є 32x32 пікселів — WCAG 2. 5. 5 рекомендує мінімум 44x44 пікселів. » / « Цей модальний елемент не затримує фокус — користувачі можуть виходити з модального елемента і взаємодіяти зі сторінкою за ним. » / « Немає доступної за допомогою клавіатури альтернативи інтерфейсу перетягування і скидання. » / « Підказка з’ являється лише при наведенні вказівника миші — користувачі клавіатури не зможуть отримати до неї доступ. » Ці спостереження перетворюють рішення щодо дизайну на конкретні технічні вимоги щодо доступності.

Розділ 4: Виконання та основні Web Vitals Language

Веб-продуктивність є дисципліною з багатим кількісним словником. Під час обговорення продуктивності з колегами, менеджерами продуктів або зацікавленими особами, вам слід точніше говорити про показники, пороги і їх вплив на користувачів. Core Web Vitals є стандартизованими показниками продуктивності Google і стали індустріальним словником для обговорення продуктивності.

Основні веб-сайти Євангеліон

Три основних Web Vitals: LCP (Largest Contentful Paint — вимірює сприйняту швидкість завантаження, час до появи найбільшого видимого елемента), FID/INP (First Input Delay / Interaction to Next Paint — вимірює інтерактивність і здатність реагувати на введення користувача), і CLS (Cumulative Layout Shift — вимірює візуальну стабільність, наскільки сторінка несподівано змінюється під час завантаження). Кожен з них має поріг « добре », « потребує поліпшення » і « погано ». « Наш LCP зараз становить 4, 2 секунди — ми знаходимося у діапазоні « погано ». Це менше ніж 2,5 секунди для «доброї» оцінки.» / «Рейтинг CLS 0,28 викликає видимі зміни макету на повільних з'єднаннях — нам потрібно резервувати місце для зображень, які завантажуються асинхронно»

Мова оптимізації продуктивності

Обговорення оптимізації вимагає словникового запасу як для діагностики, так і для розв'язання. Поширений діагностичний словник: « ресурс блокування відтворення » (скрипт або таблиця стилів, що перешкоджає відтворенню сторінки), « критичний шлях відтворення » (кроки, які переглядач повинен виконати перед показом вмісту), « розмір пакета JavaScript » (загальний розмір звантажених файлів JS), « розривання дерева » (вилучення невикористаного коду з пакетів), « розділення коду » (розділення пакета на менші шматки, завантажені за потреби) і « частота влучень кешу » (відношення запитів, які обслуговуються з кешу). Словник рішень: « ліниве завантаження » (відкладення завантаження ресурсів поза екраном), « попереднє завантаження » (підказка переглядачеві отримати критичні ресурси раніше), « мінімізація », « стиснення » і « доставка CDN »

Практичні шаблони обговорення: «Аудит продуктивності показує, що у нас є 380 кб пакету JavaScript — значна частина є бібліотекою дати, яку ми використовуємо тільки для однієї функції форматування. Ми повинні або імпортувати тільки цю функцію, або замінити її меншою альтернативою." / "Зображення героя не попередньо завантажено, що сприяє поганому LCP - додавання <link rel='preload'> повинно значно поліпшити його."

Розділ 5: Дизайн Handoff & Collaboration англійською

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

Запитання про розробку проекту

Добрі питання для пояснення є конкретними і безпосередньо стосуються дизайну: « У мобільному перегляді, що має статися, коли таблиця має більше 5 стовпчиків? Поточний дизайн не враховує переповнення. / « Який порожній стан цього списку — якщо немає результатів, чи слід показувати повідомлення або повністю сховати компонент?» / « Відстань між цими картами у дизайні стільниці становить 24 пікселі — чи є це фіксованим значенням, чи слід його змінювати з переглядом вікна?» У цих питаннях використовується точний словник (вікно перегляду, переповнення, порожній стан, відстань) і посилання на конкретні числа з дизайну.

Флагман технічної можливості

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

Дизайн токена і словник Handoff

Сучасна передача проекту використовує Figma, Zeplin або подібні інструменти, які створюють специфікації проекту. Словниковий запас: « специфікація проекту » (докладна документація проекту, у тому числі розміри, інтервали і кольори), « червона лінія » (анотації, що показують точні виміри), « чутлива точка зупинки » (ширина вікна перегляду, за якої змінюється компонування), « автоматичне компонування » (гнучка система компонування Figma, аналогічна CSS flexbox), « екземпляр компонента » (повторне використання головного компонента).

Розділ 6: Мова сумісності браузера

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

Support Matrix і Browser Support Vocabulary

«Матриця підтримки браузера» або «політика підтримки браузера» визначає, які браузери і версії програма офіційно підтримує. Словник: «вічнозелені браузери» (браузери, що автоматично оновлюють — Chrome, Firefox, Edge), «старі браузери» (старіші версії, зазвичай IE11 або старший Safari), «базова лінія» (набір веб-функцій, які зараз широко доступні у всіх основних браузерах — відносно нова концепція W3C), «граціозне зниження» (спочатку будівництво для сучасних браузерів і забезпечення того, щоб старі браузери все ще отримували функціональний, якщо не менш багатий, досвід) і «прогресивно розширення» (спочатку будівництво базового функціонального досвіду і додавання розширень для здатних браузерів).

При обговоренні підтримки браузера в перегляді коду або плануванні: «Цей CSS контейнерний запит ще не підтримується в Safari 15 — якщо нам потрібно підтримувати Safari 15, нам буде потрібно резервне копіювання.» / «Я перевірив Can I Use — властивість співвідношення сторін має 97% глобальну підтримку, тому ми можемо безпечно використовувати його без резервного копіювання.» / «Ми могли б використовувати рідний CSS :has() селектор тут, але це тільки в наших офіційно підтримуваних браузерах з минулого кварталу — варто перевірити з командою, перш ніж покладатися на нього.»

Мова програмування та мови програмування

« Polyfill » — це код, який надає функціональність, яку переглядач не підтримує. « Transpilation » (зроблене за допомогою Babel або TypeScript) перетворює сучасний JavaScript на версію, сумісну зі старими середовищами. « Bundling » об’ єднує декілька файлів у один. Ви « націлюєте » налаштування збирання на певні версії переглядача. « Префікси виробника » (- webkit-, - moz-) є застарілими механізмами експериментальних можливостей CSS.

Розділ 7: Інтерв'ю з англійської

Фронт-енд інтерв'ю в сучасних технологічних компаніях, як правило, включають JavaScript / TypeScript кодування, CSS / HTML тест знань, системний дизайн (часто зосереджений на архітектурі інтерфейсу або дизайні системи) і поведінкові питання. Кожна з них вимагає трохи різних англійських стратегій.

Пояснення концепції JavaScript

У типових питаннях інтерв’ ю з використанням JavaScript вам слід пояснити складні поняття простою англійською мовою. Ключові формулювання: «Закриття — це функція, яка зберігає доступ до змінних її зовнішнього обсягу навіть після повернення зовнішньої функції. Конкретно, якщо я пишу..." / "Перетворювальник подій обробляє спочатку стек викликів, потім чергу мікрозадач, а потім чергу макрозадач. На практиці це означає..." / "Я б описав різницю між null і undefined як..." Використовуйте шаблон: визначте концепцію в одному реченні, а потім наведіть конкретний приклад.

Специфіка та пояснення макету CSS

Інтерв’ юери часто просять вас пояснити особливості CSS, моделі коробки або flexbox проти ґратки. Використовуйте структуру: пояснення + приклад + коли використовувати. « Специфічність CSS визначає, яке правило перемагає, коли два селектори спрямовані на один і той же елемент. Його обчислюють як значення з чотирьох частин — вбудовані стилі переважають над ідентифікаторами, які переважають над класами, які переважають над селекторами елементів. На практиці, я намагаюся зберігати специфічність низькою, уникаючи ідентифікаторів і глибоко вкладених селекторів. "

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

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

1. 1-й

   Словник CSS і інтерфейсу

   Збудуйте свій фундамент за допомогою основного словника CSS- компонування, моделі коробки, специфічності і сучасних можливостей CSS.

2. 2-й

   Перегляд коду вправ

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

3. 3-й

   Доступність мовних вправ

   Словник WCAG, мова атрибутів ARIA, і як сформулювати вимоги доступності в проектуванні та перегляді коду.

4. 4-й

   Технічні вправи з письма

   Документація щодо компонентів, описи API і правила чіткого технічного письма.

5. П'ять

   Мова дизайну продукту

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

6. 6-й

   Професійна мова програмування

   Основний словник Web Vitals і мова для обговорення і звітів про швидкодію мережі.

7. Сім

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

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

8. 8-й

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

   Письменне спілкування для розподілених команд інтерфейсу — оновлення, зворотній зв' язок щодо дизайну і асинхронні повідомлення передачі.

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

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