Як обговорювати стан залежностей проєкту англійською

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

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

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

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

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

** Семантичний контроль версій (SemVer) ** Семантичний версійно-контроль — це схема версійно-контролю, де номери версій слідують формату MAJOR.MINOR.PATCH. Зміна головної версії свідчить про зміну, що призвела до знищення, зміна другорядної версії додає нові функціональні можливості без знищення існуючого використання, а зміна латки виправляє вади.

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

Кінець життя (EOL) Залежність досягає кінця свого життя, коли її супровідники перестають надавати оновлення, включаючи латки безпеки. Використання залежностей EOL є ризиком для безпеки. Приклад: “Node.js 16 досяг кінця життя у вересні 2023 року. Всі проекти, що працюють на ньому, більше не отримують патчі безпеки».

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

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

Поширені сценарії, де використовується ця мова

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

When triaging a security alert: Автоматизовані інструменти, такі як Dependabot, Snyk або npm audit генерують попередження при виявленні вразливостей. Обговорення цих попереджень вимагає точної мови про тяжкість, експлуатабельність і усунення.

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

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

Корисні фрази для обговорення залежностей здоров’я

• «У нас є кілька залежностей, які не оновлювались більше двох років — це проблема з обслуговуванням»
• “Цей пакунок має відому вразливість безпеки, оцінену 7.8 по шкалі CVSS. Ми повинні негайно модернізувати»
• «Бібліотека більше не підтримується активно — останній запит був 18 місяців тому. Ми повинні розглянути альтернативи»
• «Ми прикріплюємо цю залежність, щоб уникнути несподіваних змін в автоматичних оновленнях»
• Процитовано 2011-01-11.  Dependabot has opened a pull request to upgrade this package — can someone review and merge it?
• “Нова основна версія вводить зміну в конфігурації API. Нам потрібно оновити наше використання перед міграцією»
• «Ця транзитивна залежність є джерелом вразливості — прямий пакунок повинен випустити латовану версію.»
• «Ми повинні перевірити ліцензію перед додаванням цього до нашої кодової бази — деякі ліцензії з авторським правом мають наслідки для нашої моделі розповсюдження»
• «Залежність широко прийнята і активно підтримується, що дає мені впевненість у її довгостроковій життєздатності»
• «Я рекомендую зменшити кількість залежностей тут — ми використовуємо 50 кБ бібліотеку для функції, яка займає три рядки ванільного коду»

Оцінка здоров’я залежності

Під час оцінки безпеки додавання нової залежності, скористайтеся послідовним набором критеріїв:

** Діяльність: ** Коли було останнє верифікування? Чи відповідають на запитання? Чи є активна дорожня карта? ** Прийняття:** Скільки проектів використовують цей пакунок? (щотижневі завантаження npm, зірки GitHub і використання у відомих компаніях є корисними сигналами.) ** Супроводження: ** Чи є чіткий супроводжувач або організація, яка стоїть за проектом? Історія безпеки: Чи був пакунок уразливим у минулому, і як з ним поводилися? ** Ліцензія: ** Чи є ліцензія дозволеною (MIT, Apache 2. 0) або авторським правом (GPL, AGPL)? ** Розмір пакунка: ** Що це додасть до вашої збірки?

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

Практичні рекомендації

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

«Перехід» — «перехід» від «перехід» до «перехід»

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

Наприклад, уявіть, що Сара переглядає PR, який включає використання старої версії бібліотеки журналювання — давайте назвемо її «LogLite». Замість того, щоб просто сказати «Підвищити LogLite!», Вона може сказати Девіду: «Я бачу, що ми все ще використовуємо LogLite v2.0. Хоча він працює, він має відомі вразливості, пов’язані з шифруванням даних, які були виправлені в останній версії (v3.5). Это может значительно повысить наш риск и вызвать проблемы с безопасностью. Чи можемо ми розглянути можливість оновлення, щоб зменшити цю проблему?» Зверніть увагу, як Сара розглядає цю проблему не лише як технічну, але й пов’ язує її з управлінням ризиками та потенційними наслідками. Цей підхід набагато більш схильні бути прийнятим позитивно і призвести до продуктивної дискусії.

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

Нарешті, пам’ятайте, що фрази навколо * інвестиції * можуть бути неймовірно ефективними. Замість того, щоб сказати « Ця залежність не варта того », спробуйте щось на зразок: « Щоб забезпечити довгострокове здоров’ я нашого проекту, я вірю, що інвестування в більш активно підтримувану альтернативу « LegacyTools » забезпечить нам кращу підтримку та можливості інтеграції, коли ми рухаємося вперед. » Формування вашого зворотнього зв’ язку навколо інвестицій — чи це час, ресурси, чи стратегічний напрямок — змінює розмову на спільні цілі і демонструє передбачення. Вивчення цих нюансових фраз значно поліпшить вашу здатність ефективно керувати обговореннями щодо перегляду залежностей.