Як обговорювати Monorepo vs. Polyrepo англійською мовою
Вивчіть англійські фрази для обговорення взаємозв’ язків між монорепо і полірепо: з’ єднання, вартість інструментів і автономність команди, у розмові про архітектуру.
Монорепо- проти-полірепо дебати стають непродуктивними швидко, коли вони перетворюються на «монорепо є кращим» проти «полірепо є кращим» як загальні претензії — корисна версія цієї розмови називає конкретні компроміси (з’єднання, вартість інструментів, незалежність випуску) для фактичного проекту під рукою. Цей посібник містить цей словник.
Ключовий словник
** Сполучення (крос- проект) ** — наскільки тісно код двох проектів залежить один від одного, ключовий фактор у тому, чи має сенс зберігати їх у одному сховищі (простіше атомарні зміни) або у окремих (простіше незалежна еволюція). “Ці дві служби тісно пов’язані зараз - половина наших PR торкається обох. Це фактично аргумент для монорепо, принаймні доки ми не від’єднаємо інтерфейс між ними.”
** Атомне збереження (крос- сховище) ** — одне збереження або PR, яке змінює декілька проектів разом послідовно, просте у моно- сховищі, але вимагає ретельної координації (або тимчасового порушеного стану) між окремими полі- сховищами.
- “У монорепо, цей рефактор є одним атомарним звітуванням як для бібліотеки, так і для її користувачів. У налаштуванні polyrepo, нам потрібно опублікувати нову версію бібліотеки спочатку, а потім оновити кожного споживача окремо.”*
** Незалежність від випуску ** — можливість версування, тестування і розгортання одного проекту за власним розкладом без прив’ язки до циклів випуску не пов’ язаних проектів, загалом простіше у полірепозиторії. “Ми хочемо незалежності випуску тут - ця служба відправляється кілька разів на день, і ми не хочемо, щоб її розгортання було обмежено повільнішою частотою випуску не пов’язаної команди.”
** Вартість інструментів ** — інженерні інвестиції, необхідні для того, щоб структура сховища працювала добре у масштабі: збудувати кешування і інструменти для власності коду для монорепо, або залежності між репо і інструменти версії для полірепо. “Відповідно до цієї версії, варіант монорепо не є безкоштовним — нам потрібно буде інвестувати в кешування збирання та інструменти власності, або часи CI погіршаться, оскільки більше команд додасть до нього код.”
Звичайні фрази
- Як тісно пов’язані ці два проекти, насправді?»
- Чи буде ця зміна атомарним затвердженням в монорепо, або чи потрібна крос-репо координація в обох напрямках?
- Чи ці дві служби дійсно потребують незалежності випуску, або вони завжди відправляються разом?»
- «Яка вартість інструментів кожного варіанту, враховуючи наші поточні налаштування CI?»
- Це не є універсальним питанням «монорепо добре» або «полірепо добре» — як це виглядає для цих конкретних проектів?»
Приклади висловлювань
Формування пропозиції щодо структури репо: “Ці три сервіси розроблені майже повністю однією командою і постійно змінюються разом — це поєднання говорить про монорепо тут, навіть якщо я знаю, що ми зберігали інші сервіси в окремих репо.”
Відкидаючи загальні претензії: “Я не думаю, що «монорепо завжди краще для швидкості» стосується цього випадку — ці дві служби мають повністю незалежні ритми випуску і різні команди на вимогу, тому незалежність випуску, ймовірно, має більше значення, ніж атомарні затвердження тут.”
Назва прихованої вартості у пропозиції: “Перед тим, як ми приступимо до міграції монорепо, ми повинні врахувати вартість інструментів — зараз наш CI не налаштований для вибіркових збирань, тому кожен запит буде викликати повне перебудування всього, поки ми не вкладемо в це гроші.”
Професійні поради
- Закочувати обговорення у ** з’ єднання ** для конкретних проектів, які обговорюються, а не структуру репо як абстрактну перевагу — щільно з’ єднаний код отримує переваги від атомарних звітів незалежно від загальної думки когось про монорепо.
- Назвіть ** незалежність випуску ** явно, коли стверджуєте про окремі репозиторії — це зазвичай найсильніший конкретний аргумент, сильніший, ніж нечіткі заклики до «автономії команди»
- Розгляньте ** вартість інструментів ** на початку будь- якої пропозиції щодо монорепо — кешування збирання, вибіркове CI, і інструменти власності є справжніми інвестиціями, а не випадковими деталями, і пропуск цієї дискусії призведе до болісних сюрпризів пізніше.
- Не слід сприймати це як універсальну архітектурну позицію — розглядати кожну заяву з точки зору потреб конкретних проектів у з’ єднанні і випуску, а не загальної ідеології монорепо проти полірепо.
Практичні вправи
- Напишіть речення, у якому пояснюється, як зв’ язок між двома проектами має впливати на рішення щодо структури сховищ.
- Поясніть, що означає незалежність випуску і коли це має найбільше значення.
- Напишіть речення, у якому вкажіть вартість інструментів, які буде впроваджено у зв’ язку з перенесенням моно- сховища.
Наприклад, англійська мова має особливий лексичний склад для не-індіанців
Повідомлення технічних концепцій, таких як монорепо проти полірепо, може бути складним навіть для носіїв англійської мови. Для тих, чия рідна мова не є англійською, тонкощі фразування - особливо при обговоренні архітектурних рішень - можуть бути неймовірно складними. Це не просто передавання ідеї; це про те, щоб зробити це з точністю і ясністю, яка поважає час і розуміння ваших колег. Давайте розглянемо деякі поширені фрази і як їх ефективно використовувати, зосередившись на побудові впевненості в професійній англійській мові.
Одна з ключових областей - це визнання потенційних компромісів. Замість того, щоб просто сказати «Ми повинні використовувати монорепо», що може звучати авторитетно, спробуйте сформулювати це так: «Я розглядаю підхід монорепо, тому що він * міг би * запропонувати переваги, такі як зменшення дублювання і спрощене керування залежностями. Однак, нам також потрібно буде ретельно оцінити вплив на часи збирання і, можливо, збільшити складність нашого налаштування інструментів. “Зауважте включення “може” і “ми повинні…”. Це пом’якшує заяву, запрошуючи спільну дискусію, а не презентуючи директиву. Аналогічно, при обговоренні потенційних мінусів, такі фрази, як «Це може представляти виклики з точки зору…» або «Ключевим розглядом буде…» є набагато більш доступними і менш схильні звучати відверто.
Іншим важливим елементом є обговорення навколо впливу. Наприклад, якщо ви пояснюєте наслідки для автономії команди, ви можете сказати: «З точки зору розробки, монорепо може вимагати від нас прийняти більш централізований підхід до перегляду коду і, можливо, вплинути на окремі потоки роботи розробників. Ми повинні переконатися, що наші процеси відповідають цьому зсуву.” Використання “з точки зору розвитку” чітко сигналізує, чию точку зору ви представляєте, і дозволяє іншим пропонувати альтернативні точки зору. Уникайте надмірно технічного жаргону, коли це можливо, вибираючи ясніші пояснення, такі як «як це впливає на здатність команди працювати незалежно»
Нарешті, звертайте увагу на те, як ви реагуєте на різні думки. Якщо хтось висловлює занепокоєння щодо збільшення складності, то хороша відповідь не просто «Це неправда!», а спробуйте: «Я ціную вашу точку зору. Давайте глибше зануримося в * чому * це може бути так. Чи можемо ми відобразити на карті потенційне зростання вартості інструментів і оцінити, чи може наша поточна інфраструктура ефективно справлятися з цим?» Це демонструє активне вислуховування і бажання ретельно досліджувати їхні проблеми, сприяючи більш продуктивному діалогу. Пам’ятайте, що демонстрація того, що ви розумієте * їх * аргументацію, часто настільки ж важлива, як і висловлення власної.