Как поддерживать одинаковые фрагменты кода для нескольких проектов [закрыто]

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

8 голосов | спросил user65721 21 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 21 Sep 2012 00:22:15 +0400 2012, 00:22:15

4 ответа


15

Отделите общий код от библиотеки и включите библиотеку в проекты.

Как разработчик Android, вы, вероятно, используете Java. Подумайте об использовании инструмента управления зависимостями, например Maven или Ivy .

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

ответил Mechanical snail 21 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 21 Sep 2012 01:27:53 +0400 2012, 01:27:53
9

Контроль версий. Git. Git Submodules.

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

ответил Hakan Deryal 21 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 21 Sep 2012 00:31:03 +0400 2012, 00:31:03
3

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

Есть несколько вариантов для этого: 1) Создайте базовый проект, от которого зависят другие. Этот проект может создать двоичный дистрибутив, который потребляют другие проекты. 2) Потяните модель с открытым исходным кодом в вашей организации. Имеют общий код как свою собственную ветвь кода, а другие проекты выставляют код так же, как и исходный код из любого OSS в Интернете.

Теперь вот, куда входит меч ...

Размещение кода в общем месте, от которого зависят другие проекты /люди, может стать довольно дорогостоящим. Допустим, у вас есть кусок кода, и от него зависят еще 4 проекта. Один из ваших клиентов, который использует проект A, обнаруживает ошибку, и вам нужно исправить ошибку. Вы бросаете исправление, и этот клиент счастлив. Но вы только что изменили код, который зависит от 3 других проектов. Повторяли ли вы все эти проверки, чтобы убедиться, что условия края не были введены?

Общий код также должен быть обработан гораздо более тщательно, и интерфейсы модулей должны быть намного лучше разработаны, потому что этот код должен размещать не один, а 4 клиента, и каждый из них может просто использовать этот код с такой незначительной разницей.

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

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

Если вы используете повторное использование этого кода, это не так уж плохо. Если у вас есть команда инженеров, и они начинают использовать общий код, расходы растут еще больше. Если другие участвуют, ожидайте размещения кода в общей библиотеке, чтобы сделать в 3 раза больше времени, чем требуется, чтобы довести его до точки, когда вы считаете, что она «полная». Вам необходимо: a) сделать библиотеку более надежной для защиты от всех видов граничных условий и недопустимого использования; b) предоставить документацию, чтобы другие могли использовать библиотеку; c) помогать другим людям отлаживать, когда они используют библиотеку таким образом, чтобы вы не ожидали, и ваша документация не охватывала их конкретный вариант использования.

Несколько предложений, которые я могу предложить:

  1. Наличие общего кода, охватываемого автоматическими модульными тестами, может пройти долгий путь и дать вам некоторое представление о том, что при внесении изменений вы не просто нарушили какой-либо другой проект.
  2. Я бы поставил очень стабильную функциональность в общий код. Если вы написали класс в прошлом году для управления таймером, и вы не изменили его за 9 месяцев, и теперь у вас есть еще 3 проекта, которым нужны таймеры, то уверен, что это хороший кандидат. Но если вы только что написали что-то на прошлой неделе, ну ... у вас нет таких вариантов (и я ненавижу копировать /вставлять код, вероятно, больше, чем следующий парень), но я бы дважды подумал о том, чтобы сделать его общим.
  3. Если фрагмент кода тривиален, но вы использовали его в нескольких местах, возможно, лучше укусить пулю, оставить DRY в одиночку и предоставить несколько копий.
  4. Иногда платит не просто поместить общий код в обычное место и все ссылаются на него. Но скорее рассматривайте общий код как свой собственный, который может быть выпущен с версиями, датами выпуска и всем остальным. Таким образом, проект C может сказать: «Я использую общую библиотеку v1.3», и если проект D нуждается в новых функциях, вы оставите v1.3 один, выпустите v1.4, а проект C не пострадает. Имейте в виду, это МНОГО, МНОГОболее дорогой, чтобы рассматривать общий код как свой собственный продукт, а не просто проверять его в общем месте.
ответил DXM 21 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 21 Sep 2012 08:16:11 +0400 2012, 08:16:11
1

Это идеализированное решение и может приложить определенные усилия для работы.

Принцип DRY гласит, что должен быть один авторитетный источник истины. Это диктует использование единственного репозитория source для всей логики программы без дублирования; файлы, созданные для содействия совместному использованию и повторному использованию документов.

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

Я бы подошел к этой проблеме, подчинившись неизбежному: вам нужно будет одновременно использовать оба подхода, и мы будем использовать скрипты и amp; чтобы сгладить тот факт, что подходы противоречивы.

: -)

Единый репозиторий будет вашим единственным авторитетным источником. Процесс сборки для каждого проекта скопирует все файлы, используемые этим проектом (и только те файлы), в промежуточное место, а затем построит из этого промежуточного местоположения. (Unison или какой-либо подобный инструмент можно использовать для перемещения дельт, а не целых файлов).

Эти промежуточные местоположения могут использоваться в качестве локальных рабочих копий для набора вторичных, производных или нижележащих репозиториев. В сценариях фиксации после фиксации в авторитетном репозитории будут обновлены все промежуточные местоположения, а для каждого, в свою очередь, проверьте, было ли оно изменено, и сделайте одну и ту же фиксацию в соответствующем вторичном репозитории, если обнаружено изменение.

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

ответил William Payne 21 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 21 Sep 2012 04:46:32 +0400 2012, 04:46:32

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132