Як підтримувати однакові фрагменти коду для кількох проектів [закрито]

Я інді-розробник, який працює над багатьма проектами Android. У мене проблеми з підтримкою однакової функціональності в різних проектах. Наприклад, три мої програми використовують однакові 2 класи; оскільки це різні проекти, коли мені потрібно змінити ці заняття, мені потрібно зробити це тричі. Чи є просте рішення подібної поширеної проблеми?

Відокремте спільний код у бібліотеці та включіть бібліотеку до проектів.

Як розробник Android, ви, ймовірно, використовуєте Java. Подумайте про використання інструменту управління залежністю, наприклад, Maven або Ivy .

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

Контроль версій. Git. Підмодулі Git.

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

Ніхто ще не згадував меч з двома кінцями, тому я додам свої 2 копійки. Якщо у вас є кілька проектів, і всі вони мають спільний код для багаторазового використання, відповідно до належних практик / принципів програмування (наприклад, DRY), ви повинні розмістити код в одному глобальному місці та структурувати його таким чином, щоб ним могли ділитися всі ваші проекти без будь-яких модифікацій. Іншими словами, визначте, що інтерфейси мають бути загальними та загальними для всіх.

Для цього є кілька варіантів: 1) Створити базовий проект, від якого залежать інші. Цей проект може створити бінарний дистрибутив, який споживають інші проекти. 2) Витягніть модель з відкритим кодом у вашій організації. Майте загальний код - це власна гілка коду, а інші проекти мають такий же спосіб, як ви брали вихідний код з будь-якої ОСС в Інтернеті.

Тепер ось, де заходить меч ...

Розміщення коду в загальному місці, від якого залежать інші проекти / люди, може стати досить дорогим. Скажімо, у вас є код і від цього залежать 4 інші проекти. Один із ваших клієнтів, який використовує проект A, виявляє помилку, і вам доведеться виправити помилку. Ви поспішаєте виправити помилку, і цей клієнт задоволений. Але ви просто змінили якийсь код, від якого залежать 3 інші проекти. Ви повторно перевірили все, щоб переконатися, що не було введено крайових умов?

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

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

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

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

Кілька пропозицій, які я можу запропонувати:

1. Маючи загальний код, охоплений тестами автоматизованих одиниць, можна пройти довгий шлях і підказати вам, що коли ви вносите зміни, ви не просто зламали якийсь інший проект.
2. Я б розмістив лише дуже стабільний функціонал в загальний код. Якщо ви писали клас минулого року, щоб займатися керуванням таймером, і ви не змінили його за 9 місяців, а тепер у вас є 3 інші проекти, які потребують таймерів, то впевнений, що це хороший кандидат. Але якщо ви щойно писали щось на минулому тижні, ну ... у вас не так багато варіантів (і я ненавиджу копію / вставлення коду, мабуть, більше, ніж наступний хлопець), але я б подумав двічі про те, щоб зробити це загальним.
3. Якщо фрагмент коду є тривіальним, але ви використовували його в декількох місцях, можливо, краще кусати кулю, залишити DRY в спокої і пустити кілька копій.
4. Іноді платять не просто ставити загальний код у загальне місце розташування, а всі з них посилатись. Але скоріше розглядайте загальний код як власний випуск із версіями, датами випуску та всім іншим. Таким чином проект C може сказати: "Я використовую загальну бібліотеку v1.3", і якщо проект D потребує нової функціональності, ви залишаєте v1.3 в спокої, випускаєте v1.4 і проект C не впливає. Майте на увазі, трактувати загальний код як власний продукт набагато дорожче, а не просто перевіряти його у загальне місце розташування.

Це ідеалізоване рішення та може зайняти певні зусилля для роботи.

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

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

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

:-)

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

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

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