Як боротися зі страхом приймати залежності

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

Я погоджуюсь, що ми повинні бути надзвичайно обережними при впровадженні (сторонніх) залежностей. Наразі у нас немає сторонніх залежностей, і ми мусимо залишатися на найнижчому рівні API рамки.

Деякі приклади:

• Ми змушені залишатися на найнижчому рівні API рамки (.NET Standard). Причина цього полягає в тому, що одного дня може з'явитися нова платформа, яка підтримує лише дуже низький рівень API.
• Ми реалізували власні компоненти для (де) серіалізації JSON і зараз робимо те ж саме для JWT. Це доступно на більш високому рівні API API.
• Ми реалізували обгортку навколо рамки HTTP стандартної бібліотеки, тому що не хочемо брати залежність від HTTP реалізації стандартної бібліотеки.
• Весь код для відображення в / з XML пишеться "від руки", знову ж таки з тієї ж причини.

Я відчуваю, що ми забираємо це занадто далеко. Мені цікаво, як з цим боротися, оскільки я думаю, що це сильно впливає на нашу швидкість.

... Ми змушені залишатися на найнижчому рівні API рамки (.NET Standard) ...

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

.NET Standard не є і ніколи не буде " найнижчим рівнем API рамки ". Самий обмежувальний набір API для .NET досягається створенням портативної бібліотеки класів, націленої на Windows Phone та Silverlight.

Залежно від того, на яку версію .NET Standard ви орієнтовані, ви можете створити дуже багатий набір API, сумісних з .NET Framework, .NET Core , Mono та Xamarin . І є багато сторонніх бібліотек, сумісних з .NET Standard, які працюватимуть на всіх цих платформах.

Тоді є .NET Standard 2.1, який, швидше за все, вийде восени 2019. Він буде підтримуватися .NET Core, Mono та Xamarin. Він не буде підтримуватися жодною версією .NET Framework , принаймні, в осяжному майбутньому, і цілком ймовірно, завжди. Тож у найближчому майбутньому .NET Standard , далеко не " найнижчий рівень API рамки ", витіснить фреймворк та матиме API, які не підтримуються останніми.

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

Тоді випуск сторонніх бібліотек. Наприклад, JSON.NET сумісний із .NET Standard. Будь-яка бібліотека, сумісна з .NET Standard, гарантована - для API - для роботи з усіма .NET-реалізаціями, сумісними з цією версією .NET Standard. Таким чином, ви не досягаєте додаткової сумісності, не використовуючи її та створюючи свою бібліотеку JSON. Ви просто створюєте більше роботи для себе і несете непотрібні витрати на свою компанію.

Так що так, ви, безумовно, забираєте це занадто далеко, на мій погляд.

Ми змушені залишатися на найнижчому рівні API рамки (.net стандарт). Причина цього полягає в тому, що одного дня може з'явитися нова платформа, яка підтримує лише дуже низький рівень API.

Міркування тут досить зворотні. Старіші, нижчі рівні API швидше застаріють і не підтримуються, ніж нові. Хоча я погоджуюся, що залишатись комфортним шляхом за «передовою межею» доцільно забезпечити розумний рівень сумісності у згадуваному вами сценарії, ніколи не рухаючись вперед, не виходить за межі крайніх.

Ми реалізували власні компоненти для (де) серіалізації JSON і зараз робимо те ж саме для JWT. Це доступно у більш високому рівні API API. Ми реалізували обгортку навколо рамки HTTP стандартної бібліотеки, оскільки не хочемо брати залежність від імпементації HTTP стандартної бібліотеки. Весь код для відображення в / з XML пишеться "від руки", знову ж таки з тієї ж причини.

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

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

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

В цілому ці речі корисні для ваших клієнтів. Навіть популярна бібліотека з відкритим кодом з певних причин може бути неможливою для їх використання.

Наприклад, вони, можливо, підписали контракт зі своїми клієнтами, обіцяючи не використовувати продукти з відкритим кодом.

Однак, як ви зазначаєте, ці особливості не обійдуться.

• Час на ринок
• Розмір упаковки
• Продуктивність

Я б підняв ці недоліки і поговорив з клієнтами, щоб дізнатися, чи справді вони потребують рівнів сумісності, які ви пропонуєте.

Якщо, наприклад, усі клієнти вже використовують Json.NET, то використання його у вашому продукті, а не власний код десеріалізації, зменшує його розмір та покращує його.

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

Коротка відповідь - слід почати вводити сторонні залежності. Під час чергової зустрічі з розмовою скажіть всім, що наступний тиждень на роботі буде найвеселішим, що їм було за роки - вони замінять компоненти JSON та XML на відкриті джерела, стандартні рішення бібліотек. Скажіть усім, що у них є три дні для заміни компонента JSON. Святкуйте після того, як це буде зроблено. Влаштувати вечірку. Це варто відзначити.

В основному все зводиться до зусиль проти ризику.

Додавши додаткову залежність або оновивши рамки або використовуючи API більш високого рівня, ви знижуєте зусилля, але ви ризикуєте. Тому я б запропонував зробити аналіз SWOT .

• Сильні сторони: Менше зусиль, тому що вам не доведеться кодувати це самостійно.
• Слабкі сторони: Це не так, як створено на замовлення для ваших особливих потреб, як рішення, виготовлене вручну.
• Можливості: Час на ринок менше. Ви можете отримати прибуток від зовнішніх розробок.
• Загрози: Ви можете засмутити клієнтів додатковими залежностями.

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

Розділіть бібліотеки компонентів на набір "Основні", які не мають залежностей (по суті, що ви робите зараз) та "Загальний" набір, які залежать від вашої "Основної" та сторонніх бібліотек.

Таким чином, якщо хтось хоче лише функціонал "Core", він може його мати.

Якщо хтось хоче функціонал "Спільний", він може його мати.

І ви можете керувати тим, що є "Core" та "Common". Ви можете швидше додати функціональність до "Загального" та перемістити його у власну "Основну" реалізацію, якщо / коли має сенс надати власну реалізацію.