Англійська для розробників Micro-Frontend

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

Ключовий словник

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

• Приклад: « Оболонкова програма є власником верхньої навігації і вирішує, який мікро- інтерфейс монтувати на основі поточного маршруту. » *

** Модульна федерація ** Метод (популярний за допомогою Webpack), який надає змогу окремо збудованим і розгорнутим програмам JavaScript динамічно завантажувати код один від одного під час виконання, без необхідності збиратися разом.

• Приклад: « Ми використовуємо федерацію модулів, щоб оболонка могла завантажити останню розгорнуту збірку мікро- інтерфейсу без перебудови самої оболонки. » *

** Мікро- інтерфейс (віддалений) ** Незалежний розроблений, збудований і розгорнутий елемент більшої інтерфейсної програми, зазвичай належить одній команді, яка відповідає за певну область функціонування.

• Приклад: « Мікро- інтерфейс пошуку повністю належить команді пошуку, і вони можуть розгортати його незалежно від решти сайту. » *

** Контракт (в контексті мікро- інтерфейсу) ** Затверджений інтерфейс, наприклад, спільні засоби, події або API з версіями, який визначає спосіб зв’ язку мікрофронту з оболонкою або з іншими мікрофронтами.

• Приклад: « Ми порушили договір, перейменувавши цю спільну подію без періоду зникнення, і мікро- фронтенди двох інших команд беззвучно перестали її отримувати. » *

** Спільна залежність ** Бібліотека (наприклад, платформа інтерфейсу користувача або система проектування), на яку покладаються декілька мікрофронтенів і яку, ідеально, слід завантажувати лише один раз, щоб уникнути дублювання розміру пакунка і зберегти послідовність поведінки на всій сторінці.

• Приклад: « Ми дедуплікуємо спільну залежність на нашій бібліотеці системного дизайну, оскільки три мікро- фронтенди кожен відправляв свою власну копію. » *

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

• Приклад: « Ця помилка відтворюється тільки у виробничому середовищі через відхилення версії — у стаджінгу всі мікро- інтерфейси були на одній версії спільної бібліотеки випадково. » *

** Композиція (композиція сторінки) ** Процес збирання декількох незалежно збудованих мікро- інтерфейсів у єдину послідовну сторінку, або на сервері, або на межі, або у переглядачі.

• Приклад: « Ми пересунули компонування сторінки на край, щоб користувачі отримали повністю зібрану сторінку при першому завантаженні, замість того, щоб чекати завершення компонування на стороні клієнта. » *

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

• Приклад: « У нашій поточній топології команди дві команди, обидві торкаються мікро-фронтенду вилучення, що є саме тим типом перекривання, яке спричиняє конфлікти розгортання, які ми бачимо. »*

Звичайні фрази

** В обзорах коду: **

• «Цей мікро-фронтенд прямує безпосередньо до внутрішньої структури DOM іншої команди замість того, щоб пройти через узгоджений договір — це порушить момент, коли вони перероблять свою розмітку»
• «Ми з’єднуємо нашу власну копію системи дизайну замість використання спільної залежності — це додає 200 КБ, які нам не потрібно відправляти»
• «Ця зміна назви події не є зворотньо сумісною — нам потрібен період застаріння перед повним видаленням старої події, оскільки інші команди все ще можуть слухати її»

В стоячих позах:

• «Вчора я виправив помилку версії між нашим мікро-фронтенденом і спільним екземпляром React оболонки; сьогодні я додаю перевірку запуску, яка гальмує гучно замість тихого розбиття»
• «Я заблокований на зміні контракту команди по виїзду — вони перейменували реквізит без оновлення спільних визначень типів, тому наші інтеграційні тести зазнають невдачі»
• «Я закінчив міграцію нашого мікро-фронтенду до модульної федерації; тепер він завантажується незалежно від оболонки без повної перебудови сайту»

** У межах обговорення архітектури команд: **

• Якщо ми не формалізуємо цей контракт, кожна перейменована реквізит або подія ризикує беззвучно розбити мікро-фронтенд іншої команди в виробництві
• «Ми повинні версувати цей спільний договір явно, щоб споживачі могли вибрати зміни в своєму власному розкладі, а не бути здивованими ними»
• Це накладання в топології команди викликає конфлікти розгортання — чи повинні ми перекреслити межі власності, щоб кожна команда володіла чистішим, більш незалежним шматком?

Фрази, яких слід уникати

Сказав “це просто розірвалося”, коли змінився спільний контракт. Замість цього скажіть: « спільний договір події змінився без періоду втрати чинності » або « існує відхилення версії між нашою спільною залежністю і їхньою ». Ці дії вказують безпосередньо на справжню причину, якою майже завжди є розрив у координації, а не загадкова помилка.

**Сказав “ми будемо координувати вручну” як довгострокову стратегію контракту. ** Это не может быть расширено за счет нескольких команд. Замість цього скажіть: «ми потребуємо версії, документованого контракту з автоматичними перевірками сумісності» — ручна координація повинна бути зупинки, а не плану.

Слово “мікро-фронтенди” означає, що команда автоматично стає незалежною. Розділення коду на мікро-фронтенди не гарантує незалежної розгорнутості, якщо команди все ще діляться тісно пов’язаними контрактами або конвеєрами розгортання. Будь конкретним щодо того, що насправді незалежно проти того, що все ще потребує координації.

Краткий справочник

Term	How to use it
shell application	”The shell owns routing and mounts the right micro-frontend.”
module federation	”Module federation lets the shell load remotes built independently.”
contract	”We broke the contract by renaming a shared event without notice.”
shared dependency	”Deduplicating the shared dependency cut bundle size significantly.”
version skew	”This bug only shows up in production due to version skew.”
composition	”We moved page composition to the edge for faster first paint.”

Ключеві моменти

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

Переклад з англійської: Микола Сікорський

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

Одна з найчастіших проблем виникає під час перегляду коду. Отримавши зворотній зв’язок, наприклад, “Цей компонент міг би бути більш модульним”, не є за своєю суттю негативним. Однак, як це доставляється має величезне значення. Конструктивною відповіддю буде: «Я ціную пропозицію зробити цей компонент більш модульним. Чи можете ви розібратися, що саме відчувається менш модульним у його нинішній структурі? Можливо, пояснення залежностей, які існують між цим компонентом, або опис його взаємодії з іншими частинами програми допоможе мені зрозуміти ваші зауваження і відповідно до них діяти. Зауважте використання таких фраз, як « дякую за пропозицію », « чи могли б ви розібратися » і « допоможіть мені зрозуміти ». Ці фрази демонструють сприйнятливість і бажання отримати пояснення, уникаючи захисних дій. Аналогічно, активне описування ваших змін у запиті на витягнення (PR) не просто перелік змін коду; це встановлення контексту. Хороший опис PR може починатися так: « Цей PR вводить новий компонент повторного використання для обробки автентифікації користувача. Він використовує модульну федерацію для зменшення розмірів пакетів і покращує підтримку, виключаючи проблеми, пов’ язані з входом користувача і керуванням сеансами. Ця зміна розв’язує проблему #123 і відповідає контракту команди щодо потоків автентифікації. ”

Іншою областю уваги є Slack комунікація. Уявіть, що ви отримали повідомлення: « Що відбувається з цим?» Корисною відповіддю буде не коротке « Нічого », а « Я зараз досліджую проблему з продуктивністю у компоненті профілю користувача, пов’ язану з отримання даних. Я виявив потенційну проблему з надмірними викликами API і досліджую стратегії кешування. » Подробиці — згадка про певний компонент, спостережену проблему (в’ язка продуктивності) і ваші негайні дії — показують, що ви приймаєте на себе відповідальність і надаєте цінну інформацію колегам, які можуть допомогти. Це стосується того, щоб бути точним в описі ситуації і продемонструвати активний підхід.

Нарешті, пам’ятайте, що чітке спілкування є важливим при встановленні контрактів між командами - визначення відповідальності навколо спільних залежностей або API. Замість простого затвердження «Команда А надає дані користувача», добре визначений контракт буде сформулювати особливості: «Команда А буде виставляти кінцеву точку REST API на /users/{userId} з відповіддю JSON, що містить дані користувача. API має мати версію (v1) і дотримуватися встановленої схеми, описаної у документації [посилання]. Команда А буде надавати перевагу SLA з 99, 9% часу роботи для цієї кінцевої точки. “Цей рівень деталізації мінімізує неоднозначність і встановлює чіткі очікування, зменшуючи потенційні трення і нерозуміння в подальшому.

# Example using webpack-bundle-analyzer to investigate bundle sizes:
webpack-bundle-analyzer --port=8888

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