Home project & совместный проект совместного использования проектов

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

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

Очевидно, что для этого, когда кто-то открывает WorkApplication в своей среде IDE, они также должны открыть SharedLibrary.

  • В языке Visual Studio это сделает как WorkApplication, так и SharedLibrary «проекты» под тем же «решением».

  • В языке IntelliJ IDEA они будут «модулями» под тем же «проектом».

  • В языке Eclipse они будут «проектами» в одном и том же «рабочем пространстве».

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

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

Как вы жонглируете этими тремя объектами, чтобы все обновлялось?

Проблема заключается в том, что разные части решения /project /workspace должны быть в разных репозиториях исходного кода: WorkApplication и SharedLibrary должны находиться в хранилище вашего рабочего места, а HomeApplication должен находиться в вашем домашнем репозитории.

Я не уверен, как смешивать несколько репозиториев исходного кода в одном и том же решении /проекте /рабочей области. Это можно сделать? Кто-нибудь попробовал? Это работает? Какие проблемы распространены?

Я могу представить сценарии, в которых вы лишаетесь преимуществ системной системы управления версиями из среды IDE, и вместо этого вы выполняете все свое обновление /фиксацию с использованием внешних инструментов каждый раз отдельно для каждого репозитория, но как-то можно сделать изнутри IDE?

Я не хочу связывать этот вопрос с какой-либо конкретной IDE, но позвольте мне просто упомянуть, что наиболее интересная для меня IDE - IntelliJ IDEA. (К сожалению, я считаю, что связанные с VCS опции IntelliJ IDEA очень сбивают с толку. Похоже, что я могу определить несколько серверов VCS в одном проекте, но неясно, как это сделать.)

4 голоса | спросил Mike Nakis 15 FebruaryEurope/MoscowbSun, 15 Feb 2015 20:07:15 +0300000000pmSun, 15 Feb 2015 20:07:15 +030015 2015, 20:07:15

1 ответ


1

Вы можете думать в терминах пакетов, что делает расположение источника неуместным.

Например, если вы работаете с C #, ваша общая библиотека может быть опубликована как пакет NuGet . Когда вы реорганизуете библиотеку, , вы не каскадируете что-либо сразу для работы приложения ; вместо этого вы публикуете новую версию пакета, и когда вы будете готовы, вы переносите рабочее приложение на новую версию , как это было бы, если, например, Microsoft выпустит новую версию Entity Framework (вы бы не поместили источник EF в свою базу кода и попросили разработчиков Microsoft каскадировать их изменения в своих бизнес-приложениях, верно?).

Это отношение издателя-потребителя . Вы предоставляете бесплатную (в конечном итоге, с открытым исходным кодом) пакет для своей компании, которая действует как ваш клиент. Они могут обновлять свои приложения до новых версий вашего пакета или продолжать использовать устаревшие версии, если захотят.

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


Смешение домашних проектов с вашей работой в качестве исходного уровня - не очень хорошая идея.

Если вы размещаете их отдельно (т. е. ваша личная библиотека остается в вашем личном хранилище на вашем домашнем сервере), это проблематично для компании, поскольку:

  • Нет никакой гарантии, что они смогут получить доступ к источнику навсегда. Что делать, если вы решили удалить его или закрыть домашний сервер? Даже потеря подключения к Интернету является проблематичной: по крайней мере, разработчики должны иметь доступ к корпоративному репозиторию, если он размещен в одном здании.

Если вы размещаете их вместе, это создает другой набор проблем:

  • Компания может применять определенные правила, которые вы не хотите соблюдать в своем личном проекте, например, руководство по стилю. Компании может потребоваться конкретное покрытие кода или код, соответствующий linter-совместимому, или просто, чтобы любой совершенный код просматривался вашими парами. Эти стандарты, нормальные в корпоративной среде, не должны применяться к вашему личному проекту.

    Хуже того, компания может не требовать чего-то прямо сейчас, но установила новое требование качества в один прекрасный день. Чтобы ты делал? Измените свою личную библиотеку, чтобы она соответствовала? Удалить библиотеку из исходного кода?

  • Некоторые менеджеры могут не понимать, что вы делаете, и находить это неудобным. В худшем случае они могут подумать, что вы тратите свое время на работу над своим проектом на работе, что может быть воспринято очень плохо.

    В предыдущем пункте я упомянул об обновлении вашего личного проекта в соответствии со стандартами компании. Что, если ваш босс замечает, что вы работаете над этим (и т. Д. свой собственный проект ), в то время как вы ожидаете решения ошибок для следующей версии, запланированной на следующую неделю?

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

Модель издателя-потребителя решает все четыре проблемы:

  1. Компания знает, что они смогут получить доступ к текущей версии вашего пакета навсегда. Удаление пакета из NuGet возможно, но очень сложно.

  2. Вам не обязательно следовать правилам и стандартам третьих сторон. Это ваш проект, поэтому ваши правила.

  3. Нельзя обвинять вас в том, что вы работаете над своими личными проектами на работе. Они четко разделены.

  4. Вы сохраняете интеллектуальную собственность своего проекта и устанавливаете лицензию на свой вкус. Опять же, ваш проект, вашправила.

ответил Arseni Mourzenko 15 FebruaryEurope/MoscowbSun, 15 Feb 2015 20:22:13 +0300000000pmSun, 15 Feb 2015 20:22:13 +030015 2015, 20:22:13

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

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

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