Який найефективніший спосіб ділитися кодом між .NET-додатками?

У своїй роботі у нас є кілька різних .net-додатків, які мають багато базових функціональних можливостей. Ми створили ці програми за допомогою чистої n-ярусної архітектури, але ми потрапили в той момент, коли зрозуміли, що повторно реалізували одні і ті ж функції кілька разів. Очевидно, це порушує DRY, і ми хотіли б це виправити. Ми вже використовуємо Nuget для успішного використання загального коду клею (підключення IoC, ведення журналів, налаштувань), але ми також хотіли б поділитися нашими даними та бізнес-шарами між усіма нашими програмами. Ідея полягає в тому, що інтерфейс користувача матиме справу лише з частинами бізнес-шару, які йому фактично потрібні.

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

Скажімо, ми працюємо над проектом A і додаємо нову функцію, яка потребує змін у Foundation. Ми вносимо зміни до фонду (Foundation-A) і висуваємо їх до нульового каналу як нестабільний пакет. Проект A отримує найновіший пакунок нута, і все добре. Тим часом, інший розробник працює над проектом B. Він отримує останній фонд від контролю джерел, але бере його від стабільної гілки, щоб у ньому не було змін Проекту А. Він вносить зміни і створив Foundation-B. І все добре. Але потім ми виявимо функціонал реалізації Foundation-A та Foundation-B, який фактично міг би ділитися кодом, тому ми їх поєднуємо. Тим часом Foundation-C пливе туди з власними змінами. Зрештою, Фонд-Б готовий до виробництва, тому ми його витісняємо. Але тоді нам потрібно оновити Виробництво A, B,

Здається, це могло б працювати, але ми стурбовані роботою з різними схемами баз даних і збереженням синхронізованого між різними гілками сховища Foundation, а також сховищами проектів A, B і C. Схоже, напевно знадобиться багато ручної роботи, що відкриває можливість помилок. Я хотів би, щоб це було максимально автоматизованим.

Ось стек, який ми використовуємо: C #, TFS з постійною інтеграцією, Nuget. Наші програми - це всі різні типи програм ASP.NET. Ми готові подивитися на різні SCM, якщо це полегшить ситуацію.

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

Ми вносимо зміни до фонду (Foundation-A) і висуваємо їх до нульового каналу як нестабільний пакет.

Ось де починається ваша проблема ... Не робіть цього.

Будь-які зміни до фонду v1.0 мають бути притаманні всім споживачам Фонду, інакше він не належить до фонду. Отже, створюючи пакет nuget, робіть це як офіційну, стабільну версію Foundation (тобто v1.1), або не робіть цього взагалі.

Проект B повинен будувати свої вдосконалення Фонду так, як зазвичай, але (при належному режимі управління джерелами) повинен зливатися в змінах ствола (v1.1), перш ніж підштовхувати стабільний фонд (v1.2) до нуля.

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

Я погоджуюся з @Giedrius ; мені здається, це скоріше питання контролю джерела / розгалуження, в тому сенсі, що якщо розгалуження / злиття Foundation керується належним чином, питання управління пакетом стають суперечливими.

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

Також пам’ятайте, що не всі копії коду дійсно дублюються; Деякі з них - це клей-код або код, який інакше необхідний для підтримки архітектури, тому не зациклюйтеся на тому, щоб бути занадто СУХИМ.

Повторне використання коду

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

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

2. Загальний вихідний код. Код, який потрібен у більш ніж одному місці, пишеться один раз і розміщується у вихідному файлі у загальній структурі каталогів. Усі проекти, яким потрібен цей код, включають цей файл як один із вихідних файлів. Це забезпечує повторне використання коду, а переваги написання одного разу використовують багато. Однак. Його недоліком є ​​те, що стає можливим складання різних частин проекту, складених з різними версіями цього коду, - що може ввести деякі тонкі дефекти, які можна виявити і визначити за допомогою забезпечення якості.

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

Управління NuGET

Тут у вас набагато цікавіша проблема. Керування декількома конфігураціями. Моя порада тут - не керувати різноманітною базою клієнтів з різними версіями коду, а з файлами конфігурації. Існує щонайменше 3 шари даних конфігурації для управління. Базова (внутрішня) конфігурація товару, яку замовник ніколи не бачить. Параметри конфігурації за замовчуванням, які може змінити ваш клієнт, і останній рівень параметрів конфігурації, які змінив ваш клієнт. Розділяючи ці різні шари, ви зможете виконувати оновлення без руйнування конфігурацій клієнтів.

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

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

http://ayende.com/blog/3986/let-us-burn-all-those-pesky-util-common-libraries http://blog.jordanterrell.com/post/CommonUtility-Libraries-Dead.aspx

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

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

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