Використання пакетів (дорогоцінних каменів, яєць тощо) для створення роз'єднаних архітектур

Основне питання

Бачачи хорошу підтримку більшості сучасних платформ програмування мають для управління пакетами (думають gem, npm, і pipт.д.), має сенс розробити додаток або систему складаються з внутреннх розроблених пакетів, таким чином , щоб заохочувати і створювати слабо зв'язаної архітектуру?

Приклад

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

Міркування

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

Це здається раціональною та розумною дизайнерською концепцією? Чи сьогодні це насправді використовується як стандартний спосіб структурування додатків?

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

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

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

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

Це гарна ідея, загалом. Вам потрібно буде подумати про створення внутрішнього сховища пакетів (зазвичай його називають "сховищем артефактів" у світі Java або "сервером pypi" у світі Python), щоб ви зберігали там ті пакунки, які ви не хочете чи не можете " t випуск як відкритий код.

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

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

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