Англійська для розробників Nx Monorepo

Nx monorepos вводить словник, побудований навколо графіків залежностей і кешування обчислень, який не існує в репозитірах з одним пакунком. Команди, які не можуть відрізнити « вражені » від « всіх », або « межі проекту » від структури тек, мають тенденцію писати неточні звіти CI і нечіткі коментарі перегляду коду. У цьому підручнику наведено терміни, які вам слід знати для розуміння роботи з робочим простором Nx.

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

** Графік проекту ** — графік залежностей Nx, який буде створено за допомогою аналізу імпортів у робочому просторі, використовується для визначення того, які проекти залежать від яких інших проектів. “Граф проекту показує, що програма checkout залежить від спільної бібліотеки інтерфейсу користувача, тому зміна в ній також повинна викликати тестування checkout.”

** Вплив** — набір проектів, код яких змінився, безпосередньо або транзитивно, з моменту вказаного посилання git, використовується для обмеження CI лише на те, що потребує перезбирання. “Замість запуску всього набору тестів, CI запускає тести тільки для проектів, які зазнали впливу, що скорочує час нашого конвеєра з двадцяти хвилин до чотирьох.”

** Графік задач ** — упорядкований набір завдань (збирання, тестування, лінт) Nx обчислює всі проекти, які задіяно, з урахуванням залежностей, отже бібліотека буде збудована першою за програму, яка її використовує. “Nx автоматично створює графік завдань, тому нам не потрібно вручну вказувати, що спільна бібліотека має бути збудована перед програмою.”

** Кешування обчислень ** — Механізм Nx для повного пропуску завдання і повторення його кешованого виводу, якщо вхідні дані не змінилися з часу останнього виконання. “Ця збірка завершилася за дві секунди через кешування обчислень — нічого не змінилося на вхідних даних з часу останнього запуску CI.”

** Модульна межа ** — правило lint ( @nx/enforce-module-boundaries ), яке обмежує, з яких проектів можна імпортувати, запобігаючи програмі потрапляння до внутрішніх даних іншої програми.

• “Правило меж модулів блокує цей імпорт, оскільки бібліотекам можливостей не дозволено безпосередньо залежати від інших можливостей.” *

** Nx Cloud ** — хостована служба, яка спільно використовує кеш обчислень і розподіляє виконання завдань між машинами CI і ноутбуками розробників.

• “За допомогою Nx Cloud, якщо один з колег вже збудував цей саме запит, ваша локальна збірка просто витягне кешований результат замість перебудови.” *

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

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

Приклади висловлювань

Пояснення прискорення CI у ретро: “Ми ввімкнули nx affected в конвеєрі, тому зміна на одну бібліотеку більше не викликає повного перебудови кожної програми — тільки проекти, які насправді залежать від неї, працюють.”

Звіт про порушення меж:

• “Крок lint зазнав невдачі, оскільки функція платежу імпортує безпосередньо з функції оплати, що порушує правила меж модуля — замість цього вона повинна проходити через бібліотеку спільного домену.” *

Обговорення поведінки кешування з одноклубником: “Збірка виглядала миттєво в CI через кешування обчислень — вхідні дані, включаючи геш файла блокування, не змінилися з часу останнього успішного запуску на цій гілці.”

Професійні поради

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

Практичні вправи

1. Поясніть у двох реченнях, чому nx affected може зробити CI швидшим, не жертвуючи коректністю.
2. Написати коментар перегляду коду у одному реченні, у якому буде позначено порушення меж модуля.
3. Опишемо вашими словами відмінність між графіком проекту і графіком завдання.

Національний гідрографічний інститут: Відповідь і відповіді

Для не- рідних носіїв, освоєння тонкощів професійної англійської мови в технічному середовищі, як Nx monorepo може відчувати себе особливо викликом. Це не просто про знання * слів *; Це про розуміння немовлених очікувань і як зворотній зв’язок доставляється, отримується і діє в команді. Часто, прямі переклади з вашої рідної мови не вміщують у собі всі нюанси, які стоять за фразами, використовуваними під час перегляду коду або обговорення. Розгляньте різницю між простою заявою про проблему і її формулюванням як пропозиції щодо поліпшення. Останнє - особливо коли це робиться конструктивно - демонструє повагу до роботи вашого колеги і заохочує позитивний обмін.

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

Крім того, розуміння термінології навколо залежних відносин - * вплив команд * в графі завдання - є ключем до ефективного пояснення змін. Якщо ви змінили налаштування пакунка і хочете повідомити про його вплив, сказавши «Ця зміна запустить команду Nx, яка вплине на build і, можливо, test », ви отримаєте контекст, який набагато більше, ніж просто вказати, що ви зробили. Цей рівень точності створює довіру в команді і сприяє ефективному вирішенню проблем.

nx graph --output=dot monorepo && dot -Tpng monorepo.dot -o monorepo.png

За допомогою цієї команди ви можете створити графік залежностей вашого сховища monorepo за допомогою nx graph, а потім вивести його у вигляді мови DOT. Результатом роботи є файл DOT, який потім відтворюється у вигляді зображення PNG, що надає вам змогу побачити структуру проекту — це корисний інструмент для пояснення змін, пов’ язаних з * межами проекту * і залежностями під час обговорення.